Date: Fri, 12 Nov 2010 01:17:51 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Evans <brde@optusnet.com.au> Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and pathconf(_PC_NO_TRUNC) Message-ID: <20101112005719.O1598@besplex.bde.org> In-Reply-To: <20101112002522.V1372@besplex.bde.org> References: <871369D9-7D63-4CE0-BB87-B8C46A62B271@exonetric.com> <201011111206.oABC6VYG027663@higson.cam.lispworks.com> <86371A88-1474-4A51-8C84-05C4A71A9135@exonetric.com> <20101112002522.V1372@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Nov 2010, Bruce Evans wrote: > On Thu, 11 Nov 2010, Mark Blackman wrote: > >> On 11 Nov 2010, at 12:06, Martin Simmons wrote: >>> Your call to printf is clobbering the real errno, which is EINVAL. >> >> Doh! thanks for pointing that out. :) >> >>> That is an >>> allowed value according to the pathconf man page: >>> >>> [EINVAL] The implementation does not support an association >>> of >>> the variable name with the associated file. >>> >>> So it is correct, but maybe not useful. >> >> hmm. this is popping up in the context of building perl 5.12 on a zfs-only >> filesystem. One of the POSIX::* tests fails because of the above. > > zfs_vnops.c:zfs_pathconf() is missing _PC_NO_TRUNC, so it seems to be just > broken (it returns EOPNOTSUPP for cases not in the switch, so there seems > to be no way for another level to support _PC_NO_TRUNC). It apparently > depends on another layer providing defaults. > > Other basic things missing in it: > _PC_NAME_MAX > _PC_CHOWN_RESTRICTED > _PC_PIPE_BUF > [several other things that are in the switch statement in vop_stdpathconf(), Oops, more careful grepping shows that zfs uses its own layer (zfs_freebsd_pathconf()) to provide defaults by calling vop_stdpathconf() if zfs_pathconf() fails with error EOPNOTSUPP, so it should never fail for _PC_NO_TRUNC or the other basic ones). But there seem to be problems somewhere. EOPNOTSUPP is not a possible error for pathconf(). EINVAL must be returned for unsupported feature tests. ffs handles all the cases directly, except it is more careful for fifos -- it calls fifo_pathconf() for these, where zfs seems to succeed for a lot of features that shouldn't apply to fifos, and then falls back to vop_stdpathconf() which succeeds for even more features where it shouldn't. fifo_pathconf() only succeeds for _PC_LINK_MAX, _PC_PIPE_BUF and _PC_CHOWN_RESTRICTED. Its setting of _PC_LINK_MAX is wrong, since the value of this is fs-dependent. _PC_PIPE_BUF is of course pipe+fifo-dependent so its setting belongs here and somewhere for pipes (I can't see where it is supported for fpathconf() on pipes). _PC_CHOWN_RESTRICTED also shouldn't be set here, but perhaps fifos can know a system-wide setting and repeat it, as other file systems do. Correct layering would probably result in vop_stdpathconf() not existing. It is currently more or less correct only for devfs, and is only used by zfs, coda, devfs, fdescfs and portalfs. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101112005719.O1598>