svn commit: r220791 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys

[Pawel Jakub Dawidek]

On Mon, Apr 18, 2011 at 11:13:02PM +0300, Kostik Belousov wrote:
> > The need is, as commented, to return EFBIG when the new file size will
> > be larger than the FS supports.  Without this code, passing in
> > something like posix_fallocate(fd, 0, OFF_MAX) will run the filesystem
> > out of space.
> Handling max file size and not overflowing the fs are different things.
> VOP_WRITE() will handle file size on its own too. I see no problem with
> exhausting free space if this is what user asked for.

This makes me wonder that current implementation isn't atomic.
If we get out of space error, we won't shrink the file back.
Even if we could shirk it at the end, we won't be able to put holes in
the middle of it.
Not sure if this is a big issue, but one doesn't expect from rename(2)
to create new link and not remove old one.
All in all, making it atomic would be impossible currently for various
reasons (we can't put holes back and we can crash in the middle).

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20110418/fc406da0/attachment.pgp