Re: RESVSP problems

David Chinner
2007-05-08T05:25:32Z

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