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

From: Andreas Dilger <adilger@dilger.ca>
To: David Turner <novalis@novalis.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	"Theodore Ts'o" <tytso@mit.edu>, Mark Harris <mhlk@osj.us>,
	Jan Kara <jack@suse.cz>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ext4: explain encoding of 34-bit a,c,mtime values
Date: Tue, 11 Feb 2014 00:07:33 -0700	[thread overview]
Message-ID: <A8F66E63-68C0-4363-BCB5-8CBD1AC777DA@dilger.ca> (raw)
In-Reply-To: <1392095546.10065.56.camel@chiang>

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

On Feb 10, 2014, at 10:12 PM, David Turner <novalis@novalis.org> wrote:
> On Tue, 2014-01-21 at 22:22 -0800, Darrick J. Wong wrote:
>> On Mon, Nov 11, 2013 at 07:30:18PM -0500, Theodore Ts'o 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.  :-)
>> 
>> Just out of curiosity, did this (updated patch) ever happen?
> 
> I think I sent a usable patch that Ted merged part of into e2fscktools;
> the kernel portion was dropped for some reason.
> 
> While I was waiting to hear back on the kernel portion, I started
> looking into the dtime stuff, but then I got distracted by a new job.
> 
> Assuming that I won't have time to deal with dtime (since it seems to be
> much more complicated), is the right way forward for me to rebase the
> non-dtime portion of my patch against the latest kernel, and resend it?
> If so, will it get merged?  (Assume here that I do the same with the
> e2fsck stuff)

Yes, please submit an updated patch for the kernel.  Ted will hopefully
merge it this time.

I don't know that we really care about dtime so much, since it is mostly
just treated as "zero == not deleted" and "non-zero == deleted" by e2fsck,
and maybe useful for manual debugging.  We might consider that it uses a
sliding window in the future, since I'm sure we won't care about files
deleted more than 70 years ago, and if we did the fact that they appear
to be files deleted 70 years in the future won't matter so much.  In any
case, that can be looked at in a separate patch.

Cheers, Andreas

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 833 bytes --]