linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Conrad Meyer <cse.cem@gmail.com>
Cc: Andreas Dilger <adilger@dilger.ca>, Conrad Meyer <cemeyer@uw.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fs: ext4: Sign-extend tv_sec after ORing in epoch bits
Date: Mon, 31 Mar 2014 22:56:10 -0400	[thread overview]
Message-ID: <20140401025610.GG4911@thunk.org> (raw)
In-Reply-To: <CAG6CVpX57PFG7wUofHW4BPR_FY-ewv8+7P5baXgF9jd-gMOwmQ@mail.gmail.com>

On Mon, Mar 31, 2014 at 08:42:06AM -0700, Conrad Meyer wrote:
> The problem exists in mainline (v3.14) and linux-next (20140328), so
> it looks like it didn't land. Unless it's queued in an ext4 tree and
> didn't get selected for Linus for some reason?

There were some proposals for a different encoding that would be
better, that would have required some e2fsprogs changes.  Since this
is a long range problem (that doesn't hit until 2038) it's not been
high priority to deal with, but I haven't forgotten it.  I've just had
higher priority items on my todo list.

The huge long thread can be found here:

    http://thread.gmane.org/gmane.comp.file-systems.ext4/40978

What this is blocked on is I wanted to have some better ways of
setting times using the old and the proposed new encoding convention,
so we could have proper regression tests for the changes in e2fsck.
That way we can make sure the right thing really happens with 32-bit
kernels, 64-bit kernels, 32-bit e2fsprogs, 64-bit e2fsprogs, etc.,
with file systems using both the old and the newer encoding.

(Yes, I'm paranoid that way.  Regression tests are _important_.)

      	  	   	      		       	   - Ted

      reply	other threads:[~2014-04-01  2:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-30 14:58 [PATCH] fs: ext4: Sign-extend tv_sec after ORing in epoch bits Conrad Meyer
2014-03-31 15:34 ` Andreas Dilger
2014-03-31 15:42   ` Conrad Meyer
2014-04-01  2:56     ` Theodore Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140401025610.GG4911@thunk.org \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=adilger@dilger.ca \
    --cc=cemeyer@uw.edu \
    --cc=cse.cem@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).