Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Apr 2011 13:38:32 -0700
From:      mdf@FreeBSD.org
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r220791 - in head: lib/libc/sys sys/compat/freebsd32 sys/kern sys/sys
Message-ID:  <BANLkTi=moc4HLXsoczxcFR8Y9twOuOEfmA@mail.gmail.com>
In-Reply-To: <20110418201302.GY48734@deviant.kiev.zoral.com.ua>
References:  <201104181632.p3IGWM5v077720@svn.freebsd.org> <20110418192810.GX48734@deviant.kiev.zoral.com.ua> <BANLkTi=A-C6PY%2B5VSbigQpLKLVJYQ2b2Mg@mail.gmail.com> <20110418201302.GY48734@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
2011/4/18 Kostik Belousov <kostikbel@gmail.com>:
> On Mon, Apr 18, 2011 at 12:49:38PM -0700, mdf@freebsd.org wrote:
>> On Mon, Apr 18, 2011 at 12:28 PM, Kostik Belousov <kostikbel@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:
>> >> =A0 Add the posix_fallocate(2) syscall. =A0The default implementation=
 in
>> >> =A0 vop_stdallocate() is filesystem agnostic and will run as slow as =
a
>> >> =A0 read/write loop in userspace; however, it serves to correctly
>> >> =A0 implement the functionality for filesystems that do not implement=
 a
>> >> =A0 VOP_ALLOCATE.
>> >>
>> >> =A0 Note that __FreeBSD_version was already bumped today to 900036 fo=
r any
>> >> =A0 ports which would like to use this function.
>> >>
>> >> =A0 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. =A0Without 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=moc4HLXsoczxcFR8Y9twOuOEfmA>