[Tux3] Tux3 time format

[Daniel Phillips]

Changesets 381 and on add time field updating to tux3 and tux3fuse:

   http://tux3.org/tux3

This can be verified by the fact that ls -l now shows correct dates
for a fuse-mounted Tux3 filesystem, and even has subsecond resolution.

Commands to test this:

   make && make mkfs && make defuse 

Then in another terminal:

   sudo su
   cd /tmp && touch test/foo && ls -l test

or

   stat test/foo

(The "make defuse" target mounts a test filesystem on /tmp/test.  You
need to be root to work on it, because permissions are not implemented
properly yet.)

Tux3 times are represented in fixed point fractions, as opposed to the
more common representation of separate integer seconds and decimal
fraction fields as used by libc and most or everywhere in kernel.  That
never made sense to me, I really think it would have been better if
decimal fractions had died along with BCD and Nixie tubes.  Fixed point
fractions are altogether better for arithmetic and verifiable code.

At the moment the format is 32.32, that is, 32 bits of integer seconds
and 32 bits of binary fraction for in-memory "tuxtime".  But that is
probably not quite right because it fails to avoid the 2037 overflow
problem.  There are a few ways we could deal with that.  Probably the
easiest is just to give another bit or two to the integer field, for
example, 33.31 format, which leaves us with the year 2015 problem, or
34.30 which yields the 2241 problem, long after most of use will not
care about it very much any more.  Or another way of looking at it is,
it should be enough time to come up with a backward compatible version
that has greater date range.

Another way to to extend the date range is to assume unsigned instead
of signed date values internal to Tux3.  This by itself gets us to 2015
with 32.32 format, at the expense of not being able to represent dates
before 1969.  Does anybody care?  Another option is to represent dates
relative to the creation date of the filesystem, and the creation date
can have higher range.  These are all just slight tweaks, and we have
lots of time to fiddle with this.  Suggestions welcome.

Dates are stored in inode table blocks in 32.16 format, sacrificing
some precision to save two bytes per date field.  Is it worth it?  I
can't say for sure, but I think it is and this is easy to change if I
turn out to be wrong.  A 32.16 field gives a resolution of 1/(2**16)
seconds.  If we take away a bit for higher range, that is 1/(2**15) or
better than one part in thirty thousand.  My feeling is, if somebody
needs higher resolution than that for a filesystem timestamp, they are
probably doing something wrong.

Regards,

Daniel

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3