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>