xfs
[Top] [All Lists]

Re: [RFC 11/32] xfs: convert to struct inode_time

To: Arnd Bergmann <arnd@xxxxxxxx>
Subject: Re: [RFC 11/32] xfs: convert to struct inode_time
From: Theodore Ts'o <tytso@xxxxxxx>
Date: Mon, 2 Jun 2014 09:15:55 -0400
Cc: Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, joseph@xxxxxxxxxxxxxxxx, john.stultz@xxxxxxxxxx, hch@xxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, geert@xxxxxxxxxxxxxx, lftan@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=1TtxTK+LMLweW6LeRm+yCZK7qhIvg8Ti1lCj0xP882Q=; b=ygsFxFAAvGdGpO+WVrOQ3ANgbEjnKUbBNDR+8jZsphH6YOcW764dQGcQT+21gSfd+u4bmNDW1FfOjFOrzzjROWRmNyvqMgFsbGwcIm+bDuXBI4n++40KbQV3VFzE7GN9ZJzSLkjL8qxxCFQ6l6zMopqNS1RE0k6zRwRa0BW5HAw=;
In-reply-to: <4910284.a72lauVLNV@wuerfel>
Mail-followup-to: Theodore Ts'o <tytso@xxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, Nicolas Pitre <nicolas.pitre@xxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, joseph@xxxxxxxxxxxxxxxx, john.stultz@xxxxxxxxxx, hch@xxxxxxxxxxxxx, tglx@xxxxxxxxxxxxx, geert@xxxxxxxxxxxxxx, lftan@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
References: <1401480116-1973111-1-git-send-email-arnd@xxxxxxxx> <4178301.j9kWdGCRLC@wuerfel> <20140602115737.GB14276@xxxxxxxxx> <4910284.a72lauVLNV@wuerfel>
User-agent: Mutt/1.5.23 (2014-03-12)
On Mon, Jun 02, 2014 at 02:38:09PM +0200, Arnd Bergmann wrote:
> 
> "For new inodes we always reserve enough space for the kernel's known
> extended fields, but for inodes created with an old kernel this might
> not have been the case. None of the extended inode fields is critical
> for correct filesystem operation."
> 
> Do we have to worry about this for inodes that contain extended
> attributes and that get updated after 2038?

In practice, the extended timestamps was one of the first things added
to ext4, so the vast majority of ext4 file systems with inode sizes >
128 bytes will have room for the extended timestamps.  There are some
legacy ext3 file systems with 256-byte inodes (enabled for fast
sotrage of SELinux xattrs) that in theory, could have been converted
to ext4 and had enough xattrs so that the extended timestamps couldn't
be added.  That would be a vanishingly small use case, and in
practice, it's not likely to be the case for the embedded market.

I could imagine someone worrying about file systems originally
formatted using RHEL 4 post-2038 (perhaps running in a VM), but I
don't work for IBM any more, and hopefully even IBM would just tell
such customers that they need to suck it up, and do a
backup/reformat/restore pass.

Cheers,
                                                - Ted

<Prev in Thread] Current Thread [Next in Thread>