lkml.org 
[lkml]   [2010]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 02/18] xstat: Add a pair of system calls to make extended file stats available [ver #6]
Date
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


\
 
 \ /
  Last update: 2010-07-16 15:35    [W:0.325 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site