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 <[EMAIL PROTECTED]> 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 > [email protected] > http://tux3.org/cgi-bin/mailman/listinfo/tux3 > _______________________________________________ Tux3 mailing list [email protected] http://tux3.org/cgi-bin/mailman/listinfo/tux3
