From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751833AbaDAC4X (ORCPT ); Mon, 31 Mar 2014 22:56:23 -0400 Received: from imap.thunk.org ([74.207.234.97]:48086 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751787AbaDAC4S (ORCPT ); Mon, 31 Mar 2014 22:56:18 -0400 Date: Mon, 31 Mar 2014 22:56:10 -0400 From: "Theodore Ts'o" To: Conrad Meyer Cc: Andreas Dilger , Conrad Meyer , Andreas Dilger , "linux-ext4@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] fs: ext4: Sign-extend tv_sec after ORing in epoch bits Message-ID: <20140401025610.GG4911@thunk.org> Mail-Followup-To: Theodore Ts'o , Conrad Meyer , Andreas Dilger , Conrad Meyer , Andreas Dilger , "linux-ext4@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <1396191514-19081-1-git-send-email-cse.cem@gmail.com> <38140D27-E451-4BF1-9445-D319652E1BCF@dilger.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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