Re: [PATCH v3 4/4] stat: support statx DONT_SYNC and FORCE_SYNC flags

[Jeff Layton]

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 <address@hidden>