[Tux3] Time fields in Tux3

[Daniel Phillips]

Hi,

Compared to other things this is a minor matter, but I thought it is
worth a post to help make sure that what I have in mind meets people's
needs.  It turns out that time fields, specifically ctime and mtime,
account for a significant part of a Tux3 inode.  We try not to store
redundant time fields, so in situations where ctime and mtime are the
same (like after every file write) we only store ctime.  Just ctime
accounts for 13% of a newly created Tux3 inode, so you see why I worry
about bytes.  At 46 bytes, a Tux3 inode is the tiniest on the planet
(probably) and we would like to keep it that way.

Executive summary: I plan to use 48 bit fields to store times in Tux3,
with a resolution of 1/(2^16) seconds relative to the time a given
filesystem was created.  This means that Tux3 times are good for

   2**48 / (2**16 * 24 * 3600 * 365.25) = 136 years

from the time you create your filesystem, which should be enough time
to improve Tux3 with higher precision time attributes.  We will keep
compatibility with existing volumes of course.

So my question to all is, does resolution of 1/16th of a millisecond
work for you?  Note my nascent feeling of inadequacy here: XFS uses
billionths of seconds and ZFS boils the oceans.  Tux3 aims to save
bytes while still offering decent time resolution and range.

Like everything else in Tux3, time fields are versioned.  It happens to
be convenient to pack a version plus attribute type tag (14 bits) in
with the time, leaving 50 bits available in an 8 byte field.  I
actually use 48 bits because that is an even six bytes, but could use
all 50 available bits if it is thought to matter.  Or I can just add
another couple of bytes to the field to store full 64 bit times,
bringing the ctime field 16% of a basic inode.

I plan to store atimes as 32 bit quantities with one second resolution,
less than ctime and mtime.  This is because atime has always had that
resolution and was a poorly conceived idea from the start.  It is not
my intention to improve atime, but simply to support it as a legacy
feature.

Regards,

Daniel

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