linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Lukas Czerner <lczerner@redhat.com>, Theodore Ts'o <tytso@mit.edu>
Cc: Christoph Hellwig <hch@infradead.org>,
	Andreas Dilger <adilger@dilger.ca>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org
Subject: Re: pathconf syscall for linux
Date: Thu, 21 Sep 2017 15:49:48 +0200	[thread overview]
Message-ID: <ad44458e-acbe-1bf2-05b5-5a76d55833db@redhat.com> (raw)
In-Reply-To: <20170921131746.ewi7fwiegufa77mn@rh_laptop>

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.

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).

> _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,
Florian

  reply	other threads:[~2017-09-21 13:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-18 15:52 [PATCH 0/7][RFC] Introduce fallocate query support mode Lukas Czerner
2017-09-18 15:52 ` [PATCH 1/7] vfs: " Lukas Czerner
2017-09-18 15:52 ` [PATCH 2/7] ext4: Implement " Lukas Czerner
2017-09-18 15:52 ` [PATCH 3/7] ext4: Remove unnecessary S_ISREG checks in fallocate operations Lukas Czerner
2017-09-18 15:52 ` [PATCH 4/7] xfs: Implement fallocate query support mode Lukas Czerner
2017-09-18 17:56   ` Christoph Hellwig
2017-09-19  3:28     ` OGAWA Hirofumi
2017-09-19  8:15     ` Lukas Czerner
2017-09-19 14:13       ` Christoph Hellwig
2017-09-18 20:48   ` Darrick J. Wong
2017-09-18 21:55     ` Andreas Dilger
2017-09-19 14:55       ` Theodore Ts'o
2017-09-19 15:33         ` Lukas Czerner
2017-09-19 15:55         ` Christoph Hellwig
2017-09-19 19:17           ` Florian Weimer
2017-09-19 20:37             ` Christoph Hellwig
2017-09-19 23:17               ` Theodore Ts'o
2017-09-21 13:17                 ` pathconf syscall for linux Lukas Czerner
2017-09-21 13:49                   ` Florian Weimer [this message]
2017-09-22  8:38                     ` Lukas Czerner
2017-09-21 13:54                 ` [PATCH 4/7] xfs: Implement fallocate query support mode Florian Weimer
2017-09-22  8:40                   ` Lukas Czerner
2017-09-19  8:20     ` Lukas Czerner
2017-09-18 15:52 ` [PATCH 5/7] fat: " Lukas Czerner
2017-09-18 15:52 ` [PATCH 6/7] gfs2: " Lukas Czerner
2017-09-18 15:52 ` [PATCH 7/7] loop: Check for puch hole and zero range support specifically Lukas Czerner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ad44458e-acbe-1bf2-05b5-5a76d55833db@redhat.com \
    --to=fweimer@redhat.com \
    --cc=adilger@dilger.ca \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=lczerner@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).