Re: RESVSP problems

[David Chinner <dgc@sgi.com>]

On Tue, May 08, 2007 at 12:03:07AM -0500, Eric Sandeen wrote:
> David Chinner wrote:
> 
> >>>yeah... ISTR that the arguments are funky.  I can't remember if it's a
> >>>bug or not.  :)  FWIW, allocsp just writes zeros to the file, so you
> >>>could do it just as well from userspace w/ no fancy ioctls...  ALLOCSP
> >>>is a bit pointless if you ask me... though maybe someone knows why it's
> >>>there :)
> >>Let me say that I have noticed that using ALLOCSP seems to create less 
> >>extents than posix_fallocate/manual zeroing.
> >
> >Yes, that's likely ;)
> >
> >There's work currently active to make posix_fallocate() do the same thing
> >as ALLOCSP (i.e. call into the filesystem and let it do smart stuff), but
> >that's a ways off yet...
> 
> Dave, doesn't ALLOCSP actually create actual zeroed space though? 

Ah, yes it does - I was sort of lumping allocsp/resvsp together as one
there.

> Pretty much as posix_fallocate from userspace does today, maybe with 
> better allocation...

Better allocations and with no ENOSPC-after-partial-zeroing problems,
either.

> And "smart stuff" would be *not* needing to write 
> zeros.... i.e. what RESVSP does.

Yup. I've implemented fallocate() with the equivalent of RESVSP.
xfs_zero_eof() is smart enough to not try to zero unwritten extents
so changing the filesize after preallocation is effectively a no-op ;)

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group