Interpreting Output of "btrfs fi show"
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/sda1Label: 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
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
Quoted 3 lines · Thomas Rohwer
Hello,
I am using btrfs as my root file system on partition sda1. Now I am g=
etting
Quoted 2 lines
errors
because of a full device, although df shows a use of only 64%. I read=
the
Quoted 2 lines
FAQ and
understand that this number may not be accurate. But according to the=
FAQ
Quoted 8 lines
"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
Quoted 4 lines
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
Quoted 4 lines
Btrfs Btrfs v0.19
And this does not make sense to me at all. First, the device listed f=
or
Quoted 2 lines
/dev/sda1
does not seem to be fully used. Second, I have no idea what the entry=
for
Quoted 7 lines
/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:
Quoted 8 lines
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.04GBhumbur:~# df Filesystem =C2=A0 =C2=A0 1K-blocks =C2=A0 =C2=A0 Used Available Use% =
Mounted on
Quoted 1 line
rootfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 117219800 71666680 =C2=A040316032 =
=C2=A064% /
Quoted 1 line
/dev/root=C2=A0 =C2=A0 =C2=A0117219800 71666680 =C2=A040316032 =C2=A0=
64% /
Quoted 1 line
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
Quoted 1 line
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
Quoted 1 line
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
Quoted 1 line
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
Quoted 1 line
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
Quoted 5 lines
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
Quoted 1 line
tmpfs
/run/locktmpfs rw,nosuid,nodev,noexec,relatime,size=3D5120k 0 =
0
Quoted 6 lines
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/shmtmpfs rw,nosuid,nodev,relatime,size=3D795212k 0 0 devpts/dev/ptsdevpts rw,nosuid,noexec,relatime,gid=3D5,mode=3D620 0=
0
Quoted 7 lines
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/sda1humbur:~# cat /proc/version Linux version 3.3.0 (tr@humbur) (gcc version 4.6.3 (GCC) ) #3 SMP Thu=
Apr 5
Quoted 5 lines
00:14:18 CEST 2012
Quoted 8 lines
Some help would be appreciated.
Sincerely,
Thomas Rohwer
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
Quoted 2 lines
the body of a message to [email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Bart,
Quoted 3 lines
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.
Quoted 3 lines
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
Quoted 8 lines · Thomas Rohwer
Quoted 3 lines
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/sdain 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.
Quoted 8 lines
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
Hallo, Bart,
Du meintest am 26.04.12:
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
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/sdain this situation.
Quoted 4 lines
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
Quoted 2 lines · Helmut Hullen
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
Hallo, David,
Du meintest am 26.04.12:
Quoted 6 lines
Quoted 2 lines
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
Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
Quoted 18 lines
Hallo, Bart,
Du meintest am 26.04.12:
Quoted 9 lines
Quoted 8 lines
Quoted 3 lines
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/sdain this situation.Quoted 4 lines
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.
Quoted 4 lines
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!
Signature · 3 lines
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
Quoted 5 lines · 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:
Quoted 4 lines
Hallo, Bart,
Quoted 3 lines
=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
Quoted 1 line
Quoted 1 line
Quoted 1 line
start of the disk, this superblock was not overwritten when you cr=
eated
Quoted 5 lines
Quoted 5 lines
Quoted 1 line
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
Quoted 3 lines
Quoted 1 line
if=3D/dev/zero"
=20
But /unlike/ reiserfs, which was only affected with the well warned a=
s
Quoted 1 line
don't-use-unless-you-have-to fsck --rebuild-tree option, it seems tha=
t
Quoted 2 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hubert Kario posted on Sat, 28 Apr 2012 18:42:52 +0200 as excerpted:
Quoted 14 lines · On Thursday 26 of April 2012 20:54:47 Duncan wrote:
Quoted 13 lines
Helmut Hullen posted on Thu, 26 Apr 2012 13:11:00 +0200 as excerpted:
Quoted 11 lines
Hallo, Bart,
Quoted 5 lines
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"
Quoted 7 lines
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 6 lines
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.)
Quoted 2 lines
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.
Signature · 3 lines
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
Quoted 1 line · On Sunday 29 of April 2012 04:15:24 Duncan wrote:
Quoted 1 line
Still, a "zero-superblock" option would be useful for the btrfs too=
l.
Quoted 4 lines
Quoted 1 line
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
Quoted 2 lines
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
Quoted 2 lines
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
Quoted 1 line
I redo my layouts, probably when I switch some of them to btrfs inste=
ad,=20
Quoted 2 lines
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
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 26 lines · Hubert Kario
Quoted 10 lines · 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:
Quoted 9 lines
Hallo, Bart,
Quoted 5 lines
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 ...
Quoted 7 lines
Quoted 2 lines
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.
Quoted 6 lines
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.
Signature · 3 lines
=== 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" ---
Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
Quoted 1 line
On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer <[email protected]> wrote=
:
Quoted 1 line
Quoted 1 line
Quoted 1 line
As for the two filesystems shown in btrfs fi show... I have no clu=
e
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
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
Quoted 11 lines
Quoted 2 lines
in the partition table? I understand that I should avoid mounting
/dev/sdain 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · On Sunday 29 of April 2012 08:13:48 Martin Steigerwald wrote:
Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
Quoted 1 line
On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer <[email protected]> wro=
te:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
As for the two filesystems shown in btrfs fi show... I have no c=
lue
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
what that is about. Did you maybe make a mistake to create a btr=
fs
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
filesystem on the whole disk at first?
=20
That is possible. But afterwards I certainly repartioned the devi=
ce
Quoted 1 line
Quoted 1 line
Quoted 1 line
and created a btrfs filesystem on
/dev/sda1. Maybe this info is o=
nly
Quoted 9 lines
Quoted 9 lines
Quoted 2 lines
in the partition table? I understand that I should avoid mounting
/dev/sdain 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
Quoted 1 line
Quoted 1 line
go about erasing the stale superblock and whether it is safe to do =
so
Quoted 3 lines
Quoted 1 line
I can't say though.
=20
There is the command wipefs. Whether its safe to use here I do not kn=
ow. I
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · Hubert Kario
Quoted 2 lines · On Sunday 29 of April 2012 08:13:48 Martin Steigerwald wrote:
Am Donnerstag, 26. April 2012 schrieb Bart Noordervliet:
Quoted 1 line
On Thu, Apr 26, 2012 at 11:06, Thomas Rohwer <[email protected]> wr=
ote:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
As for the two filesystems shown in btrfs fi show... I have no =
clue
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
what that is about. Did you maybe make a mistake to create a bt=
rfs
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
filesystem on the whole disk at first?
That is possible. But afterwards I certainly repartioned the dev=
ice
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
and created a btrfs filesystem on
/dev/sda1. Maybe this info is =
only
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
in the partition table? I understand that I should avoid mountin=
g
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
/dev/sdain 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
Quoted 1 line
Quoted 1 line
Quoted 1 line
the start of the disk, this superblock was not overwritten when yo=
u
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
go about erasing the stale superblock and whether it is safe to do=
so
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
I can't say though.
There is the command wipefs. Whether its safe to use here I do not k=
now. I
Quoted 3 lines
Quoted 1 line
wouldn=C2=B4t try without a backup.
Sorry, but I'm unable to find it. Is it a
btrfstool option or is i=
t a
Quoted 1 line
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html