linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hugo Mills <hugo@carfax.org.uk>
To: Hubert Kario <hka@qbs.com.pl>
Cc: Duncan <1i5t5.duncan@cox.net>,
	linux-btrfs@vger.kernel.org, chris.mason@oracle.com,
	josef@redhat.com
Subject: Re: Interpreting Output of "btrfs fi show"
Date: Sun, 29 Apr 2012 19:34:27 +0100	[thread overview]
Message-ID: <20120429183427.GL6172@carfax.org.uk> (raw)
In-Reply-To: <8118972.tgkAvno4mK@bursa22>

[-- Attachment #1: Type: text/plain, Size: 2343 bytes --]

On Sat, Apr 28, 2012 at 06:42:52PM +0200, Hubert Kario wrote:
> On Thursday 26 of April 2012 20:54:47 Duncan wrote:
> > Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
> > > Hallo, Bart,
> > >> 
> > >> Well I think there is a btrfs superblock still present from the
> > >> full-disk filesystem. Due to the offset of the first partition from the
> > >> start of the disk, this superblock was not overwritten when you created
> > >> the filesystem inside the partition.
> > > 
> > > Sounds familiar ...
> > > 
> > > I now use to delete about the first 10 MByte of the target disk via "dd
> > > if=/dev/zero"
> > 
> > But /unlike/ reiserfs, which was only affected with the well warned as
> > don't-use-unless-you-have-to fsck --rebuild-tree option, it seems that
> > due to btrfs scan, etc, btrfs has its similar problem in more routine
> > operation.
> 
> I'd say that this kind of problem is basically impossible in btrfs because 
> of FS UUID written all over the tree.
> 
> What we see here, is a superblock that is written in *very* specific place 
> on the partition, that just is aligned in place that makes the whole disk 
> look like btrfs.
> 
> I don't think it's actually possible for btrfs to put a file with btrfs 
> filesystem image in place where it could seem like the basic block device 
> has btrfs /too/. It depends on whatever the metadata block is allocated 
> before data block on disk. It /may/ be possible in mixed data-metadata 
> allocation mode.
> Chris or Josef, can you confirm?

   It's actually even harder than that -- btrfs filesystems have the
FS UUID embedded in every single block of metadata, including the
superblock, so there's no way of mixing up two filesystems, even if
they actually occupy blocks on the same device (as in the scenario
above).

   However, this comes at a price, which is that a block-for-block
copy of a btrfs filesystem looks like it's a part of the original FS,
and you can't mount both the original and the copy on the same machine
at the same time.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- "What's so bad about being drunk?" "You ask a glass of water" ---  
                                                                         

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

  parent reply	other threads:[~2012-04-29 18:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-26  2:34 Interpreting Output of "btrfs fi show" Thomas Rohwer
2012-04-26  8:34 ` Bart Noordervliet
2012-04-26  9:06   ` Thomas Rohwer
2012-04-26 10:04     ` Bart Noordervliet
2012-04-26 10:14       ` Thomas Rohwer
2012-04-26 11:11       ` Helmut Hullen
2012-04-26 11:53         ` David Sterba
2012-04-26 13:59           ` Helmut Hullen
2012-04-26 20:54         ` Duncan
2012-04-28 16:42           ` Hubert Kario
2012-04-29  4:15             ` Duncan
2012-04-30 17:03               ` Hubert Kario
2012-04-29 18:34             ` Hugo Mills [this message]
2012-04-29  6:13       ` Martin Steigerwald
2012-04-30 17:10         ` Hubert Kario
2012-04-30 18:12           ` Mike Fleetwood

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=20120429183427.GL6172@carfax.org.uk \
    --to=hugo@carfax.org.uk \
    --cc=1i5t5.duncan@cox.net \
    --cc=chris.mason@oracle.com \
    --cc=hka@qbs.com.pl \
    --cc=josef@redhat.com \
    --cc=linux-btrfs@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).