From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Emmanuel Florac <eflorac@intellique.com>, linux-xfs@vger.kernel.org
Subject: Re: [XFS SUMMIT] Deprecating V4 on-disk format
Date: Sun, 24 May 2020 23:08:04 -0700 [thread overview]
Message-ID: <20200525060804.GC252930@magnolia> (raw)
In-Reply-To: <20200525032354.GV2040@dread.disaster.area>
On Mon, May 25, 2020 at 01:23:54PM +1000, Dave Chinner wrote:
> On Wed, May 20, 2020 at 03:15:10PM +0200, Emmanuel Florac wrote:
> > Le Wed, 20 May 2020 11:14:30 +1000
> > Dave Chinner <david@fromorbit.com> écrivait:
> >
> > > Well, there's a difference between what a distro that heavily
> > > patches the upstream kernel is willing to support and what upstream
> > > supports. And, realistically, v4 is going to be around for at least
> > > one more major distro release, which means the distro support time
> > > window is still going to be in the order of 15 years.
> >
> > IIRC, RedHat/CentOS v.7.x shipped with a v5-capable mkfs.xfs, but
> > defaulted to v4. That means that unless you were extremely cautious
> > (like I am :) 99% of RH/COs v7 will be running v4 volumes for the
> > coming years. How many years, would you ask?
>
> Largely irrelevant to the question at hand, as support is dependent
> on the distro lifecycle here. Essentially whatever is in RHEL7 is
> supported by RH until the end of it's life.
>
> In RHEL8, we default to v5 filesystems, but fully support v4. That
> will be the case for the rest of it's life. Unless the user
> specifically asks for it, no new v4 filesystems are being created on
> current RHEL releases.
>
> If we were to deprecate v4 now, then it will be marked as deprecated
> in the next major RHEL release. That means it's still fully
> supported in that release for it's entire life, but it will be
> removed in the next major release after that. So we are still
> talking about at least 15+ years of enterprise distro support for
> the format, even if upstream drops it sooner...
We probably ought to do it sooner than later though, particularly if we
think/care about 5.9 turning into an LTS.
> > As for the lifecycle of a filesystem, I just ended support on a 40 TB
> > archival server I set up back in 2007. I still have a number of
> > supported systems from the years 2008-2010, and about a hundred from
> > 2010-2013. That's how reliable XFS is, unfortunately :)
>
> Yup, 10-15 years is pretty much the expected max life of storage
> systems before the hardware really needs to be retired. We made v5
> the default 5 years ago, so give it another 10 years (the sort of
> timeframe we are talking about here) and just about
> everything will be running v5 and that's when v4 can likely be
> dropped.
>
> The other thing to consider is that we need to drop v4 before we get
> to y2038 support issues as the format will never support dates
> beyond that. Essentially, we need to have the deprecation discussion
> and take action in the near future so that people have stopped using
> it before y2038 comes along and v4 filesystems break everything.
>
> Not enough people think long term when it comes to computers - it
> should be more obvious now why I brought this up for discussion...
Ok then, who would like to help me get the y2038 timestamp patches
reviewed for ~5.9? :D
(Anyone; not necessarily Dave)
--D
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
next prev parent reply other threads:[~2020-05-25 6:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-13 2:36 [XFS SUMMIT] Deprecating V4 on-disk format Dave Chinner
2020-05-19 6:23 ` Darrick J. Wong
2020-05-20 1:14 ` Dave Chinner
2020-05-20 13:15 ` Emmanuel Florac
2020-05-21 8:29 ` Mike Fleetwood
2020-05-26 17:16 ` Eric Sandeen
2020-05-25 3:23 ` Dave Chinner
2020-05-25 6:08 ` Darrick J. Wong [this message]
2020-05-25 7:02 ` Amir Goldstein
2020-05-25 10:01 ` Emmanuel Florac
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=20200525060804.GC252930@magnolia \
--to=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=eflorac@intellique.com \
--cc=linux-xfs@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