On Mon, 2019-04-29 at 09:40 -0700, Pádraig Brady wrote:
> On 23/04/19 04:59, Jeff Layton wrote:
> > > +#if HAVE_STATX && defined STATX_INO
> > > + fputs (_("\
> > > + -D, --dont-sync don't synchronize with server (for network
> > > fs')\n\
> > > + -F, --force-sync force synchronization with server (for network
> > > fs')\n\
> > > +"), stdout);
> > > +#endif
> > > fputs (_("\
> > > -c --format=FORMAT use the specified FORMAT instead of the
> > > default;\n\
> > > output a newline after each use of FORMAT\n\
> > > @@ -1916,7 +1937,7 @@ main (int argc, char *argv[])
> > >
> > > atexit (close_stdout);
> > >
> > > - while ((c = getopt_long (argc, argv, "c:fLt", long_options, NULL)) !=
> > > -1)
> > > + while ((c = getopt_long (argc, argv, "c:DfFLt", long_options, NULL))
> > > != -1)
> >
> > Hmm...we'll probably want to use a different string if HAVE_STATX is
> > not defined. Fixed in my tree, but I'll refrain from resending until I
> > get some other feedback on this.
> >
> > BTW, ping on this? I'd like to know whether this patchset is
> > reasonable, as I was planning to use this functionality to write some
> > tests for cephfs.
>
> If we need a flag to control this at all, it should probably be
> a single long format option with parameters, and no corresponding short
> option.
> Also we want to avoid the ambiguity of implying a (data) sync is invoked.
> Perhaps something like:
>
> --cached={default,never,always}
>
I sent a new set a little while ago. Let me know what you think.
> In general I think the statx interface is useful,
> as file systems are tending to be more distributed over time.
>
> I was thinking that statx could be emulated with stat where necessary,
> and we could move that implementation from stat.c to gl/lib/ to gnulib/
> if statx has enough advantages for general use.
>
glibc already does this when the kernel doesn't provide statx, so I
don't think we'll need anything special here.
Thanks,
--
Jeff Layton <[email protected]>
