Interpreting Output of "btrfs fi show"

Interpreting Output of "btrfs fi show"

[Thomas Rohwer]

Hello,

I am using btrfs as my root file system on partition sda1. Now I am getting errors
because of a full device, although df shows a use of only 64%. I read the FAQ and
understand that this number may not be accurate. But according to the FAQ
"btrfs fi show" should show a full device.
I am getting:

humbur:~# btrfs fi show
failed to read /dev/sr0
Label: none  uuid: 484f8251-678f-4625-a05e-9dc8483f20a9
         Total devices 1 FS bytes used 64.31GB
         devid    1 size 111.79GB used 89.07GB path /dev/sda1

Label: none  uuid: be144c3c-3c34-45d1-aff2-415e72b0ec6e
         Total devices 1 FS bytes used 34.15GB
         devid    1 size 111.79GB used 37.29GB path /dev/sda

Btrfs Btrfs v0.19

And this does not make sense to me at all. First, the device listed for /dev/sda1
does not seem to be fully used. Second, I have no idea what the entry for /dev/sda
is supposed to mean. There should be only one btrfs filesystem, and certainly not
a second one on the device /dev/sda.

Some additional information:

humbur:~# btrfs fi df /
Data: total=76.00GB, used=60.27GB
System, DUP: total=32.00MB, used=20.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=6.50GB, used=4.04GB

humbur:~# df
Filesystem     1K-blocks     Used Available Use% Mounted on
rootfs         117219800 71666680  40316032  64% /
/dev/root      117219800 71666680  40316032  64% /
tmpfs             397608      200    397408   1% /run
tmpfs               5120        0      5120   0% /run/lock
tmpfs             795212        8    795204   1% /tmp
tmpfs              10240        0     10240   0% /dev
tmpfs             795212        0    795212   0% /run/shm

humbur:~# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / btrfs rw,noatime,ssd,noacl,nospace_cache 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=397608k,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=795212k 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,relatime,size=10240k,mode=755 0 0
tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=795212k 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0

humbur:~# ls -l /dev/sd*
brw-rw---T 1 root disk 8, 0 Apr 26 01:27 /dev/sda
brw-rw---T 1 root disk 8, 1 Apr 26 01:18 /dev/sda1

humbur:~# cat /proc/version
Linux version 3.3.0 (tr@humbur) (gcc version 4.6.3 (GCC) ) #3 SMP Thu Apr 5 00:14:18 CEST 2012




Some help would be appreciated.

Sincerely,

Thomas Rohwer

Re: Interpreting Output of "btrfs fi show"

[Bart Noordervliet]

Hi Thomas,

there's a known regression in 3.3.0 that causes btrfs to report
out-of-space too early. If you upgrade to 3.3.3 or the latest 3.4 rc
the problem should be gone.

As for the two filesystems shown in btrfs fi show... I have no clue
what that is about. Did you maybe make a mistake to create a btrfs
filesystem on the whole disk at first? The current situation looks a
bit dangerous, because writing to a filesystem on /dev/sda could
overwrite data from a filesystem on /dev/sda1...

Regards,

Bart

On Thu, Apr 26, 2012 at 04:34, Thomas Rohwer <trohwer@ennit.de> wrote:
> Hello,
>
> I am using btrfs as my root file system on partition sda1. Now I am g=
etting
> errors
> because of a full device, although df shows a use of only 64%. I read=
 the
> FAQ and
> understand that this number may not be accurate. But according to the=
 FAQ
> "btrfs fi show" should show a full device.
> I am getting:
>
> humbur:~# btrfs fi show
> failed to read /dev/sr0
> Label: none =C2=A0uuid: 484f8251-678f-4625-a05e-9dc8483f20a9
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Total devices 1 FS bytes used 64.31GB
> =C2=A0 =C2=A0 =C2=A0 =C2=A0devid =C2=A0 =C2=A01 size 111.79GB used 89=
=2E07GB path /dev/sda1
>
> Label: none =C2=A0uuid: be144c3c-3c34-45d1-aff2-415e72b0ec6e
> =C2=A0 =C2=A0 =C2=A0 =C2=A0Total devices 1 FS bytes used 34.15GB
> =C2=A0 =C2=A0 =C2=A0 =C2=A0devid =C2=A0 =C2=A01 size 111.79GB used 37=
=2E29GB path /dev/sda
>
> Btrfs Btrfs v0.19
>
> And this does not make sense to me at all. First, the device listed f=
or
> /dev/sda1
> does not seem to be fully used. Second, I have no idea what the entry=
 for
> /dev/sda
> is supposed to mean. There should be only one btrfs filesystem, and
> certainly not
> a second one on the device /dev/sda.
>
> Some additional information:
>
> humbur:~# btrfs fi df /
> Data: total=3D76.00GB, used=3D60.27GB
> System, DUP: total=3D32.00MB, used=3D20.00KB
> System: total=3D4.00MB, used=3D0.00
> Metadata, DUP: total=3D6.50GB, used=3D4.04GB
>
> humbur:~# df
> Filesystem =C2=A0 =C2=A0 1K-blocks =C2=A0 =C2=A0 Used Available Use% =
Mounted on
> rootfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 117219800 71666680 =C2=A040316032 =
=C2=A064% /
> /dev/root =C2=A0 =C2=A0 =C2=A0117219800 71666680 =C2=A040316032 =C2=A0=
64% /
> tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 397608 =C2=A0 =C2=A0 =
=C2=A0200 =C2=A0 =C2=A0397408 =C2=A0 1% /run
> tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5120 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A05120 =C2=A0 0% /run/lock
> tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 795212 =C2=A0 =C2=A0 =
=C2=A0 =C2=A08 =C2=A0 =C2=A0795204 =C2=A0 1% /tmp
> tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A010240 =C2=A0 =C2=
=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 10240 =C2=A0 0% /dev
> tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 795212 =C2=A0 =C2=A0 =
=C2=A0 =C2=A00 =C2=A0 =C2=A0795212 =C2=A0 0% /run/shm
>
> humbur:~# cat /proc/mounts
> rootfs / rootfs rw 0 0
> /dev/root / btrfs rw,noatime,ssd,noacl,nospace_cache 0 0
> tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=3D397608k,mode=3D755 =
0 0
> tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=3D5120k 0 =
0
> tmpfs /tmp tmpfs rw,nosuid,nodev,relatime,size=3D795212k 0 0
> proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
> sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
> tmpfs /dev tmpfs rw,relatime,size=3D10240k,mode=3D755 0 0
> tmpfs /run/shm tmpfs rw,nosuid,nodev,relatime,size=3D795212k 0 0
> devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=3D5,mode=3D620 0=
 0
>
> humbur:~# ls -l /dev/sd*
> brw-rw---T 1 root disk 8, 0 Apr 26 01:27 /dev/sda
> brw-rw---T 1 root disk 8, 1 Apr 26 01:18 /dev/sda1
>
> humbur:~# cat /proc/version
> Linux version 3.3.0 (tr@humbur) (gcc version 4.6.3 (GCC) ) #3 SMP Thu=
 Apr 5
> 00:14:18 CEST 2012
>
>
>
>
> Some help would be appreciated.
>
> Sincerely,
>
> Thomas Rohwer
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =C2=A0http://vger.kernel.org/majordomo-info.ht=
ml
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interpreting Output of "btrfs fi show"

[Thomas Rohwer]

Hello Bart,

> there's a known regression in 3.3.0 that causes btrfs to report
> out-of-space too early. If you upgrade to 3.3.3 or the latest 3.4 rc
> the problem should be gone.

thanks for the information. I will update my kernel.

> As for the two filesystems shown in btrfs fi show... I have no clue
> what that is about. Did you maybe make a mistake to create a btrfs
> filesystem on the whole disk at first?

That is possible. But afterwards I certainly repartioned the device and
created a btrfs filesystem on /dev/sda1. Maybe this info is only in
the partition table? I understand that I should avoid mounting /dev/sda
in this situation.

Sincerely,

Thomas Rohwer

Re: Interpreting Output of "btrfs fi show"

[Bart Noordervliet]

On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer <trohwer@ennit.de> wrote:
>> As for the two filesystems shown in btrfs fi show... I have no clue
>> what that is about. Did you maybe make a mistake to create a btrfs
>> filesystem on the whole disk at first?
>
> That is possible. But afterwards I certainly repartioned the device and
> created a btrfs filesystem on /dev/sda1. Maybe this info is only in
> the partition table? I understand that I should avoid mounting /dev/sda
> in this situation.

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. But they very much
overlap and the full-disk superblock will probably eventually be
overwritten by elements from the partition filesystem. How you would
go about erasing the stale superblock and whether it is safe to do so
I can't say though.

Re: Interpreting Output of "btrfs fi show"

[Thomas Rohwer]

> 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. But they very much
> overlap and the full-disk superblock will probably eventually be
> overwritten by elements from the partition filesystem. How you would
> go about erasing the stale superblock and whether it is safe to do so
> I can't say though.

Ok, that explains it, and it is no problem for me. I was just confused
by the output and thought that this may be related to the "no space"
problem. I just installed kernel 3.3.3, and the problem with "no space"
seems to be gone. Thanks for your quick help.

Sincerely,

Thomas Rohwer

Re: Interpreting Output of "btrfs fi show"

[Helmut Hullen]

Hallo, Bart,

Du meintest am 26.04.12:

>>> As for the two filesystems shown in btrfs fi show... I have no clue
>>> what that is about. Did you maybe make a mistake to create a btrfs
>>> filesystem on the whole disk at first?

>> That is possible. But afterwards I certainly repartioned the device
>> and created a btrfs filesystem on /dev/sda1. Maybe this info is only
>> in the partition table? I understand that I should avoid mounting
>> /dev/sda in this situation.

> 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"

Viele Gruesse!
Helmut

Re: Interpreting Output of "btrfs fi show"

[David Sterba]

On Thu, Apr 26, 2012 at 01:11:00PM +0200, Helmut Hullen wrote:
> I now use to delete about the first 10 MByte of the target disk via "dd  
> if=/dev/zero"

FYI, the minimal amount of data you need to rewrite is 4k:

dd if=/dev/zero of=/dev/ice bs=1k count=4 seek=64

david

Re: Interpreting Output of "btrfs fi show"

[Helmut Hullen]

Hallo, David,

Du meintest am 26.04.12:

>> I now use to delete about the first 10 MByte of the target disk via
>> "dd if=/dev/zero"

> FYI, the minimal amount of data you need to rewrite is 4k:

> dd if=/dev/zero of=/dev/ice bs=1k count=4 seek=64

Thank you - I'll try to remember the next time I need this command!

Viele Gruesse!
Helmut

Re: Interpreting Output of "btrfs fi show"

[Duncan]

Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:

> Hallo, Bart,
> 
> Du meintest am 26.04.12:
> 
>>>> As for the two filesystems shown in btrfs fi show... I have no clue
>>>> what that is about. Did you maybe make a mistake to create a btrfs
>>>> filesystem on the whole disk at first?
> 
>>> That is possible. But afterwards I certainly repartioned the device
>>> and created a btrfs filesystem on /dev/sda1. Maybe this info is only
>>> in the partition table? I understand that I should avoid mounting
>>> /dev/sda in this situation.
> 
>> 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"

Interestingly, this reminds me very much of the problem reiserfs has 
(used to have??) with reiserfsck --rebuild-tree, where it would scan the 
disk and decide anything that looked like a reiserfs superblock must 
indeed be one, so any loopback filesystems created on a larger reiserfs 
would screw up the larger reiserfs if rebuild-tree was ever run on it.

FWIW, I still run reiserfs, while waiting for a new filesystem with tail-
packing (FWIW one of the features btrfs has, but btrfs isn't mature yet), 
but I've never done a loopback reiserfs hosted on reiserfs -- I make sure 
any loopbacks are something else, so I I've never had that problem 
personally nor do I expect to.

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.

But of course Chris Mason, being reiserfs maintainer for many years (and 
whose praises I continue to sing for introducing and making ordered 
journaling the reiserfs default in the mainline kernel... such that 
during the infamous period when ext3 defaulted to writeback journaling, 
reiserfs was arguably more stable than ext3!), both knows and has 
forgotten waayyy more about that than most of us would ever /dream/ of 
knowing in the first place, I'm sure!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Interpreting Output of "btrfs fi show"

[Hubert Kario]

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,
> >>=20
> >> Well I think there is a btrfs superblock still present from the
> >> full-disk filesystem. Due to the offset of the first partition fro=
m the
> >> start of the disk, this superblock was not overwritten when you cr=
eated
> >> the filesystem inside the partition.
> >=20
> > Sounds familiar ...
> >=20
> > I now use to delete about the first 10 MByte of the target disk via=
 "dd
> > if=3D/dev/zero"
>=20
> But /unlike/ reiserfs, which was only affected with the well warned a=
s
> don't-use-unless-you-have-to fsck --rebuild-tree option, it seems tha=
t
> 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 beca=
use=20
of FS UUID written all over the tree.

What we see here, is a superblock that is written in *very* specific pl=
ace=20
on the partition, that just is aligned in place that makes the whole di=
sk=20
look like btrfs.

I don't think it's actually possible for btrfs to put a file with btrfs=
=20
filesystem image in place where it could seem like the basic block devi=
ce=20
has btrfs /too/. It depends on whatever the metadata block is allocated=
=20
before data block on disk. It /may/ be possible in mixed data-metadata=20
allocation mode.
Chris or Josef, can you confirm?

Still, a "zero-superblock" option would be useful for the btrfs tool. I=
'll=20
see what I can do about this.

Regards,
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interpreting Output of "btrfs fi show"

[Duncan]

Hubert Kario posted on Sat, 28 Apr 2012 18:42:52 +0200 as excerpted:

> 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.

Very good point!  I had forgotten about that.

> 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.

Yes.  That would be more analogous to the md/raid problem related to one 
of the 1.x metadata formats, where it's at the /end/ of the volume.  If 
that "volume" happens to correspond to the end of the physical disk as 
well, then it's not always clear whether the md with metadata of that 
version is the entire device or just a partition thereon.

> 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?

Makes sense.  I too would like confirmation on the mixed-mode case, tho, 
as when I setup with btrfs, I'll very likely be using mixed-mode for some 
of my smaller filesystems.  (I don't plan on using the sub-volumes for 
that, as a good part of the reason I'm doing it is robustness, not 
putting all my data "eggs" in the same filesystem "basket".  Keeping them 
in separate baskets means if one filesystem "basket" dies, I've lost only 
a relatively small subset of my data.)

> Still, a "zero-superblock" option would be useful for the btrfs tool.
> I'll see what I can do about this.

Yes, indeed.  Particularly since various bits of btrfs functionality 
depend on scanning for filesystems (presumably their superblocks), and 
output like that in the OP can be confusing indeed, as well as 
potentially dangerous in recovery situations, where the wrong one might 
be activated by accident.  (FWIW, there's an mdadm --zero-superblock 
option.  I should take note of this thread and be sure I use it when next 
I redo my layouts, probably when I switch some of them to btrfs instead, 
tho that's going to be a bit as I'm waiting for N-way-mirroring, aka 
proper raid1 mode, not the 2-way-only-mirroring that btrfs calls raid1 
mode currently.)

Thanks.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: Interpreting Output of "btrfs fi show"

[Martin Steigerwald]

Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
> On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer <trohwer@ennit.de> wrote=
:
> >> As for the two filesystems shown in btrfs fi show... I have no clu=
e
> >> what that is about. Did you maybe make a mistake to create a btrfs
> >> filesystem on the whole disk at first?
> >=20
> > That is possible. But afterwards I certainly repartioned the device
> > and created a btrfs filesystem on /dev/sda1. Maybe this info is onl=
y
> > in the partition table? I understand that I should avoid mounting
> > /dev/sda in this situation.
>=20
> 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. But they very much
> overlap and the full-disk superblock will probably eventually be
> overwritten by elements from the partition filesystem. How you would
> go about erasing the stale superblock and whether it is safe to do so
> I can't say though.

There is the command wipefs. Whether its safe to use here I do not know=
=2E I=20
wouldn=C2=B4t try without a backup.

--=20
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interpreting Output of "btrfs fi show"

[Hugo Mills]

[-- 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 --]

Re: Interpreting Output of "btrfs fi show"

[Hubert Kario]

On Sunday 29 of April 2012 04:15:24 Duncan wrote:
> > Still, a "zero-superblock" option would be useful for the btrfs too=
l.
> > I'll see what I can do about this.
>=20
> Yes, indeed.  Particularly since various bits of btrfs functionality=20
> depend on scanning for filesystems (presumably their superblocks), an=
d=20
> output like that in the OP can be confusing indeed, as well as=20
> potentially dangerous in recovery situations, where the wrong one mig=
ht=20
> be activated by accident.  (FWIW, there's an mdadm --zero-superblock=20
> option.  I should take note of this thread and be sure I use it when =
next=20
> I redo my layouts, probably when I switch some of them to btrfs inste=
ad,=20
> tho that's going to be a bit as I'm waiting for N-way-mirroring, aka=20
> proper raid1 mode, not the 2-way-only-mirroring that btrfs calls raid=
1=20
> mode currently.)

mdadm --zero-superblock removes MD superblock, it doesn't modify the da=
ta part=20
of the partition, it just zeroes the MD metadata.

Regards,
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interpreting Output of "btrfs fi show"

[Hubert Kario]

On Sunday 29 of April 2012 08:13:48 Martin Steigerwald wrote:
> Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
> > On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer <trohwer@ennit.de> wro=
te:
> > >> As for the two filesystems shown in btrfs fi show... I have no c=
lue
> > >> what that is about. Did you maybe make a mistake to create a btr=
fs
> > >> filesystem on the whole disk at first?
> > >=20
> > > That is possible. But afterwards I certainly repartioned the devi=
ce
> > > and created a btrfs filesystem on /dev/sda1. Maybe this info is o=
nly
> > > in the partition table? I understand that I should avoid mounting
> > > /dev/sda in this situation.
> >=20
> > 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. But they very much
> > overlap and the full-disk superblock will probably eventually be
> > overwritten by elements from the partition filesystem. How you woul=
d
> > go about erasing the stale superblock and whether it is safe to do =
so
> > I can't say though.
>=20
> There is the command wipefs. Whether its safe to use here I do not kn=
ow. I
> wouldn=B4t try without a backup.

Sorry, but I'm unable to find it. Is it a `btrfs` tool option or is it =
a=20
standalone application (in similar form as is the `btrfs-zero-log`)?

Regards,
--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Interpreting Output of "btrfs fi show"

[Mike Fleetwood]

On 30 April 2012 18:10, Hubert Kario <hka@qbs.com.pl> wrote:
> On Sunday 29 of April 2012 08:13:48 Martin Steigerwald wrote:
>> Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
>> > On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer <trohwer@ennit.de> wr=
ote:
>> > >> As for the two filesystems shown in btrfs fi show... I have no =
clue
>> > >> what that is about. Did you maybe make a mistake to create a bt=
rfs
>> > >> filesystem on the whole disk at first?
>> > >
>> > > That is possible. But afterwards I certainly repartioned the dev=
ice
>> > > and created a btrfs filesystem on /dev/sda1. Maybe this info is =
only
>> > > in the partition table? I understand that I should avoid mountin=
g
>> > > /dev/sda in this situation.
>> >
>> > Well I think there is a btrfs superblock still present from the
>> > full-disk filesystem. Due to the offset of the first partition fro=
m
>> > the start of the disk, this superblock was not overwritten when yo=
u
>> > created the filesystem inside the partition. But they very much
>> > overlap and the full-disk superblock will probably eventually be
>> > overwritten by elements from the partition filesystem. How you wou=
ld
>> > go about erasing the stale superblock and whether it is safe to do=
 so
>> > I can't say though.
>>
>> There is the command wipefs. Whether its safe to use here I do not k=
now. I
>> wouldn=C2=B4t try without a backup.
>
> Sorry, but I'm unable to find it. Is it a `btrfs` tool option or is i=
t a
> standalone application (in similar form as is the `btrfs-zero-log`)?

Google is your friend.  wipefs is part of util-linux from 2.17, circa J=
an-2010.

Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html