[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 2/3] ls: use statx for loop detection if it's available
From: |
Jeff Layton |
Subject: |
Re: [PATCH 2/3] ls: use statx for loop detection if it's available |
Date: |
Fri, 13 Sep 2019 13:15:09 -0400 |
User-agent: |
Evolution 3.32.4 (3.32.4-1.fc30) |
On Fri, 2019-09-13 at 17:31 +0100, Pádraig Brady wrote:
> On 13/09/19 11:08, Jeff Layton wrote:
> > On Thu, 2019-09-12 at 11:58 -0600, Andreas Dilger wrote:
> > > Should this have a runtime fallback to stat() if statx() is not
> > > implemented
> > > on the running kernel, or is that already handled at another level?
> > >
> >
> > glibc already does this fallback.
>
> Note we need to be portable to a lot more than glibc
>
To my knowledge, only glibc has a statx wrapper so far, so others should
just end up using the non-statx-enabled codepaths.
I'd argue that a libc implementation that provided a statx that didn't
fall back when run on an legacy kernel could be considered broken.
> In general this patchset looks really useful,
> and the performance testing on ceph is really appreciated.
Yeah, it's always nice to see when these sorts of patches make a marked
difference. While I didn't measure it, I suspect that the "ls" commands
themselves also ran faster in this test, since they wouldn't have had to
make as many round trips to the MDS.
Note that I expect this set may also help on NFS, and Andreas said this
should help Lustre too. Not sure about other netfs' yet, but I wouldn't
expect this to perform any worse than the stat() variant does anywhere.
Thanks,
--
Jeff Layton <address@hidden>
[PATCH 3/3] ls: add statx-enabled variants of stat and lstat calls, Jeff Layton, 2019/09/11