[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211228224017.GA2242@duo.ucw.cz>
Date: Tue, 28 Dec 2021 23:40:17 +0100
From: Pavel Machek <pavel@....cz>
To: Lukas Czerner <lczerner@...hat.com>
Cc: Theodore Ts'o <tytso@....edu>, 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
Hi!
> > So the question is, is it worth it to continue supporting the migrate
> > feature, or should we just delete all of the migration code, and risk
> > users complaining that we've broken their use case? The chances of
> > that happening is admittedly low, and Linus's rule that "it's only
> > breaking userspace if a user complains" means we might very well get
> > away with it. :-)
>
> That's a very good summary Ted, thanks.
>
> 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.
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.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)
Powered by blists - more mailing lists