From: Martin Steigerwald <Martin@lichtvoll.de>
To: tux3@phunq.net
Cc: Daniel Phillips <daniel.raymond.phillips@gmail.com>,
"Theodore Ts'o" <tytso@mit.edu>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
David Lang <david@lang.hm>,
linux-kernel@vger.kernel.org, tux3@tux3.org,
linux-fsdevel@vger.kernel.org
Subject: Re: Tux3 Report: Initial fsck has landed
Date: Wed, 20 Mar 2013 00:00:32 +0100 [thread overview]
Message-ID: <201303200000.33356.Martin@lichtvoll.de> (raw)
In-Reply-To: <CAEsagEhZkkr+G0gFr6rnsyjFmCckNMkOnTVcUMvaj8EHD-qGQw@mail.gmail.com>
Am Dienstag, 29. Januar 2013 schrieb Daniel Phillips:
> On Mon, Jan 28, 2013 at 5:40 PM, Theodore Ts'o <tytso@mit.edu> wrote:
> > On Mon, Jan 28, 2013 at 04:20:11PM -0800, Darrick J. Wong wrote:
> >> On Mon, Jan 28, 2013 at 03:27:38PM -0800, David Lang wrote:
> >> > The situation I'm thinking of is when dealing with VMs, you make a
> >> > filesystem image once and clone it multiple times. Won't that end up
> >> > with the same UUID in the superblock?
> >>
> >> Yes, but one ought to be able to change the UUID a la tune2fs
> >> -U. Even still... so long as the VM images have a different UUID
> >> than the fs that they live on, it ought to be fine.
> >
> > ... and this is something most system administrators should be
> > familiar with. For example, it's one of those things that Norton
> > Ghost when makes file system image copes (the equivalent of "tune2fs
> > -U random /dev/XXX")
>
> Hmm, maybe I missed something but it does not seem like a good idea
> to use the volume UID itself to generate unique-per-volume metadata
> hashes, if users expect to be able to change it. All the metadata hashes
> would need to be changed.
I believe that is what BTRFS is doing.
And yes, AFAIK there is no easy way to change the UUID of a BTRFS filesystems
after it was created.
Thanks,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
next prev parent reply other threads:[~2013-03-19 23:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-28 5:55 Tux3 Report: Initial fsck has landed Daniel Phillips
2013-01-28 6:02 ` David Lang
2013-01-28 6:13 ` Daniel Phillips
2013-01-28 14:12 ` Theodore Ts'o
2013-01-28 23:27 ` David Lang
2013-01-28 23:27 ` David Lang
2013-01-29 0:20 ` Darrick J. Wong
2013-01-29 1:40 ` Theodore Ts'o
2013-01-29 4:34 ` Daniel Phillips
2013-03-19 23:00 ` Martin Steigerwald [this message]
2013-03-20 4:04 ` David Lang
2013-03-20 4:04 ` David Lang
2013-03-20 4:08 ` Daniel Phillips
2013-03-20 4:08 ` Daniel Phillips
2013-03-20 10:29 ` Martin Steigerwald
2013-03-20 10:29 ` Martin Steigerwald
2013-03-20 6:54 ` Rob Landley
2013-03-21 1:49 ` Daniel Phillips
2013-03-22 1:57 ` Dave Chinner
2013-03-22 5:41 ` Daniel Phillips
2013-03-26 6:42 ` Christian Stroetmann
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=201303200000.33356.Martin@lichtvoll.de \
--to=martin@lichtvoll.de \
--cc=daniel.raymond.phillips@gmail.com \
--cc=darrick.wong@oracle.com \
--cc=david@lang.hm \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tux3@phunq.net \
--cc=tux3@tux3.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.