From owner-freebsd-fs@FreeBSD.ORG Thu Nov 11 14:17:58 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7241D1065693 for ; Thu, 11 Nov 2010 14:17:58 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBCC8FC16 for ; Thu, 11 Nov 2010 14:17:57 +0000 (UTC) Received: from c122-107-121-73.carlnfd1.nsw.optusnet.com.au (c122-107-121-73.carlnfd1.nsw.optusnet.com.au [122.107.121.73]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oABEHpoa020457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2010 01:17:52 +1100 Date: Fri, 12 Nov 2010 01:17:51 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20101112002522.V1372@besplex.bde.org> Message-ID: <20101112005719.O1598@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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: ZFS and pathconf(_PC_NO_TRUNC) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 14:17:58 -0000 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