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
