Re: XFS on 2.6.26: reading the first 4K of a large file takes ages

[Dave Chinner <david@fromorbit.com>]

On Fri, May 21, 2010 at 06:43:15AM +0000, Florian Weimer wrote:
> * Stewart Smith:
> 
> > On Thu, 20 May 2010 12:11:00 +0000, Florian Weimer <fweimer@bfk.de> wrote:
> >> Thanks for confirming my hunch.  I don't think it's worth fixing this
> >> in XFS.  The database should call posix_fallocate() before flushing
> >> its internal cache to the file in essentially random order, but it's
> >> difficult to get upstream to implement this (the source code is a bit
> >> hard to follow, unfortunately).
> >
> > Which database?
> 
> Oracle Berkeley DB.
> 
> > You could always mount with allocsize
> 
> This happens with "allocsize=4194304".

Because allocsize only works for allocations extending the file.

> > or use other tools to do the preallocation before things got too
> > bad.
> 
> Is there a way to transparently preallocate a few GB after the current
> end of the file?  That would be helpful because Berkeley DB wouldn't
> have to know about it.

Yes. the fallocate() syscall has a mode that allows allocation
beyond the current end of file, as does the XFS_IOC_RESVSP ioctl.

Or, even easier, with xfs_io:

$ stat /mnt/test/foo
  File: `/mnt/test/foo'
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
....
$ xfs_io -f -c "resvsp 0 1048576" /mnt/test/foo
$ stat /mnt/test/foo
  File: `/mnt/test/foo'
  Size: 0               Blocks: 2048       IO Block: 4096   regular empty file
....
$ xfs_bmap -vp /mnt/test/foo
/mnt/test/foo:
 EXT: FILE-OFFSET      BLOCK-RANGE      AG AG-OFFSET        TOTAL FLAGS
   0: [0..2047]:       171912..173959    0 (171912..173959)  2048 10000
$

/mnt/test/foo still a zero length file but has 1MB of extents allocated.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs