Re: pathconf syscall for linux

Lukas Czerner
2017-09-22T08:38:35Z

On Thu, Sep 21, 2017 at 03:49:48PM +0200, Florian Weimer wrote:
> On 09/21/2017 03:17 PM, Lukas Czerner wrote:
>
> > _PC_NAME_MAX linux limits
>
> Note that _PC_NAME_MAX is basically a lie. There are file systems which
> support longer names than 255 bytes. It's quite common for file systems
> which store names in UCS-2 or UTF-16 and have code point limit of 255, which
> translates to something larger after UTF-8 conversion in the kernel. This
> value is available today through statfs/f_namemax, but historically, the
> reported value was not correct.

Right, we can do this correctly from kernel though.

>
> But due to file bind mounts, any value the kernel can return is useless for
> application use anyway.
>
> The only real user of this constant was readdir_r, and I've been trying to
> kill it (it's still in POSIX, but will be removed in a future edition).

Good to know, but we still need to implement this, at least for now.

>
> > _PC_REC_INCR_XFER_SIZE ?
> > _PC_REC_MAX_XFER_SIZE ?
> > _PC_REC_MIN_XFER_SIZE ? block size ?
> > _PC_REC_XFER_ALIGN per fs (block size)
>
> NFS (and perhaps other network file systems) treats f_bsize to signal
> something similar. We had to remove f_bsize-based tuning from glibc as a
> result because the value is quite misleading for many workloads.
>
> > _PC_ALLOC_SIZE_MIN per fs (block size)
>
> Like the other size limits quoted above, the semantics are quite unclear.
> POSIX documents them mostly in the context of the RT extensions, so the
> acceptable values likely depend whether the application uses kernel-assisted
> aio, or aio based on userspace threads.

Thanks!
-Lukas