From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Date: Sat, 31 May 2014 18:20:43 +0200 Subject: [Cluster-devel] [RFC 00/32] making inode time stamps y2038 ready In-Reply-To: <6347520.8jMPlVsFjM@wuerfel> References: <1401480116-1973111-1-git-send-email-arnd@arndb.de> <20140531145114.GA3721@localhost.localdomain> <6347520.8jMPlVsFjM@wuerfel> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Sat, May 31, 2014 at 5:23 PM, Arnd Bergmann wrote: > On Saturday 31 May 2014 16:51:15 Richard Cochran wrote: >> On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote: >> > I picked this because it is a fairly isolated problem, as the >> > inode time stamps are rarely assigned to any other time values. >> > As a byproduct of this work, I documented for each of the file >> > systems we support how long the on-disk format can work[1]. >> >> Why are some of the time stamp expiration dates marked as "never"? > > It's an approximation: > with 64-bit timestamps, you can represent close to 300 billion > years, which is way past the time that our planet can sustain > life of any form[1]. FWIW, the 48-bit second limit of befs marked never happens sooner than the 32-bit day limit of affs marked as Y11760870. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds