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
--
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
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 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 > > -- > 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-- 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
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 -- 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
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. -- 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
> 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 -- 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
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 -- 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
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 -- 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
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=64Thank you - I''ll try to remember the next time I need this command! Viele Gruesse! Helmut -- 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
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 -- 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
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? Still, a "zero-superblock" option would be useful for the btrfs tool. I''ll see what I can do about this. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 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
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 -- 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
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 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.There is the command wipefs. Whether its safe to use here I do not know. I wouldn´t try without a backup. -- 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
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" ---
On Sunday 29 of April 2012 04:15:24 Duncan wrote:> > 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.)mdadm --zero-superblock removes MD superblock, it doesn''t modify the data part of the partition, it just zeroes the MD metadata. Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 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
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> 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. > > There is the command wipefs. Whether its safe to use here I do not know. I > wouldn´t try without a backup.Sorry, but I''m unable to find it. Is it a `btrfs` tool option or is it a standalone application (in similar form as is the `btrfs-zero-log`)? Regards, -- Hubert Kario QBS - Quality Business Software 02-656 Warszawa, ul. Ksawerów 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
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> 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. >> >> There is the command wipefs. Whether its safe to use here I do not know. I >> wouldn´t try without a backup. > > Sorry, but I''m unable to find it. Is it a `btrfs` tool option or is it 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 Jan-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