From: Theodore Ts'o <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] tune2fs: don't change UUID on a mounted metadata_csum fs
Date: Wed, 30 Sep 2015 12:11:12 -0400 [thread overview]
Message-ID: <20150930161112.GA16068@thunk.org> (raw)
In-Reply-To: <8B6E949A-7397-49BB-84BC-72479FE0F7A7@dilger.ca>
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
prev parent reply other threads:[~2015-09-30 16:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 15:31 [PATCH] tune2fs: don't change UUID on a mounted metadata_csum fs Darrick J. Wong
2015-09-29 22:46 ` Theodore Ts'o
2015-09-30 1:21 ` Andreas Dilger
2015-09-30 16:11 ` Theodore Ts'o [this message]
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=20150930161112.GA16068@thunk.org \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=darrick.wong@oracle.com \
--cc=linux-ext4@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).