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

[David Howells]

Arnd Bergmann <arnd@xxxxxxxx> 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?

> 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?

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.

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

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...

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/