ZFS and pathconf(_PC_NO_TRUNC)

[Bruce Evans]

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