On Nov 11, 2013, at 5:30 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Sun, Nov 10, 2013 at 02:56:54AM -0500, David Turner wrote:
>> b. Use Andreas's encoding, which is incompatible with pre-1970 files
>> written on 64-bit systems.
>> 
>> 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?).
> 
> I agree, I think this is the best way to go.  I'm going to drop your
> earlier patch, and wait for an updated patch from you.  It may miss
> this merge window, but as Andreas has pointed out, we still have a few
> years to get this right.  :-)

Since this change would immediately break files encoded with pre-1970 dates
on ext4 filesystems, should there be a transition period where both pre-1970
dates (with extra epoch bits == 0x3 in the current encoding) and post-2378
(with extra epoch bits == 0x3 in the new encoding) are decoded as being
pre-1970?  That could be conditional until some release in the future (e.g.
>= Linux 4.20, at least 5 years away) to give folks a chance to run the new
e2fsck to fix up those files.

Are there really any ext4 filesystems that have files with valid dates so old?
I don’t want to break anyone’s data, but if this extra complexity is completely
pointless then I’m also fine with this minor risk of breakage.

Cheers, Andreas