BUG btrfs fi show displays stale btrfs volume

BUG btrfs fi show displays stale btrfs volume

[Chris Murphy]

I've filed this bug under util-linux, because I think wipefs isn't deleting all btrfs metadata it could. But ultimately it appears to be a btrfs bug because nothing else sees the stale volume.

https://bugzilla.redhat.com/show_bug.cgi?id=889888#c15

btrfs-progs-0.20.rc1.20121017git92d9eec-1.fc18.x86_64
e2fs-progs-1.42.5-1.fc18.x86_64
kernel 3.7.1-2

Brand new 80GB virtual disk, so it's completely zero'd.

1. fdisk to create one partition, all defaults.
2. Format that sda1 with mkfs.btrfs -L first.
3. btrfs fi show displays "first" labeled volume.
4. wipefs -a /dev/sda1 and it finds btrfs metadata, ostensibly removes it.
5. btrfs fi show does NOT show "first" anymore.
6. fdisk /dev/sda again, delete the one partition; create a new partition 500MB and a second one for remaining space.
7. btrfs fi show still does not show "first".
8. mkfs.ext4 /dev/sda1
9. btrfs fi show NOW SHOWS "first" on sda1!
10. Reboot
11. btrfs fi show still shows "first" on sda1, size 80GB.

Tentative conclusions:

A. wipefs isn't deleting all btrfs metadata it could. 

B. mkfs.ext4 is refreshing stale btrfs metadata in a way that causes btrfs fi show to see.

C. btrfs fi show seems to blatantly disregard the partition map, because it shows a volume the partition map cannot possibly validly support.

D. Nothing else sees this phantom btrfs volume. btrfs fi show seems confused.


Chris Murphy

Re: BUG btrfs fi show displays stale btrfs volume

[Goffredo Baroncelli]

Hi Chris
On 01/06/2013 12:21 AM, Chris Murphy wrote:
> I've filed this bug under util-linux, because I think wipefs isn't deleting all btrfs metadata it could. But ultimately it appears to be a btrfs bug because nothing else sees the stale volume.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=889888#c15
> 
> btrfs-progs-0.20.rc1.20121017git92d9eec-1.fc18.x86_64
> e2fs-progs-1.42.5-1.fc18.x86_64
> kernel 3.7.1-2
> 
> Brand new 80GB virtual disk, so it's completely zero'd.
> 
> 1. fdisk to create one partition, all defaults.
> 2. Format that sda1 with mkfs.btrfs -L first.
> 3. btrfs fi show displays "first" labeled volume.
> 4. wipefs -a /dev/sda1 and it finds btrfs metadata, ostensibly removes it.
> 5. btrfs fi show does NOT show "first" anymore.
> 6. fdisk /dev/sda again, delete the one partition; create a new partition 500MB and a second one for remaining space.
> 7. btrfs fi show still does not show "first".
> 8. mkfs.ext4 /dev/sda1
> 9. btrfs fi show NOW SHOWS "first" on sda1!
> 10. Reboot
> 11. btrfs fi show still shows "first" on sda1, size 80GB.
> 
> Tentative conclusions:
> 
> A. wipefs isn't deleting all btrfs metadata it could. 
True
> 
> B. mkfs.ext4 is refreshing stale btrfs metadata in a way that causes btrfs fi show to see.
True

Btrfs stores several copies of the superblock (IIRC three). During the
scan it searches for a valid superblock. If the first is wrong, checks
the second and so on...
It stops the search when one of the following conditions is true:
1) the superblock "magic" field is zero (typically when a disk is removed)
2) the superblock is valid
3) there is no other superblock.

I think that wipefs zeros the "magic" field on the first superblock. So
the btrfs scan process ends at the first superblock.

When the disk is used again, it is possible that the first superblock is
overwritten and the "magic" field is not zero any more. So in case of
further scan by btrfs, the first superblock is ignored and the check is
performed to the second one and the third one, which could be valid, if
nobody zeroed its "magic" field.

I think that wipefs should be improved to reset to zero also the other
superblocks.

I will start to update the wiki; then I will give a look to wipefs to
improve it.

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

Re: BUG btrfs fi show displays stale btrfs volume

[Goffredo Baroncelli]

On 01/06/2013 05:26 PM, Goffredo Baroncelli wrote:
> Hi Chris
[...]
> 
> I will start to update the wiki; then I will give a look to wipefs to
> improve it.

Hello I updated the wiki page:


https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#What_if_I_don.27t_have_wipefs_at_hand.3F
-----
 What if I don't have wipefs at hand?

There are three superblocks: the first one is located at 64K, the second
one at 64M, the third one at 256GB. The following lines reset the magic
string on all the three superblocks

# dd if=/dev/zero bs=1 count=8 of=/dev/sda seek=$((64*1024+64))
# dd if=/dev/zero bs=1 count=8 of=/dev/sda seek=$((64*1024*1024+64))
# dd if=/dev/zero bs=1 count=8 of=/dev/sda seek=$((256*1024*1024*1024+64))

If you want to restore the superblocks magic string,

# echo "_BHRfS_M" | dd bs=1 count=8 of=/dev/sda seek=$((64*1024+64))
# echo "_BHRfS_M" | dd bs=1 count=8 of=/dev/sda seek=$((64*1024*1024+64))
# echo "_BHRfS_M" | dd bs=1 count=8 of=/dev/sda
seek=$((256*1024*1024*1024+64))
------

> 
> BR
> G.Baroncelli


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