All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Emmanuel Florac <eflorac@intellique.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>, linux-xfs@vger.kernel.org
Subject: Re: [XFS SUMMIT] Deprecating V4 on-disk format
Date: Mon, 25 May 2020 13:23:54 +1000	[thread overview]
Message-ID: <20200525032354.GV2040@dread.disaster.area> (raw)
In-Reply-To: <20200520151510.11837539@harpe.intellique.com>

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...

> 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...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2020-05-25  3:23 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 [this message]
2020-05-25  6:08         ` Darrick J. Wong
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=20200525032354.GV2040@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.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.