From: Theodore Ts'o <tytso@mit.edu>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: David Lang <david@lang.hm>,
Daniel Phillips <daniel.raymond.phillips@gmail.com>,
linux-kernel@vger.kernel.org, tux3@tux3.org,
linux-fsdevel@vger.kernel.org
Subject: Re: Tux3 Report: Initial fsck has landed
Date: Mon, 28 Jan 2013 20:40:00 -0500 [thread overview]
Message-ID: <20130129014000.GA7003@thunk.org> (raw)
In-Reply-To: <20130129002011.GA4757@blackbox.djwong.org>
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:
> > On Mon, 28 Jan 2013, Theodore Ts'o wrote:
> >
> > >On Sun, Jan 27, 2013 at 10:13:37PM -0800, Daniel Phillips wrote:
> > >>>The thing that jumps out at me with this is the question of how you will
> > >>>avoid the 'filesystem image in a file' disaster that reiserfs had (where
> > >>>it's fsck could mix up metadata chunks from the main filesystem with
> > >>>metadata chunks from any filesystem images that it happened to stumble
> > >>>across when scanning the disk)
>
> Did that ever get fixed in reiserfs?
Not in resierfs, but this was something that Hans did change for
reiserfs4.
> > 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")
- Ted
next prev parent reply other threads:[~2013-01-29 1:40 UTC|newest]
Thread overview: 17+ 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-29 0:20 ` Darrick J. Wong
2013-01-29 1:40 ` Theodore Ts'o [this message]
2013-01-29 4:34 ` Daniel Phillips
2013-03-19 23:00 ` Martin Steigerwald
2013-03-20 4:04 ` David Lang
2013-03-20 4:08 ` Daniel Phillips
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=20130129014000.GA7003@thunk.org \
--to=tytso@mit.edu \
--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@tux3.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).