On Fri, 8 Dec 2000, Konrad Schroder wrote:

> On Fri, 8 Dec 2000, Bill Studenmund wrote:
> 
> > No, you should include the ufs inode verison number as a parameter in the
> > superblock, as does ffs. That way changing the ufs inode doesn't mean
> > changing the lfs version. :-)
> 
> This isn't really an objection, but I was thinking of lfs_version as
> covering all of superblock, segsum, ifile, and inode version.  All of
> these things are really orthogonal but since they seldom change they might
> as well be lumped together.  It would be easy enough for fsck_lfs to
> convert v1->v2->v3 the same way that fsck_ffs can convert between inode
> formats.

Since the inode is shared with ufs, I'd suggest keeping the inode version
seperate. That way there is a common version number for both ffs & lfs
routines.

> Besides, if the UFS inode were to change to 64-bit times at some point,
> wouldn't FFS itself get a magic number change rather than an fs_inodefmt
> bump?  I seem to recall a discussion about big inodes wanting a new magic
> number, but I can't remember the reasoning at the moment.

That depends on how we support times beyond 2^31-1 seconds. Large indoes
would be one way. But large inodes would break bootloaders which
understand ffs. So we have to come up with a backwards-compatabile way.
And if we have it, it's not obvious that we have to go to large inodes.

The best one I've heard of so far is to take the 64-bits we have for time
(32 bits for seconds, 32 bits for nanoseconds) and shuffle them around. If
we decide that microsecond resolution is ok, then we only need 20 bits for
sub-second timing, and we have 44 bits for seconds. That will get us to
the year 559447 or so (I'm also assuming that the file system doesn't need
to encode dates before 1970 either).

If we decide we MUST have nanosecond resolution, we still could steal two
bits & go unsigned, and get us to 2514.

So we can get pretty far without changing the inode size. :-)

Take care,

Bill