Date: Fri, 15 Apr 2011 12:30:57 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: mdf@freebsd.org Cc: Gleb Kurtsou <gleb.kurtsou@gmail.com>, FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: posix_fallocate(2) Message-ID: <20110415093057.GJ48734@deviant.kiev.zoral.com.ua> In-Reply-To: <BANLkTi=OWUnB_ue3RT4bzGNvivZwW_ofkA@mail.gmail.com> References: <BANLkTimYzJ11w9X1OHShEn2wi6gjHx=YjA@mail.gmail.com> <20110414213610.GB92382@tops> <BANLkTi=OWUnB_ue3RT4bzGNvivZwW_ofkA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--HuXIgs6JvY9hJs5C Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 14, 2011 at 03:41:30PM -0700, mdf@freebsd.org wrote: > On Thu, Apr 14, 2011 at 2:36 PM, Gleb Kurtsou <gleb.kurtsou@gmail.com> wr= ote: > > On (14/04/2011 12:35), mdf@FreeBSD.org wrote: > >> For work we need a functionality in our filesystem that is pretty much > >> like posix_fallocate(2), so we're using the name and I've added a > >> default VOP_ALLOCATE definition that does the right, but dumb, thing. > >> > >> The most recent mention of this function in FreeBSD was another thread > >> lamenting it's failure to exist: > >> http://lists.freebsd.org/pipermail/freebsd-ports/2010-February/059268.= html > >> > >> The attached files are the core of the kernel implementation of the > >> syscall and a default VOP for any filesystem not supporting > >> VOP_ALLOCATE, which allows the syscall to work as expected but in a > >> non-performant manner. =9AI didn't see this syscall in NetBSD or > >> OpenBSD, so I plan to add it to the end of our syscall table. > >> > >> What I wanted to check with -arch about was: > >> > >> 1) is there still a desire for this syscall? > > It looks not to play well architecturally with modern COW file systems > > like ZFS and HUMMER. So potentially it can be implemented only for UFS. >=20 > The syscall, or the dumb implementation? I don't see why the syscall > itself would be a problem; presumably ZFS can figure out whether an > fallocate() block is worth COWing or not... >=20 > >> 2) is this naive implementation useful enough to serve as a default > >> for all filesystems until someone with more knowledge fills them in? > > Maillist ate the patch. Only man page attached. >=20 > Whoops! >=20 > http://people.freebsd.org/~mdf/bsd-fallocate.diff New syscall symbols for 9.0 should go in under FBSD_1.2 version, not FBSD_1= .0. You have inconsistent spacing in the kern_posix_fallocate(). I do not quite understand the locking for vnode you did. You marked the vop as taking and returning unlocked vnode. But, you do call VOP_GETATTR in the vop std implementation before locking the vnode. Did you tested with DEBUG_VFS_LOCKS config ? Usual (and proper) practice is to have such vop require locked vnode, in case of VOP_ALLOCATE, exclusive lock is appropriate. The Giant dance and vn_start_write() + vn_lock() go into kern_posix_fallocate() then. Also, you should call bwillwrite() before taking any vfs locks. Is locking/unlocking the vnode in loop is done to allow other callers to perform i/o on the vnode in between ? In particular, to truncate it ? I think this is not needed, and previous suggestion would take care of it. Why do you need stdallocate_extend() ? VOP_WRITE does the right thing with extending the vnode. You might find vn_rdwr easier to use then the bare vops. In particular, it would not omit the mac calls for read/write. --HuXIgs6JvY9hJs5C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk2oEFEACgkQC3+MBN1Mb4hjtgCgg7uxoPSepR7JPHDkdqaZUGrp 0pkAoOz8XPQ6Rtdju8bnj7JKGhnOliDi =Q8QX -----END PGP SIGNATURE----- --HuXIgs6JvY9hJs5C--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110415093057.GJ48734>