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

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?

						- Ted

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV