Re: [PATCH] ext4: explain encoding of 34-bit a,c,mtime values

[David Turner <novalis@novalis.org>]

On Sat, 2013-11-09 at 15:51 -0800, Mark Harris wrote:
> 
> The problem with the existing encoding is that pre-1970 dates are
> encoded with extra bits 1,1 in 64-bit kernels with ext4, but on 32-bit
> kernels and inodes that were originally written as ext3 the extra bits
> will be 0,0.  Currently, both are decoded as pre-1970 dates.
> 
> With your patch, only the 1,1 format used by 64-bit ext4 will decode
> as a pre-1970 date.  Dates previously written by ext3 or a 32-bit
> kernel will no longer be decoded as expected.  Also the patch does
> not update ext4_encode_extra_time to use this format for pre-1970
> dates in 32-bit mode.

You're right -- I missed the complexity here.

> Possible solutions were discussed here, but no decision was made:
> http://thread.gmane.org/gmane.comp.file-systems.ext4/26087/focus=26406

To summarize, the previous discussion offered four possible solutions,
of which two were thought good:

b. Use Andreas's encoding, which is incompatible with pre-1970 files
written on 64-bit systems.

c. Use an encoding which is compatible with all pre-1970 files, but
incompatible with 64-bit post-2038 files, and which encodes a smaller
range of time and is more complicated. 

-------
I don't care about currently-existing post-2038 files, because I believe
that nobody has a valid reason to have such files.  However, I do
believe that pre-1970 files are probably important to someone.

Despite this, I prefer option (b), because I think the simplicity is
valuable, and because I hate to give up date ranges (even ones that I
think we'll "never" need). Option (b) is not actually lossy, because we
could correct pre-1970 files with e2fsck; under Andreas's encoding,
their dates would be in the far future (and thus cannot be legitimate).

Would a patch that does (b) be accepted?  I would accompany it with a
patch to e2fsck (which I assume would also go to the ext4 developers
mailing list?).