[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150930161112.GA16068@thunk.org>
Date: Wed, 30 Sep 2015 12:11:12 -0400
From: Theodore Ts'o <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: "Darrick J. Wong" <darrick.wong@...cle.com>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH] tune2fs: don't change UUID on a mounted metadata_csum fs
On Tue, Sep 29, 2015 at 07:21:08PM -0600, Andreas Dilger wrote:
>
> I don't see how changing the UUID for mounted file systems can work
> for metadata_csum file systems?
>
> Wouldn't this cause a checksum error for every piece of metadata?
Tune2fs tries to update every piece of metadata when you run a command
like "tune2fs -U random /dev/sda1". The danger is in the fact that
tune2fs is modifying every bit of metadata while the file system is
mounted.
If you do this with "debugfs -w -R "ssv uuid random" /dev/sda1", it
will break every metadata in the system, because it doesn't try to
update every bit of metadata.
I suppose a better choice might be to add a debugfs command which does
update the UUID, and use that command as an emergency override when
there's no other clean way of handling things. It's more understood
by users that using debugfs is inherently dangerous, where as it's not
quite as obvious that -f means "here be dragons". (Hence the
rationale of using "-f -f" which we've used in other cases.)
The problem with --force-uuid is that it means dragging in
getopt_long(), and having a fallback when compiling e2fsprogs on a
system that doesn't support getopt_long(), or if you are using a libc,
such as Bionic, dietlibc, etc., that doesn't have getopt_long().
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists