[Tux3] Tux3 time format

[Maciej Żenczykowski]

So part of the problem with this is that it doesn't deal correctly
with leap seconds (like the one happening on Dec 31, 2008) -
unfortunately, since the user-kernel interface is the way it is, I'm
not sure this is something that can really be fixed by a filesystem,
since the problem is really the posix interface, and besides
filesystems shouldn't be doing date-parsing of any kind...

On Tue, Nov 11, 2008 at 00:14, Daniel Phillips <phillips at phunq.net> wrote:
> 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
>

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