Re: [XFS SUMMIT] Deprecating V4 on-disk format

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 25, 2020 at 9:12 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
>
> 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@xxxxxxxxxxxxx> é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
>

I can help with review. Already looked at your branch.

Thanks,
Amir.




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux