Re: [GIT PULL] vfs dio

[Christian Brauner <brauner@kernel.org>]

On Mon, Jan 20, 2025 at 11:24:56AM -0800, Linus Torvalds wrote:
> On Sat, 18 Jan 2025 at 05:09, Christian Brauner <brauner@kernel.org> wrote:
> >
> > Add a separate dio read align field to statx, as many out of place write
> > file systems can easily do reads aligned to the device sector size, but
> > require bigger alignment for writes.
> 
> I've pulled this, but it needs some fixing.
> 
> You added the 'dio_read_offset_align' field to 'struct kstat', and
> that structure is *critical*, because it's used even for the real
> 'stat()' calls that people actually use (as opposed to the statx side
> that is seldom a real issue).
> 
> And that field was added in a way that causes the struct to grow due
> to alignment issues.  For no good reason, because there were existing
> holes in there.
> 
> So please just fix it.

Right, sorry I should've noticed that during review.

> I despise the whole statx thing exactly because it has (approximately)
> five specialized users, while slowing down regular stat/fstat that is
> used widely absolutely *evertwhere*.
> 
> Of course, judging by past performance, I wouldn't be surprised if
> glibc has screwed the pooch, and decided to use 'statx()' to implement
> stat, together with extra pointless user space overhead to convert one
> into the other. Because that's the glibc way (ie the whole "turn
> fstat() into the much slower fstatat() call, just because").
> 
> So here's the deal: 'statx()' is *not* an "improved stat". It's an
> actively worse stat() for people who need very unusual and specialized
> information, and it makes everything else worse.

Yes, I'm well aware that you dislike statx(). :) It is heavily used
nowadays though because there's a few additional bits in there that
don't require calling into filesystems but are heavily used.

I want to reiterate that if I'd been involved in statx() I would've done
it as an extensible struct. So v1 of the struct would just be exactly
what stat() was.

This way neither copy-in nor copy-out would have done any unnecessary
work and perf would've been the same. Only when userspace actually
needed additional information it would have to pass in a larger struct
and pay the price for copy-in and copy-out.

I'll get you a new PR soon!