All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [XFS SUMMIT] Deprecating V4 on-disk format
Date: Wed, 13 May 2020 12:36:18 +1000	[thread overview]
Message-ID: <20200513023618.GA2040@dread.disaster.area> (raw)


Topic: Deprecating V4 On-disk Format

Scope:
	Long term life cycle planning
	Supporting old filesystems with new kernels.
	Unfixable integrity issues in v4 format.
	Reducing feature matrix for testing

Proposal:

The CRC-enabled V5 format has been the upstream default format now
since commit 566ebd5ae5fa ("mkfs: default to CRC enabled
filesystems") dated May 11 2015 (5 years ago!) and released in
xfsprogs v3.2.3. It is the default in all major distros, and has
been for some time.

We know that the v4 format has unfixable integrity issues apart from
the obvious lack of CRCs and self-describing metadata structures; it
has race conditions in log recovery realted to inode creation and
other such issues that could only be solved with an on-disk format
change of some kind. We are not adding new features to v4 formats,
so anyone wanting to use new XFS features must use v5 format
filesystems.

We also know that the number of v4 filesysetms in production is
slowly decreasing as systems are replaced as part of the natural
life cycle of production systems.

All this adds up to the realisation that existing v4 filesystems are
effectively in the "Maintenance Mode" era of the software life
cycle. The next stage in the life cycle is "Phasing Out" before we
drop support for it altogether, also know around here as
"deprecated" which is a sign that support will "soon" cease.

I'd like to move the v4 format to the "deprecated" state as a signal
to users that it should really not be considered viable for new
systems. New systems running modern kernels and userspace should
all be using the v5 format, so this mostly only affects existing
filesystems.

Note: I am not proposing that we drop support for the v4 format any
time soon. What I am proposing is an "end of lifecycle" tag similar
to the way we use EXPERIMENTAL to indicate that the functionality is
available but we don't recommend it for production systems yet.

Hence what I am proposing is that we introduce a DEPRECATED alert at
mount time to inform users that the functionality exists, but it
will not be maintained indefinitely into the future. For distros
with a ten year support life, this means that a near-future release
will pick up the DEPRECATED tag but still support the filesystem for
the support life of that release. A "future +1" release may not
support the v4 format at all.

Discussion points:

- How practical is this?
- What should we have mkfs do when directed to create a v4 format
  filesystem?
- How long before we decide to remove v4 support from the upstream
  kernel and tools? 5 years after deprecation? 10 years?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

             reply	other threads:[~2020-05-13  2:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-13  2:36 Dave Chinner [this message]
2020-05-19  6:23 ` [XFS SUMMIT] Deprecating V4 on-disk format 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
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=20200513023618.GA2040@dread.disaster.area \
    --to=david@fromorbit.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.