-------- Original Message --------
Subject: Re: [PATCH 0/8] Introduce offline fsid/chunk tree uuid change
for btrfstune.
From: David Sterba <dsterba@xxxxxxx>
To: Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>
Date: 2015年05月06日 23:43
On Wed, May 06, 2015 at 08:49:33AM +0800, Qu Wenruo wrote:
Code looks good to me. I'm not sure whether it should land in btrfstune
or in 'btrfs' proper.
* btrfstune should go away at some point, so I'd rather not add new
features there
* 'btrfs property set -t filesystem uuid' seems best to me at this moment
Good idea.
I'll change it to property in next version.
I've realized this later on. The original purpose of the properties is
to manipulate objects on a mounted filesystem, so this might need some
adjustnments on the progs side. I'd really want to avoid another
separate tool, so we should make sure that the interface is sane even if
it could mix online/offline filesystem changes.
That's the original reason why I put these codes into btrfstune.
But that should not be a big problem. (See below)
Respecting the current syntax, the way to set the uuid is:
btrfs prop set -t filesytem /dev/sdx uuid ...UUID...
In this special case, the property handler should check if the device is
unmounted (and is a btrfs filesystem) and then do the rest.
This is one good idea, but I'm afraid it may still be confusing.
And things may get even worse when we try to move everything into
btrfs-prop,
E.g. if we auto move seeding flag to prop, we must give a quite detailed
explain on which property is offline.
So I prefer to add a new type called offline, and put uuid change with
other btrfstune function into this type.
IMHO this should provide a good explain on which is online and which is
offline.
How do you think about this method?
Thanks,
Qu
A minor suggestion: set BTRFS_SUPER_FLAG_ERROR on the filesystem during
the conversion and drop it after it finishes successfully. It's merely a
hint that there's something wrong with the filesytem, the mount will
fail because filesystem uuid would not match the device id.
Nice idea too.
But I'd like to use more specific flags like
BTRFS_SUPER_FLAG_UUID_CHANGING to give better info if kernel can't mount it.
Yeah that would be better and we'd use that for the on-line uuid change
as well. I've outlined the idea here
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Filesystem_UUID_change_-_on-line
The code should really support only 2 UUIDs, so we should check if the
UUIDs specified by user matches one of them if the superblock flag is
set. Ie. a partial uuid conversion must be finished before another
UUID change (though it's a rare case, we have to be ready for that).
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
