Re: [PATCH] 05/13 e2fsprogs-inode_prealloc - allow PAGE_SIZE persistent preallocation

On Aug 05, 2006  18:36 -0400, Theodore Tso wrote:
> On Wed, Aug 02, 2006 at 10:52:45AM -0600, Andreas Dilger wrote:
> > Allow regular files to be preallocated on-disk up to the next multiple
> > of the system PAGE_SIZE without complaining about extra blocks.
> 
> Two problems with this patch.
> 
> First of all, getpagesize() isn't portable.  In fact, the man page
> describing it is positively scary:
> 
>    CONFORMING TO
>        SVr4, 4.4BSD, SUSv2.   In  SUSv2  the  getpagesize()  call  is  labeled
>        "legacy",  and in POSIX 1003.1-2001 it has been dropped.  HPUX does not
>        have this call.
> 
>    NOTES
>        Whether getpagesize() is present as a Linux system call depends on  the
>        architecture.   If it is, it returns the kernel symbol PAGE_SIZE, which
>        is architecture and machine model dependent.  Generally, one uses bina
>        ries that are architecture but not machine model dependent, in order to
>        have a single binary distribution per architecture. This means  that  a
>        user  program  should  not find PAGE_SIZE at compile time from a header
>        file, but use an actual system call, at least for  those  architectures
>        (like sun4) where this dependency exists.  Here libc4, libc5, glibc 2.0
>        fail because their getpagesize() returns a  statically  derived  value,
>        and does not use a system call.  Things are OK in glibc 2.1.
> 
> The portable way to do this can be found in mke2fs, which uses
> sysconf(_SC_PAGESIZE), which is a POSIX.1 interface.
> 
> The second problem which is bothering me is that this isn't a complete
> fix.  What if the filesystem is moved from an Itanic system to an x86
> system?  The page size will change, and e2fsck will complain.  There
> are a number o options, including:
> 
> 1) Just let e2fsck complain in this case, which will result in a
> potentially scary message during the boot sequence, but which
> mercifully won't result in the boot being aborted.  That's what this
> patch does, but it is potentially ignoring the problem.
> 
> 2) Define a new superblock field which gives a hint about the largest
> page size architecture which has ever mounted the filesystem.  That
> way, the filesystem won't show errors when it is moved from a system
> with larger pages to one with smaller pages.  The downside though is
> that this requires a kernel patch in order for this to function
> perfectly, although e2fsck could be changed to update the hint, so
> that as long as e2fsck is run at least once on the largepage system,
> this solution will work.
> 
> 3) Be permissive and allow allocated blocks rounded up to 64k always.
> This could result in some extra wasted blocks, but isn't otherwise
> harmful.  
> 
> I'm leaning towards (2) or (3).  (3) has the advantage of being
> simplest, while (2) has the advantage of being most correct.  Does
> anyone have an opinion on the matter?

I'm OK with 3, but 2 should also be relatively safe.  I don't think
we have filesystems moving between architectures very often, the only
realistic time it happens is with embedded filesystems.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642