linux-kernel - Re: [PATCH v2] ext4: set csum seed in tmp inode while migrating to extents

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Yc1YMUryayqc8fUk@mit.edu>
Date:   Thu, 30 Dec 2021 01:56:49 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Pavel Machek <pavel@....cz>
Cc:     Lukas Czerner <lczerner@...hat.com>, Jan Kara <jack@...e.cz>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Luís Henriques <lhenriques@...e.de>,
        Andreas Dilger <adilger.kernel@...ger.ca>,
        linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org,
        Jeroen van Wolffelaar <jeroen@...ffelaar.nl>
Subject: Re: [PATCH v2] ext4: set csum seed in tmp inode while migrating to
 extents

On Tue, Dec 28, 2021 at 11:40:17PM +0100, Pavel Machek wrote:
> > Our rationale behind not supporting the migration was always the fact
> > that we felt that backup was absolutely necessary before operation like
> > this. When you already have up-to-date backup available you might as
> > well create a fresh ext4 file system with all the advantages it brings
> > and recover data from said backup. I think this is still a very
> > reasonable approach.
> 
> Umm. Not really?
> 
> First... full backup/restore will take a _long_ time.

How big is an ext3 file system going to be, though?  Ext4 was
available in RHEL 5, and was fully supported in RHEL 6 --- which was
released in the year 2000.  Back in 2000, the biggest Seagate
Barracuda drive you could get was 30GB.  The biggest disk available at
that time was the IBM Deskstar 75GXP, which was 75GB.

So a 5 disk RAID array from the era where you might have still been
using ext3 *might* have been as large as 300GB.

> Second... if you do online migration, you have filesystem you are
> quite unlikely to corrupt, and backup you are unlikely to use. If you
> do backup/restore, you have to be _way_ more careful that backup media
> is reliable etc.

21 years later, those IDE disks are probably not even functioning any
more.  Every 4-7 years, depending on how careful you want to be, you'd
would be well-advised to buy new hard drives, since back then disk
drive capacities were doubling every 18-24 months.  And so the sane
thing to do would be to do a disk-to-disk transfer.  That is, you buy
a new computer, with brand new hard drives, install the latest distro
(many companies would only upgrade distros when they upgraded their
hardware), and so you'd format new hard drives with the latest file
system, and do a disk-to-disk transfer from the old system to the new
system.

Quite frankly, if you aren't willing to copy the data from your
ancient spinning rust platters (and back then, they probably *were*
actually iron oxide :-), your largest risk would be the HDD
self-destructing from extreme old age.  :-)

							- Ted