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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.