This is the mail archive of the
mailing list for the glibc project.
Re: [PING] Avoid excessive buffer size in libio
- From: Florian Weimer <fweimer at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 29 Nov 2016 17:50:17 +0100
- Subject: Re: [PING] Avoid excessive buffer size in libio
- Authentication-results: sourceware.org; auth=none
- References: <56E17C8E.email@example.com> <20160311215230.B5AF32C3C1E@topped-with-meat.com> <56E69B9D.firstname.lastname@example.org> <20160318225258.7D1852C3C60@topped-with-meat.com> <56FCF883.email@example.com> <firstname.lastname@example.org> <email@example.com>
On 06/24/2016 05:35 PM, Florian Weimer wrote:
On 05/19/2016 04:57 PM, Florian Weimer wrote:
On 03/31/2016 12:14 PM, Florian Weimer wrote:
On 03/18/2016 11:52 PM, Roland McGrath wrote:
Whatever the results, they would not IMHO be relevant here.
POSIX specifies that st_blksize is the "preferred I/O block size for
object". It's the kernel's responsibility to give userland good advice
through this channel. If there are common buggy kernels that give bad
advice, that is a reason to apply upper and lower limits to the
the kernel. But the expectation should be that the kernel gets
give good advice, and the optimal thing to do with a good kernel is to
follow its advice.
Since the recommended use of st_blksize in this way is a standard user
feature and not just what stdio's implementation happens to do, there
argument to be made that the limiting of the value should be done in
*stat functions reported st_blksize values rather than in stdio's
them. (I'm ambivalent about this point.)
That's a good point. I'll try to get feedback from kernel file system
developers on this matter.
I wasn't able to get any feedback. Based on Rich's point about random
I/O and Roland's earlier suggestion, I'm just capping the reported
buffer size to 8192 in the attached patch.