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

[mdf at FreeBSD.org]

2011/4/18 Kostik Belousov <kostikbel at gmail.com>:
> On Mon, Apr 18, 2011 at 12:49:38PM -0700, mdf at freebsd.org wrote:
>> On Mon, Apr 18, 2011 at 12:28 PM, Kostik Belousov <kostikbel at gmail.com> wrote:
>> > On Mon, Apr 18, 2011 at 04:32:22PM +0000, Matthew D Fleming wrote:
>> >> Author: mdf
>> >> Date: Mon Apr 18 16:32:22 2011
>> >> New Revision: 220791
>> >> URL: http://svn.freebsd.org/changeset/base/220791
>> >>
>> >> Log:
>> >>   Add the posix_fallocate(2) syscall.  The default implementation in
>> >>   vop_stdallocate() is filesystem agnostic and will run as slow as a
>> >>   read/write loop in userspace; however, it serves to correctly
>> >>   implement the functionality for filesystems that do not implement a
>> >>   VOP_ALLOCATE.
>> >>
>> >>   Note that __FreeBSD_version was already bumped today to 900036 for any
>> >>   ports which would like to use this function.
>> >>
>> >>   Also reserve space in the syscall table for posix_fadvise(2).

>> 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 violates the standard, though, since it would return ENOSPC
instead of EFBIG.

Also, this is just the default implementation.  I'm adding a second
VOP_SETATTR in vop_stdallocate() to restore the file size after
extending, which will let the implementation use bzero/VOP_WRITE
instead of VOP_READ/VOP_WRITE when past the original EOF.  This is
more of an issue when calling the vop iteratively, since subsequent
calls don't know what the "correct" file size is.

Cheers,
matthew