linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Goffredo Baroncelli <kreijack@inwind.it>
To: util-linux@vger.kernel.org
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
	Chris Mason <chris.mason@fusionio.com>,
	Chris Murphy <lists@colorremedies.com>
Subject: [PATCH][v2] Btrfs: wipe all the superblock [redhat bugzilla 889888]
Date: Wed, 09 Jan 2013 22:14:43 +0100	[thread overview]
Message-ID: <50EDDDC3.10407@inwind.it> (raw)

Hi all,

Currently wipefs doesn't clear all the superblock of btrfs. Only the first 
one is cleared.

Btrfs has three superblocks. The first one is placed at 64KB, the second 
one at 64MB, the third one at 256GB.

If the first superblock is valid except that the "magic field" is zeroed,
btrfs skips the check of the other superblocks.
If the first superblock is fully invalid, btrfs checks for the other
superblock.

So zeroing the first superblock "magic field" at the beginning seems
that the filesystem is wiped. But when the first superblock is overwritten
(e.g. by another filesystem), then the other two superblocks may be considered
valid, and the filesystem may resurrect.


# make a filesystem, wipe it and check if it disappears

$ sudo mkfs.btrfs -L "Btrfs-test" /dev/loop0
$ sudo btrfs filesystem  show /dev/loop0
Label: 'Btrfs-test'  uuid: 3156cef7-8522-411f-876a-ba8ec32cc781
	Total devices 1 FS bytes used 28.00KB
	devid    1 size 4.00TB used 2.04GB path /dev/loop0

Btrfs Btrfs v0.19
$ sudo wipefs /dev/loop0
offset               type
----------------------------------------------------------------
0x10040              btrfs   [filesystem]
                     LABEL: Btrfs-test
                     UUID:  3156cef7-8522-411f-876a-ba8ec32cc781

$ sudo wipefs /dev/loop0 -a
8 bytes were erased at offset 0x10040 (btrfs)
they were: 5f 42 48 52 66 53 5f 4d
$ sudo btrfs filesystem  show /dev/loop0
Btrfs Btrfs v0.19

# it seems that the filesystem is disappeared # now zero all the 1st superblock

$ sudo dd if=/dev/zero of=/dev/loop0 bs=1 count=4k seek=64k
4096+0 records in
4096+0 records out
4096 bytes (4.1 kB) copied, 0.00659795 s, 621 kB/s

# check if the filesystem is resurrected
$ sudo btrfs filesystem  show /dev/loop0
failed to read /dev/sr0
Label: 'Btrfs-test'  uuid: 3156cef7-8522-411f-876a-ba8ec32cc781
	Total devices 1 FS bytes used 28.00KB
	devid    1 size 4.00TB used 2.04GB path /dev/loop0

Btrfs Btrfs v0.19

# it is !!!


# With this patch, wipefs is able to wipe all the superblock:

$ sudo mkfs.btrfs -L "Btrfs-test" /dev/loop0
$ sudo ~/btrfs/util-linux/wipefs /dev/loop0 offset               type
----------------------------------------------------------------
0x10040              btrfs   [filesystem]
                     LABEL: Btrfs-test
                     UUID:  5ca3239c-363c-4c28-b831-eac03cc5ca62

$ sudo ~/btrfs/util-linux/wipefs -a /dev/loop0 
/dev/loop0: 8 bytes were erased at offset 0x00010040 (btrfs): 	5f 42 48 52 66 53 5f 4d
/dev/loop0: 8 bytes were erased at offset 0x04000040 (btrfs):	5f 42 48 52 66 53 5f 4d
/dev/loop0: 8 bytes were erased at offset 0x4000000040 (btrfs): 5f 42 48 52 66 53 5f 4d

# Now even if we zero the 1st superblock, the filesystem doesn't resurrect

$ sudo dd if=/dev/zero of=/dev/loop0 bs=1 count=4k seek=64k4096+0 records in
4096+0 records out
4096 bytes (4.1 kB) copied, 0.00643427 s, 637 kB/s
$ sudo btrfs filesystem  show /dev/loop0
Btrfs Btrfs v0.19
$

Br 
G.Baroncelli

Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>

ChangeLog

V1 -> V2	Removed the three different superblock and put
		all the info in the same array (Thanks to Karel Zak
		for the suggestion)
		

------

Btrfs has three superblock. The first one is placed at 64KB, the
second one at 64MB, the third one at 256GB.

If the first superblock is valid except that the "magic field" is zeroed,
btrfs skips the check of the other superblocks.
If the first superblock is fully invalid, btrfs checks for the other
superblock.

So zeroing the first superblock "magic field" at the beginning seems
that the filesystem is wiped. But when the first superblock is overwritten
(eg by another filesystem), then the other two superblock may be considered
valid, and the filesystem may resurrect.

This patch allow to find and wipe the other btrfs superblocks signature.
---
 libblkid/src/superblocks/btrfs.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/libblkid/src/superblocks/btrfs.c b/libblkid/src/superblocks/btrfs.c
index 039be42..cb5004f 100644
--- a/libblkid/src/superblocks/btrfs.c
+++ b/libblkid/src/superblocks/btrfs.c
@@ -87,6 +87,14 @@ const struct blkid_idinfo btrfs_idinfo =
 	.magics		=
 	{
 		{ .magic = "_BHRfS_M", .len = 8, .kboff = 64, .sboff = 0x40 },
+		{ .magic = "_BHRfS_M", 
+		  .len = 8, 
+		  .kboff = 64 * 1024, 
+		  .sboff = 0x40 },
+		{ .magic = "_BHRfS_M", 
+		  .len = 8, 
+		  .kboff = 256 * 1024 * 1024, 
+		  .sboff = 0x40 },
 		{ NULL }
 	}
 };
-- 
1.7.10.4 


-- 
gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

             reply	other threads:[~2013-01-09 21:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-09 21:14 Goffredo Baroncelli [this message]
2013-01-10 10:44 ` [PATCH][v2] Btrfs: wipe all the superblock [redhat bugzilla 889888] Karel Zak

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=50EDDDC3.10407@inwind.it \
    --to=kreijack@inwind.it \
    --cc=chris.mason@fusionio.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=util-linux@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).