Re: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]

[Arnd Bergmann <arnd@arndb.de>]

On Friday 16 July 2010, David Howells wrote:
> Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > You could also define the tv_gran_units to be power-of-ten nanoseconds,
> > making it a decimal floating point number like 
> > 
> > enum {
> >       XSTAT_NANOSECONDS_GRANULARITY = 0,
> >       XSTAT_MICROSECONDS_GRANULARITY = 3,
> >       XSTAT_MILLISECONDS_GRANULARITY = 6,
> >       XSTAT_SECONDS_GRANULARITY = 9,
> > };
> 
> Are you thinking, then, of having tv_nsec be in terms of those units?

No, just tv_granularity. Most users won't need to care that this
is not a regular timespec then.

> > That would make it easier to define an xstat_time_before() function, though
> > it means that you could no longer do XSTAT_MINUTES_GRANULARITY and
> > higher directly other than { .tv_gran_units = 10, .tv_granularity = 6, }.
> 
> So you're thinking of indicating time (in)equality based on overlapping time
> granules?

Yes, for example rsync could use this to determine wether a local (e.g. FAT)
and a remote (e.g. NFS) file are identical or not. Right now, you can pass
the granularity in seconds as a command line argument, but it would be nice
to have rsync do this automatically if possible.

> Your suggestion would suffice, I think.  With a 2:2 split between exponent
> (tv_gran_units) and mantissa (tv_granularity), you can do:
> 
>         UNIT            SECONDS/UNIT    EXPONENT        MANTISSA
>         nanoseconds     0.000000001     -9              1
>         microseconds    0.000001        -6              1
>         millseconds     0.001           -3              1
>         seconds         1               0               1
>         minutes         60              1               6
>         hours           3600            2               36
>         days            86400           2               864
>         weeks           604800          2               6048
> 
> Any units beyond that are variable length and not worth considering, IMO.

right.
 
> And if you don't want negative numbers in your exponent, you can make the base
> unit nS instead of S.

either way works fine for me.

> Is it worth allowing a filesystem to indicate that it has granularity smaller
> than nS, even if the resolution can't be handled here?  We could even have:
> 
>         struct xstat_time {
>                 signed long long        tv_sec;         /* seconds */
>                 unsigned int            tv_nsec;        /* nanoseconds */
>                 unsigned char           tv_psec4;       /* picoseconds/4 */
>                 signed char             tv_gran_exp;    /* exponent */
>                 unsigned short          tv_gran_mant;   /* mantissa */
>         };
> 
> Though it's probably still an unnecessary extravagance to have the pS field.
> It's probably best left as padding for now; we can always change our minds
> later...

There are also two extra bits in tv_nsec ;-). No, I don't think we
need picoseconds any time soon.

One byte padding might not be the worst thing to have in here, like

        struct xstat_time {
                signed long long        tv_sec;         /* seconds */
                unsigned int            tv_nsec;        /* nanoseconds */
                unsigned short          tv_gran_mant;   /* mantissa */
                signed char             tv_gran_exp;    /* exponent */
                unsigned char           unused;
        };

	Arnd