Hallo, linux-btrfs,
please delete the option "-L" (for labelling) in
"mkfs.btrfs", in some
configurations it doesn''t work as expected.
My usual way:
mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ...
One call for some devices.
Wenn I add the option "-L mylabel" then each device gets the same
label,
and therefore some other programs can''t find the (one) device with the
defined label.
Especially
blkid
findfs LABEL=mylabel
don''t work.
file -s /dev/sdb (etc.)
shows the label (and the problem).
Other tries:
mkfs.btrfs -L mylabel /dev/sdb
creates a new btrfs filesystem and overwrites prior tries.
What works:
btrfs filesystem label /dev/sdb mylabel
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, Jan 03, 2013 at 04:14:00PM +0100, Helmut Hullen wrote:> Hallo, linux-btrfs, > > please delete the option "-L" (for labelling) in "mkfs.btrfs", in some > configurations it doesn''t work as expected. > > My usual way: > > mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... > > One call for some devices. > Wenn I add the option "-L mylabel" then each device gets the same label, > and therefore some other programs can''t find the (one) device with the > defined label.I''m sure we''ve been over this territory before. Devices are not labelled; filesystems are labelled. You are labelling the whole filesystem, which exists over several devices, so the same label will be attached to every device in the filesystem.> Especially > > blkid > findfs LABEL=mylabel > > don''t work.How do you mean, "don''t work"? What are they showing, and what do you think should they be showing? It looks like both of them print an arbitrary device node of the devices that the FS lives on. Given that both of these tools probably expect a one-to-one relationship between a block device and a filesystem, this is not unreasonable.> file -s /dev/sdb (etc.) > > shows the label (and the problem). > > Other tries: > > mkfs.btrfs -L mylabel /dev/sdb > > creates a new btrfs filesystem and overwrites prior tries.Yes, because you''ve just created a new filesystem. That''s what mkfs.btrfs does, same as every other mkfs -- it creates a new filesystem, destroying what was there before. This is unsurprising. Hugo.> What works: > > btrfs filesystem label /dev/sdb mylabel-- === 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 part of "gestalt" don''t you understand? ---
Hallo, Hugo, Du meintest am 03.01.13:>> please delete the option "-L" (for labelling) in "mkfs.btrfs", in >> some configurations it doesn''t work as expected. >> >> My usual way: >> >> mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... >> >> One call for some devices. >> Wenn I add the option "-L mylabel" then each device gets the same >> label, and therefore some other programs can''t find the (one) device >> with the defined label.> I''m sure we''ve been over this territory before. Devices are not > labelled; filesystems are labelled. You are labelling the whole > filesystem, which exists over several devices, so the same label will > be attached to every device in the filesystem.But for what purpose offers "mkfs.btrfs" this option?>> Especially >> >> blkid >> findfs LABEL=mylabel >> >> don''t work.> How do you mean, "don''t work"? What are they showing, and what do > you think should they be showing?Without this double-labelled (?) devices "blkid" shows all devices with (if defined) their labels. When I define the same label for more than 1 device (btrfs or ext2fs or ...) then "blkid" shows nothing. No output for any of the devices. "findfs": with double-labelled devices "findfs" doesn''t find any label.> It looks like both of them print an > arbitrary device node of the devices that the FS lives on. Given that > both of these tools probably expect a one-to-one relationship between > a block device and a filesystem, this is not unreasonable.May be that "this is not unreasonable". But when "mkfs.btrfs" offers the "label" option I don''t expect this behaviour. I had mentioned this problem more than a year ago, it still exists. 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, Jan 03, 2013 at 05:29:00PM +0100, Helmut Hullen wrote:> Hallo, Hugo, > > Du meintest am 03.01.13: > > >> please delete the option "-L" (for labelling) in "mkfs.btrfs", in > >> some configurations it doesn''t work as expected. > >> > >> My usual way: > >> > >> mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... > >> > >> One call for some devices. > >> Wenn I add the option "-L mylabel" then each device gets the same > >> label, and therefore some other programs can''t find the (one) device > >> with the defined label. > > > I''m sure we''ve been over this territory before. Devices are not > > labelled; filesystems are labelled. You are labelling the whole > > filesystem, which exists over several devices, so the same label will > > be attached to every device in the filesystem. > > But for what purpose offers "mkfs.btrfs" this option?So that you don''t have to run the label command immediately after making the filesystem. Most mkfs implementations for different filesystems have something similar, usually with the -L option.> >> Especially > >> > >> blkid > >> findfs LABEL=mylabel > >> > >> don''t work. > > > How do you mean, "don''t work"? What are they showing, and what do > > you think should they be showing? > > Without this double-labelled (?) devices "blkid" shows all devices with"Double-labelled"? The filesystem has one label, belonging to the filesystem. I don''t see where the "double-labelling" comes in.> (if defined) their labels. When I define the same label for more than 1 > device (btrfs or ext2fs or ...) then "blkid" shows nothing. No output > for any of the devices.This is a fault in the version of blkid you''re running, then. There''s nothing to stop me from labelling two ext2 filesystems with the same label. If blkid can''t handle that, then it''s got problems beyond btrfs. On my main machine, it seems to work correctly: $ sudo blkid /dev/sda: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="5fd56eec-5e26-4c1f-a02a-f86550e4aefe" TYPE="btrfs" /dev/sdc: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="4e392bea-f39a-4cba-b78c-c712479bf3f0" TYPE="btrfs" /dev/sde: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="5e2555bd-bf36-430b-af5a-aa81604afc96" TYPE="btrfs" /dev/sdp: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="404d13f5-0231-46db-a311-ad7a4f99eef3" TYPE="btrfs" /dev/sdr: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="90469059-f012-4b6e-9233-8c591cbeaa80" TYPE="btrfs" /dev/sdq: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="646d3d32-5193-4fcd-afb2-43f14122a149" TYPE="btrfs" /dev/sds: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="f4d4dbb2-f2bb-4e54-bbf9-4bb5474e9ef1" TYPE="btrfs" My blkid version: blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011)> "findfs": with double-labelled devices "findfs" doesn''t find any label.On my system, the filesystem with label "media" exists on /dev/sd{a,b,c,e,p,q,r,s}: $ sudo blkid -L media /dev/sdb $ sudo findfs LABEL=media /dev/sdb In each case, it''s giving me the path of a block device node which I can use to mount the filesystem. As far as I know, this is the correct and expected behaviour.> > It looks like both of them print an > > arbitrary device node of the devices that the FS lives on. Given that > > both of these tools probably expect a one-to-one relationship between > > a block device and a filesystem, this is not unreasonable. > > May be that "this is not unreasonable". But when "mkfs.btrfs" offers the > "label" option I don''t expect this behaviour.You''re running mkfs. Why would you expect running mkfs *not* to make a new filesystem? This is the behaviour on all other mkfses. From the man page: DESCRIPTION mkfs.btrfs is used to create a btrfs filesystem (usually in a disk par‐ tition, or an array of disk partitions). device is the special file corresponding to the device (e.g /dev/sdXX ). If multiple devices are specified, btrfs is created spanning across the specified devices. i.e. it''s a tool to create a filesystem.> I had mentioned this problem more than a year ago, it still exists.It''s not a problem. Everything is working as expected and as designed. 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 --- You''re never alone with a rubber duck... ---
common labels work for me on my 3 way raid volumes. there''s been no problem. what might be a problem is when i do mount LABEL=foo, btrfs dev scan is not automatic on failure. On Thu, Jan 3, 2013 at 9:01 AM, Hugo Mills <hugo@carfax.org.uk> wrote:> On Thu, Jan 03, 2013 at 05:29:00PM +0100, Helmut Hullen wrote: >> Hallo, Hugo, >> >> Du meintest am 03.01.13: >> >> >> please delete the option "-L" (for labelling) in "mkfs.btrfs", in >> >> some configurations it doesn''t work as expected. >> >> >> >> My usual way: >> >> >> >> mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... >> >> >> >> One call for some devices. >> >> Wenn I add the option "-L mylabel" then each device gets the same >> >> label, and therefore some other programs can''t find the (one) device >> >> with the defined label. >> >> > I''m sure we''ve been over this territory before. Devices are not >> > labelled; filesystems are labelled. You are labelling the whole >> > filesystem, which exists over several devices, so the same label will >> > be attached to every device in the filesystem. >> >> But for what purpose offers "mkfs.btrfs" this option? > > So that you don''t have to run the label command immediately after > making the filesystem. Most mkfs implementations for different > filesystems have something similar, usually with the -L option. > >> >> Especially >> >> >> >> blkid >> >> findfs LABEL=mylabel >> >> >> >> don''t work. >> >> > How do you mean, "don''t work"? What are they showing, and what do >> > you think should they be showing? >> >> Without this double-labelled (?) devices "blkid" shows all devices with > > "Double-labelled"? The filesystem has one label, belonging to the > filesystem. I don''t see where the "double-labelling" comes in. > >> (if defined) their labels. When I define the same label for more than 1 >> device (btrfs or ext2fs or ...) then "blkid" shows nothing. No output >> for any of the devices. > > This is a fault in the version of blkid you''re running, then. > There''s nothing to stop me from labelling two ext2 filesystems with > the same label. If blkid can''t handle that, then it''s got problems > beyond btrfs. On my main machine, it seems to work correctly: > > $ sudo blkid > /dev/sda: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="5fd56eec-5e26-4c1f-a02a-f86550e4aefe" TYPE="btrfs" > /dev/sdc: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="4e392bea-f39a-4cba-b78c-c712479bf3f0" TYPE="btrfs" > /dev/sde: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="5e2555bd-bf36-430b-af5a-aa81604afc96" TYPE="btrfs" > /dev/sdp: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="404d13f5-0231-46db-a311-ad7a4f99eef3" TYPE="btrfs" > /dev/sdr: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="90469059-f012-4b6e-9233-8c591cbeaa80" TYPE="btrfs" > /dev/sdq: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="646d3d32-5193-4fcd-afb2-43f14122a149" TYPE="btrfs" > /dev/sds: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" UUID_SUB="f4d4dbb2-f2bb-4e54-bbf9-4bb5474e9ef1" TYPE="btrfs" > > My blkid version: > > blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011) > >> "findfs": with double-labelled devices "findfs" doesn''t find any label. > > On my system, the filesystem with label "media" exists on > /dev/sd{a,b,c,e,p,q,r,s}: > > $ sudo blkid -L media > /dev/sdb > $ sudo findfs LABEL=media > /dev/sdb > > In each case, it''s giving me the path of a block device node which > I can use to mount the filesystem. As far as I know, this is the > correct and expected behaviour. > >> > It looks like both of them print an >> > arbitrary device node of the devices that the FS lives on. Given that >> > both of these tools probably expect a one-to-one relationship between >> > a block device and a filesystem, this is not unreasonable. >> >> May be that "this is not unreasonable". But when "mkfs.btrfs" offers the >> "label" option I don''t expect this behaviour. > > You''re running mkfs. Why would you expect running mkfs *not* to > make a new filesystem? This is the behaviour on all other mkfses. > > From the man page: > > DESCRIPTION > mkfs.btrfs is used to create a btrfs filesystem (usually in a disk par‐ > tition, or an array of disk partitions). device is the special file > corresponding to the device (e.g /dev/sdXX ). If multiple devices > are specified, btrfs is created spanning across the specified devices. > > i.e. it''s a tool to create a filesystem. > >> I had mentioned this problem more than a year ago, it still exists. > > It''s not a problem. Everything is working as expected and as > designed. > > 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 > --- You''re never alone with a rubber duck... ----- 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, Hugo, Du meintest am 03.01.13:>> But for what purpose offers "mkfs.btrfs" this option?> So that you don''t have to run the label command immediately after > making the filesystem. Most mkfs implementations for different > filesystems have something similar, usually with the -L option.But other filesystems don''t put the label onto more than 1 device. There''s the problem for/with btrfs. The label has to be unique for the whole machine.>> Without this double-labelled (?) devices "blkid" shows all devices >> with> "Double-labelled"? The filesystem has one label, belonging to the > filesystem. I don''t see where the "double-labelling" comes in.As I described: mkfs.btrfs -d raid0 -m raid1 -l mylabel /dev/sdb /dev/sdc /dev/sdd labels all three devices with the same name, and then programs like "blkid" or "findfs" don''t find any label (for all labelled devices, not only for btrfs devices). And as I have written before: file -s /dev/sdb file -s /dev/sdc file -s /dev/sdd shows for each of these devices the same label. -------------- When I run mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd and then btrfs filesystem label /dev/sdb mylabel then only "/dev/sdb" shows this label (as long as none of the 3 devices is mounted). When I then run mount LABEL=mylabel /mnt/btr then all works fine. And then (after mounting) blkid /dev/sdb blkid /dev/sdc blkid /dev/sdd show the same label. blkid without any device seems to hang - may be I haven''t waited long enough.>> (if defined) their labels. When I define the same label for more >> than 1 device (btrfs or ext2fs or ...) then "blkid" shows nothing. >> No output for any of the devices.> This is a fault in the version of blkid you''re running, then.here: "blkid from until-linux 2.21.2 (libblkid 2.21.0, 25-May-2012)". And older versions.> There''s nothing to stop me from labelling two ext2 filesystems with > the same label.That part is right: I can label more than 1 device with the same name, not only under btrfs. But then (I had written this problem) programs like "blkid" don''t find any labelled device.> If blkid can''t handle that, then it''s got problems > beyond btrfs. On my main machine, it seems to work correctly:> $ sudo blkid > /dev/sda: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="5fd56eec-5e26-4c1f-a02a-f86550e4aefe" TYPE="btrfs" > /dev/sdc: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="4e392bea-f39a-4cba-b78c-c712479bf3f0" TYPE="btrfs" > /dev/sde: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="5e2555bd-bf36-430b-af5a-aa81604afc96" TYPE="btrfs" > /dev/sdp: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="404d13f5-0231-46db-a311-ad7a4f99eef3" TYPE="btrfs" > /dev/sdr: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="90469059-f012-4b6e-9233-8c591cbeaa80" TYPE="btrfs" > /dev/sdq: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="646d3d32-5193-4fcd-afb2-43f14122a149" TYPE="btrfs" > /dev/sds: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > UUID_SUB="f4d4dbb2-f2bb-4e54-bbf9-4bb5474e9ef1" TYPE="btrfs"Is "media" mounted?> My blkid version:> blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011)It''s older than my actual version, but I had found this problem more than a year ago. 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, Jan 3, 2013 at 11:57 AM, Helmut Hullen <Hullen@t-online.de> wrote:> But other filesystems don''t put the label onto more than 1 device. > There''s the problem for/with btrfs.Other filesystems don''t exist on more than one device, so of course they don''t put a label on more than one device. -- 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, cwillu, Du meintest am 03.01.13:>> But other filesystems don''t put the label onto more than 1 device. >> There''s the problem for/with btrfs.> Other filesystems don''t exist on more than one device, so of course > they don''t put a label on more than one device.Yes, I know. And let me repeat the problem: programs like "blkid" don''t work if more than 1 device has the same label. 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, Jan 03, 2013 at 06:57:00PM +0100, Helmut Hullen wrote:> Du meintest am 03.01.13: > >> But for what purpose offers "mkfs.btrfs" this option? > > > So that you don''t have to run the label command immediately after > > making the filesystem. Most mkfs implementations for different > > filesystems have something similar, usually with the -L option. > > But other filesystems don''t put the label onto more than 1 device. > There''s the problem for/with btrfs.Aargh. How many times do I have to say this? Devices are not given labels. *Filesystems* are given labels.> The label has to be unique for the whole machine.Wrong. You can have several filesystems on a machine with the same label. It doesn''t mean that they''re easily managable, but there''s nothing that will stop it from happening. If you want a unique label for a *device*, take a look at the symlinks in /dev/disk/by-id, and the udev rules that generate them. Trying to use filesystem labels to give unique and stable device IDs is the wrong tool for the job.> >> Without this double-labelled (?) devices "blkid" shows all devices > >> with > > > "Double-labelled"? The filesystem has one label, belonging to the > > filesystem. I don''t see where the "double-labelling" comes in. > > As I described: > > mkfs.btrfs -d raid0 -m raid1 -l mylabel /dev/sdb /dev/sdc /dev/sdd > > labels all three devices with the same name, and then programs like > "blkid" or "findfs" don''t find any label (for all labelled devices, not > only for btrfs devices). > > And as I have written before: > > file -s /dev/sdb > file -s /dev/sdc > file -s /dev/sdd > > shows for each of these devices the same label.As I said above, you''re expecting something which just isn''t true. Filesystems have labels, not devices. If you want to have unique labels on devices, then you''re going to have to write some udev rules to generate them for you, and then refer to /dev/helmuts-devices/foo (or whatever you want to call them). Mucking around with filesystem labels is not going to give you a unique label for a device, because the system simply doesn''t work like that.> -------------- > > When I run > > mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd > > and then > > btrfs filesystem label /dev/sdb mylabel > > then only "/dev/sdb" shows this label (as long as none of the 3 devices > is mounted).This is probably a (minor) bug. You should be getting all of the devices with the same label here (since it''s the same filesystem). I suspect that it''s down to the label command only updating one superblock when used offline, or possibly some kind of caching thing. Does running btrfs dev scan immediately after the label command make a difference?> When I then run > > mount LABEL=mylabel /mnt/btr > > then all works fine. And then (after mounting) > > blkid /dev/sdb > blkid /dev/sdc > blkid /dev/sdd > > show the same label.This last result is the correct behaviour. All the devices of the filesystem show the filesystem''s label.> blkid > > without any device seems to hang - may be I haven''t waited long enough.It took a little while for it to run on my machine, but no more than a couple of minutes at the outside.> >> (if defined) their labels. When I define the same label for more > >> than 1 device (btrfs or ext2fs or ...) then "blkid" shows nothing. > >> No output for any of the devices. > > > This is a fault in the version of blkid you''re running, then. > > here: "blkid from until-linux 2.21.2 (libblkid 2.21.0, 25-May-2012)". > And older versions. > > > There''s nothing to stop me from labelling two ext2 filesystems with > > the same label. > > That part is right: I can label more than 1 device with the same name, > not only under btrfs.*Filesystem*, not *device*. You label *filesystems*.> But then (I had written this problem) programs like "blkid" don''t find > any labelled device.It terminates with no output? Or you get bored of waiting and hit ^C first? If the former, that''s a problem with blkid. If the latter... it''s probably not a problem.> > If blkid can''t handle that, then it''s got problems > > beyond btrfs. On my main machine, it seems to work correctly: > > > $ sudo blkid > > /dev/sda: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="5fd56eec-5e26-4c1f-a02a-f86550e4aefe" TYPE="btrfs" > > /dev/sdc: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="4e392bea-f39a-4cba-b78c-c712479bf3f0" TYPE="btrfs" > > /dev/sde: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="5e2555bd-bf36-430b-af5a-aa81604afc96" TYPE="btrfs" > > /dev/sdp: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="404d13f5-0231-46db-a311-ad7a4f99eef3" TYPE="btrfs" > > /dev/sdr: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="90469059-f012-4b6e-9233-8c591cbeaa80" TYPE="btrfs" > > /dev/sdq: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="646d3d32-5193-4fcd-afb2-43f14122a149" TYPE="btrfs" > > /dev/sds: LABEL="media" UUID="3993e50e-a926-48a4-867f-36b53d924c35" > > UUID_SUB="f4d4dbb2-f2bb-4e54-bbf9-4bb5474e9ef1" TYPE="btrfs" > > Is "media" mounted?Yes.> > My blkid version: > > > blkid from util-linux 2.20.1 (libblkid 2.20.0, 19-Oct-2011) > > It''s older than my actual version, but I had found this problem more > than a year ago.Other than the fact that btrfs fi label doesn''t seem to be updating the label on every device without mounting the FS first, everything you''ve reported here is working as it should. 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 --- This chap Anon is writing some perfectly lovely stuff --- at the moment.
Hallo, Hugo, Du meintest am 03.01.13:>>>> But for what purpose offers "mkfs.btrfs" this option?>>> So that you don''t have to run the label command immediately >>> after making the filesystem.>> But other filesystems don''t put the label onto more than 1 device. >> There''s the problem for/with btrfs.> Aargh. How many times do I have to say this?> Devices are not given labels. > *Filesystems* are given labels.And "mkfs.btrfs" combines working with devices and working with a filesystem. blkid /dev/sdb shows (if set) the label of a device (among other data).>> The label has to be unique for the whole machine.> Wrong. You can have several filesystems on a machine with the same > label.On my machines that doesn''t work when I use programs like "blkid" or "findfs". They don''t work when there is more than 1 device with the same label. That''s no special btrfs problem, that happens with (p.e.) ext4fs too.> It doesn''t mean that they''re easily managable, but there''s > nothing that will stop it from happening.> If you want a unique label for a *device*, take a look at the > symlinks in /dev/disk/by-id, and the udev rules that generate them.Sorry - I don''t use "udev" (I''ve told it long time ago). And I still believe that "btrfs" doesn''t depend on "udev".> Trying to use filesystem labels to give unique and stable device IDs > is the wrong tool for the job.I beg to differ. On my machines it''s the simpliest way, and it''s a sure way. [...]> As I said above, you''re expecting something which just isn''t true. > Filesystems have labels, not devices. If you want to have unique > labels on devices, then you''re going to have to write some udev rules > to generate them for you, and then refer to /dev/helmuts-devices/foo > (or whatever you want to call them).And how is the way for a system which doesn''t use "udev"? Labelling via "btrfs filesystem label <device> <label>" works well. 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
Device can mean more than one thing, physical device, partition, md device, logical volume, etc. Label is more narrowly defined to that of filesystems. MBR has no mechanism for labeling the disk itself or the partitions. So /dev/sda cannot have a label or a name. Whereas with GPT, there is a field for each partition to have a name, completely independent of the file system used. So if you really want physical devices given a name, the closest thing you have to that is GPT. On Jan 3, 2013, at 12:08 PM, Hullen@t-online.de (Helmut Hullen) wrote:> Labelling via "btrfs filesystem label <device> <label>" works well.It''s a bug. I''m able to reproduce it as well. The command language itself indicates its the fs that''s to be labeled. "device" in this case maps a /dev/X device to a fs UUID. It always should apply to the file system. If you want to name your partitions, use GPT. Chris Murphy-- 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, Jan 03, 2013 at 08:08:00PM +0100, Helmut Hullen wrote:> Hallo, Hugo, > > Du meintest am 03.01.13: > > >>>> But for what purpose offers "mkfs.btrfs" this option? > > >>> So that you don''t have to run the label command immediately > >>> after making the filesystem. > > > >> But other filesystems don''t put the label onto more than 1 device. > >> There''s the problem for/with btrfs. > > > Aargh. How many times do I have to say this? > > > Devices are not given labels. > > *Filesystems* are given labels. > > And "mkfs.btrfs" combines working with devices and working with a > filesystem.As do all mkfs implementations. They write a filesystem to a device (or devices), and optionally give the filesystem a label. They don''t put labels on devices, except incidentally where each filesystem exists on one or more devices.> blkid /dev/sdb > > shows (if set) the label of a device (among other data).No, it shows the label of the filesystem that lives on that device. Other devices may have another part of the same filesystem on them, and will show the same label. I repeat: devices do not have labels.> >> The label has to be unique for the whole machine. > > > Wrong. You can have several filesystems on a machine with the same > > label. > > On my machines that doesn''t work when I use programs like "blkid" or > "findfs". They don''t work when there is more than 1 device with the same > label. That''s no special btrfs problem, that happens with (p.e.) ext4fs > too.OK, and that''s a blkid problem, not a btrfs problem.> > It doesn''t mean that they''re easily managable, but there''s > > nothing that will stop it from happening. > > > If you want a unique label for a *device*, take a look at the > > symlinks in /dev/disk/by-id, and the udev rules that generate them. > > Sorry - I don''t use "udev" (I''ve told it long time ago). And I still > believe that "btrfs" doesn''t depend on "udev".No, btrfs doesn''t depend on udev. However, trying to make a unique device label out of a filesystem label won''t work. This isn''t a bug, it''s not something that was ever guaranteed, it''s just the wrong approach. You need to find another one -- see below for the options that I can see.> > Trying to use filesystem labels to give unique and stable device IDs > > is the wrong tool for the job. > > I beg to differ. On my machines it''s the simpliest way, and it''s a sure > way.No, because *it* *doesn''t* *work*. This is not a bug. This is how things have always behaved -- you''re relying on an assumption (one FS per device) which simply isn''t true any longer. You may think it''s simpler, but that''s because your assumptions are incorrect. The world does not work the way you think it does. I''m sorry this makes things hard for you, but what you''re asking for is not in scope for a filesystem -- any filesystem.> [...] > > > > As I said above, you''re expecting something which just isn''t true. > > Filesystems have labels, not devices. If you want to have unique > > labels on devices, then you''re going to have to write some udev rules > > to generate them for you, and then refer to /dev/helmuts-devices/foo > > (or whatever you want to call them). > > And how is the way for a system which doesn''t use "udev"?There isn''t one ready-made. Your options are: * run udev * write something which uses (e.g.) SMART information on block devices to extract a unique ID, and convert that into a stable device label (which is effectively what udev does) * find some piece of the device which isn''t going to be overwritten by partition tables, GPTs, filesystems, or other kinds of metadata, and write your label into there; again, you will need to develop your own tool for reading/writing this information> Labelling via "btrfs filesystem label <device> <label>" works well.Clearly it doesn''t, because you''re having problems with it. The behaviour where only one device in the FS gets the label, immediately after a btrfs label command, is a bug -- *all* of the devices in the FS should get the label. You''re trying to rely on the behaviour of a bug, not on the designed behaviour of the system. You need to find some other way of doing this. btrfs is working as it should, and I''m afraid you''re using the wrong tools for the job you''re trying to do. 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 --- O tempura! O moresushi! ---
On Jan 3, 2013, at 12:18 PM, Chris Murphy <lists@colorremedies.com> wrote:> > On Jan 3, 2013, at 12:08 PM, Hullen@t-online.de (Helmut Hullen) wrote: > >> Labelling via "btrfs filesystem label <device> <label>" works well. > > It''s a bug. I''m able to reproduce it as well. The command language itself indicates its the fs that''s to be labeled. "device" in this case maps a /dev/X device to a fs UUID. It always should apply to the file system. If you want to name your partitions, use GPT.OK on a Fedora 18 test system with kernel 3.6.11-3 and btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18.x86_64 I''m getting different results. File system is never mounted for this test. # mkfs.btrfs -L test /dev/sd[bc] # btrfs fi label /dev/sdb test # btrfs fi label /dev/sdc test # btrfs fi label /dev/sdc test2 # btrfs fi label /dev/sdc test2 # btrfs fi label /dev/sdb test2 So ''btrfs fi label'' relabeling with an unmounted system changes the file system label metadata on all member devices, according to btrfs fi label. Now when I use file: # file -s /dev/sdb /dev/sdb: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize 4096, leafsize 4096) # file -s /dev/sdc /dev/sdc: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize 4096, leafsize 4096) Again it correctly reports the label, even though I had only changed the label on sdc (which actually is improper language, I changed the label on the file system implied by device sdc which also extends to device sdb). And then for blkid: # blkid /dev/sdb: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" UUID_SUB="a5bbaa83-6d6f-45dc-9804-9442350c3bc9" TYPE="btrfs" /dev/sdc: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" UUID_SUB="01e0bc77-cfdf-4bd7-bfd3-05e14affa66a" TYPE="btrfs" So again, the correct filesystem label is returned, for this unmounted file system. Chris Murphy -- 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, Chris, Du meintest am 03.01.13:> Device can mean more than one thing, physical device, partition, md > device, logical volume, etc.> Label is more narrowly defined to that of filesystems.> MBR has no mechanism for labeling the disk itself or the partitions. > So /dev/sda cannot have a label or a name.Sure? btrfs filesystem label /dev/sdb mylabel works, and then btrfs filesystem label /dev/sdb shows "mylabel". Also: findfs LABEL=mylabel shows "/dev/sdb" blkid /dev/sdb shows (among other data) "LABEL=mylabel" Except for the "btrfs" command: same behaviour as with other filesystems. Especially with CDs and DVDs (which normally don''t use partitions). 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
Hallo, Hugo, Du meintest am 03.01.13: [...]>>> Trying to use filesystem labels to give unique and stable device >>> IDs is the wrong tool for the job.>> I beg to differ. On my machines it''s the simpliest way, and it''s a >> sure way.> No, because *it* *doesn''t* *work*. This is not a bug. This is how > things have always behaved -- you''re relying on an assumption (one FS > per device) which simply isn''t true any longer.No - I don''t rely on such an assumption. In the special case I''m just working with I want to use the whole disk only for btrfs. In other cases I work with partitions, and there is just the same problem: at least "blkid" and "findfs" don''t work when more than 1 device has the same label (p.e. /dev/sda3 and /dev/sdc5).>> And how is the way for a system which doesn''t use "udev"?> There isn''t one ready-made. Your options are:> * run udev> * write something which uses (e.g.) SMART information on block > devices to extract a unique ID, and convert that into a stable > device label (which is effectively what udev does)Sorry - I don''t need the "unique ID" for the machines. I can use (p.e.) e2label /dev/sda3 Var for labelling an ext2/3/4 partition. Works like a charm, especially for USB disks.> * find some piece of the device which isn''t going to be overwritten > by partition tables, GPTs, filesystems, or other kinds of > metadata, and write your label into there; again, you will need to > develop your own tool for reading/writing this informationSorry - that''s not necessary. When I connect the disk then I can search with "findfs" without having mounted any partition.>> Labelling via "btrfs filesystem label <device> <label>" works well.> Clearly it doesn''t, because you''re having problems with it.No - not at all! I''ve only problems when I use the "-L" option of "mkfs.btrfs" together with more than 1 device in the "mkfs.btrfs" command.> The > behaviour where only one device in the FS gets the label, immediately > after a btrfs label command, is a bug -- *all* of the devices in the > FS should get the label. You''re trying to rely on the behaviour of a > bug, not on the designed behaviour of the system.What works: Building the filesystem with "mkfs.btrfs", without the "-L" option Then (p.e.) btrfs filesystem label <device> <label> (unmounted system) Then I can check the existence (not only for btrfs formatted disks) with findfs LABEL=<label> && mount LABEL=<label> <mountpoint> As mentioned: works not only with btrfs, works fine especially for USB disks. I don''t need any UUID etc. for this way of identyfying. I don''t need to change the mount directive when I change a smaller disk to a bigger disk. 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
Hallo, Chris, Du meintest am 03.01.13:> So ''btrfs fi label'' relabeling with an unmounted system changes the > file system label metadata on all member devices, according to btrfs > fi label. Now when I use file:On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) btrfs fi label /dev/sdb mylabel only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" and "/dev/sdd" remain without label.> # file -s /dev/sdb > /dev/sdb: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize > 4096, leafsize 4096) > # file -s /dev/sdc > /dev/sdc: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize > 4096, leafsize 4096)> Again it correctly reports the label, even though I had only changed > the label on sdc (which actually is improper language, I changed the > label on the file system implied by device sdc which also extends to > device sdb).Strange. Actually the btrfs system is mounted and has to run a job with needs about 5 days - I may not stop it. But before the first mounting of the system only "/dev/sdb" showed the label. Maybe with the first mounting the label spreads over all disks.> > And then for blkid:> # blkid > /dev/sdb: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" > UUID_SUB="a5bbaa83-6d6f-45dc-9804-9442350c3bc9" TYPE="btrfs" > /dev/sdc: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" > UUID_SUB="01e0bc77-cfdf-4bd7-bfd3-05e14affa66a" TYPE="btrfs"Strange - in another way. Here "blkid" (without any device) hangs. See the attachment ("strace blkid"). Viele Gruesse! Helmut
On Jan 3, 2013, at 12:59 PM, Helmut Hullen <Hullen@t-online.de> wrote:>> MBR has no mechanism for labeling the disk itself or the partitions. >> So /dev/sda cannot have a label or a name. > > > Sure?Yes. MBR itself has no place holder to encode a disk name or partition name. http://en.wikipedia.org/wiki/Master_boot_record GPT does allow for partition names, offset 56. http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_entries> btrfs filesystem label /dev/sdb mylabelThat is a file system label. Hence the command "filesystem label".> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) > > btrfs fi label /dev/sdb mylabel > > only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" and > "/dev/sdd" remain without label.If I create a two device btrfs file system without a label, and then relabel it, all device members are relabeled - but again this is the wrong language. The devices do not have labels, it''s the file system that has the label.> for labelling an ext2/3/4 partition. Works like a charm, especially for > USB disks.Again, even with ext[234] you are not labeling a partition. You are labeling a file system. In fact if I use LVM to place /dev/sda /dev/sdb /dev/sdc into a VG, then export that whole VG as one LV, then format it ext4 with label "hellokitty" again that file system is labeled "hellokitty" which spans three devices. The devices are not what''s named. Same for md and dmraid devices. Somehow in your mind you''re OK abstracting the LV as a kind of "device" but you''re unwilling to consider a Btrfs file system a kind of "device" also. In the case of ext4 on LVM, you''re totally OK ignoring the fact that /dev/sda, /dev/sdb, /dev/sdc all have the same label in effect. But somehow it gets your goat when Btrfs is doing the same thing. Because it''s the *filesystem* that''s labelled. Chris Murphy-- 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, Jan 03, 2013 at 09:28:00PM +0100, Helmut Hullen wrote:> Hallo, Chris, > > Du meintest am 03.01.13: > > > So ''btrfs fi label'' relabeling with an unmounted system changes the > > file system label metadata on all member devices, according to btrfs > > fi label. Now when I use file: > > On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) > > btrfs fi label /dev/sdb mylabel > > only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" and > "/dev/sdd" remain without label.This is a bug.> > # file -s /dev/sdb > > /dev/sdb: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize > > 4096, leafsize 4096) > > # file -s /dev/sdc > > /dev/sdc: BTRFS Filesystem (label "test2", sectorsize 4096, nodesize > > 4096, leafsize 4096) > > > Again it correctly reports the label, even though I had only changed > > the label on sdc (which actually is improper language, I changed the > > label on the file system implied by device sdc which also extends to > > device sdb). > > Strange. > Actually the btrfs system is mounted and has to run a job with needs > about 5 days - I may not stop it. > > But before the first mounting of the system only "/dev/sdb" showed the > label. Maybe with the first mounting the label spreads over all disks.Probably.> > And then for blkid: > > > # blkid > > /dev/sdb: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" > > UUID_SUB="a5bbaa83-6d6f-45dc-9804-9442350c3bc9" TYPE="btrfs" > > /dev/sdc: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" > > UUID_SUB="01e0bc77-cfdf-4bd7-bfd3-05e14affa66a" TYPE="btrfs" > > Strange - in another way. > > Here "blkid" (without any device) hangs. See the attachment ("strace > blkid").[snip]> stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0 > open("/dev/fd0", O_RDONLY|O_LARGEFILE) = 4 > fadvise64_64(4, 0, 0, POSIX_FADV_RANDOM) = 0 > fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0 > uname({sys="Linux", node="izar", ...}) = 0 > ioctl(4, BLKGETSIZE64, 0x8050d5c) = 0 > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, 0x80517a4, 1024) = -1 EIO (Input/output error) > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, 0x80517a4, 1024) = -1 EIO (Input/output error) > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, 0x80517a4, 1024) = -1 EIO (Input/output error) > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, 0x80517a4, 1024) = -1 EIO (Input/output error) > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, 0x80517a4, 1024) = -1 EIO (Input/output error) > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, 0x80517a4, 1024) = -1 EIO (Input/output error) > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, 0x80517a4, 1024) = -1 EIO (Input/output error) > _llseek(4, 0, [0], SEEK_SET) = 0 > read(4, <unfinished ...>This is waiting for /dev/fd0 to return some data. I guess it''ll give up after a few times round (8? 10?) and return some results. 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 --- Putting U back in Honor, Valor, and Trth ---
On Jan 3, 2013, at 2:23 PM, Hugo Mills <hugo@carfax.org.uk> wrote:> On Thu, Jan 03, 2013 at 09:28:00PM +0100, Helmut Hullen wrote: >> >> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) >> >> btrfs fi label /dev/sdb mylabel >> >> only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" and >> "/dev/sdd" remain without label. > > This is a bug.It''s a bug that appears to be fixed. I inadvertently tested it first on CentOS 6.0 which has quite an older kernel and btrfsprogs. And Fedora 18 of course has a much newer kernel and btrfs-progs so I have no idea when in between those two this was fixed. Helmut what kernel and btrfs-progs or distribution are you using? I think newer progs fixes this.>> >> But before the first mounting of the system only "/dev/sdb" showed the >> label. Maybe with the first mounting the label spreads over all disks. > > Probably.Not in my case with F18. I never mounted it once and immediately all commands saw the file system label change. Chris Murphy -- 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, Hugo, Du meintest am 03.01.13:>> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) >> >> btrfs fi label /dev/sdb mylabel >> >> only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" >> and "/dev/sdd" remain without label.> This is a bug.Hmmm - I''ll test it on another system.>> Strange - in another way. >> >> Here "blkid" (without any device) hangs. See the attachment ("strace >> blkid").> [snip]>> stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), >> ...}) = 0 open("/dev/fd0", O_RDONLY|O_LARGEFILE) = 4 >> fadvise64_64(4, 0, 0, POSIX_FADV_RANDOM) = 0 >> fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0 >> uname({sys="Linux", node="izar", ...}) = 0 >> ioctl(4, BLKGETSIZE64, 0x8050d5c) = 0 >> _llseek(4, 0, [0], SEEK_SET) = 0 >> read(4, 0x80517a4, 1024) = -1 EIO (Input/output >> error) _llseek(4, 0, [0], SEEK_SET) = 0 >> read(4, 0x80517a4, 1024) = -1 EIO (Input/output >> error) _llseek(4, 0, [0], SEEK_SET) = 0 >> read(4, 0x80517a4, 1024) = -1 EIO (Input/output >> error) _llseek(4, 0, [0], SEEK_SET) = 0 >> read(4, 0x80517a4, 1024) = -1 EIO (Input/output >> error) _llseek(4, 0, [0], SEEK_SET) = 0 >> read(4, 0x80517a4, 1024) = -1 EIO (Input/output >> error) _llseek(4, 0, [0], SEEK_SET) = 0 >> read(4, 0x80517a4, 1024) = -1 EIO (Input/output >> error) _llseek(4, 0, [0], SEEK_SET) = 0 >> read(4, 0x80517a4, 1024) = -1 EIO (Input/output >> error) _llseek(4, 0, [0], SEEK_SET) = 0 >> read(4, <unfinished ...>> This is waiting for /dev/fd0 to return some data. I guess it''ll > give up after a few times round (8? 10?) and return some results.I''ve waited 10 minutes ... I know a similar behaviour p.e. when I run btrfs-show Then btrfs seems to test all block devices in "/dev" (no "udev" system) and then tells most times failed to read /dev/<nonexistent device>: No such device or address But those (unnecessary) messages come quick, with only some seconds delay. ----------------- The above log file comes from a machine without floppy disk (a laptop). Running "blkid" on an elder tower (with installed and usable floppy disk) also checks for "/dev/fd0" and then tells "ok". Tomorrow I''ll test this behaviour on another laptop. Could be a "blkid" error. 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
Hallo, Chris, Du meintest am 03.01.13:>>> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) >>> >>> btrfs fi label /dev/sdb mylabel >>> >>> only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" >>> and "/dev/sdd" remain without label.>> This is a bug.> It''s a bug that appears to be fixed. I inadvertently tested it first > on CentOS 6.0 which has quite an older kernel and btrfsprogs. And > Fedora 18 of course has a much newer kernel and btrfs-progs so I have > no idea when in between those two this was fixed.> Helmut what kernel and btrfs-progs or distribution are you using? I > think newer progs fixes this.Kernel 3.4.6 (self made), btrfs-progs downloaded and compiled 2 days ago (Mason version, not Mills version). I''ve just brewed Kernel 3.6.11 but I have to wait some days (backing up some Tbytes of data) before I can test btrfs with this newer kernel. But looking for btrfs in the ChangeLog files for kernels 3.4 to 3.6 doesn''t show any entry which might be related to the above error. (Kernels 3.4.3, 3.4.5, 3.4.8, 3.5.1, 3.5.4) 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
Hallo, Hugo, Du meintest am 03.01.13:>> On my system (a bundle of /dev/sdb, /dev/sdc, /dev/sdd) >> >> btrfs fi label /dev/sdb mylabel >> >> only sets the label on the (unmounted) device /dev/sdb. "/dev/sdc" >> and "/dev/sdd" remain without label.> This is a bug.Very very strange ... I''ve tested the commands on another laptop, with another (older) kernel, the same btrfs-progs-packet and the same "blkid" version. "blkid" doesn''t hang searching the (non existent) floppy drive. mkfs.btrfs -d raid0 -m raid1 -L mylabel /dev/sdb1 /dev/sdb2 /dev/sdb3 works, blkid then shows all 3 btrfs partitions with the same label, findfs LABEL=mylabel shows one (the first?) partition with this label. Fine. But why does that work on the one laptop but not on the other? ------------------ I''ll test this behaviour on the other laptop with the older kernel (3.3.7), but it''s yet busy, backung up some TBytes of data. ------------------ Some minutes later: "blkid" hangs again. [...] access("/dev/sda1", F_OK) = 0 access("/dev/sda2", F_OK) = 0 access("/dev/sda3", F_OK) = 0 access("/dev/sda4", F_OK) = 0 access("/dev/sdb1", F_OK) = 0 access("/dev/sdb2", F_OK) = 0 access("/dev/sdb3", F_OK) = 0 access("/dev/sdb4", F_OK) = 0 read(3, "", 4096) = 0 _llseek(3, 1240, [1240], SEEK_SET) = 0 close(3) = 0 munmap(0x40025000, 4096) = 0 open("/run/blkid/blkid.tab", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=1240, ...}) = 0 close(3) = 0 open("/proc/evms/volumes", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/proc/lvm/VGs", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/dev", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 getdents64(3, /* 1084 entries */, 32768) = 32752 getdents64(3, /* 749 entries */, 32768) = 22672 getdents64(3, /* 0 entries */, 32768) = 0 close(3) = 0 openat(AT_FDCWD, "/devfs", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/devices", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/proc/partitions", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40025000 read(3, "major minor #blocks name\n\n 2"..., 1024) = 384 stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0 access("/dev/fd0", F_OK) = 0 time(NULL) = 1357301320 stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0 open("/dev/fd0", O_RDONLY|O_LARGEFILE) = 4 fadvise64_64(4, 0, 0, POSIX_FADV_RANDOM) = 0 fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0 uname({sys="Linux", node="ElNath.wm8.hullen.de", ...}) = 0 ioctl(4, BLKGETSIZE64, 0x8050dbc) = 0 _llseek(4, 0, [0], SEEK_SET) = 0 read(4, 0x8051804, 1024) = -1 EIO (Input/output error) _llseek(4, 0, [0], SEEK_SET) = 0 read(4, 0x8051804, 1024) = -1 EIO (Input/output error) _llseek(4, 0, [0], SEEK_SET) = 0 read(4, <unfinished ...> # ------------------------------------ Is there something like "/dev/dice" running? 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
Hallo, Chris, Du meintest am 03.01.13:>>> MBR has no mechanism for labeling the disk itself or the >>> partitions. So /dev/sda cannot have a label or a name.>> Sure?> Yes. MBR itself has no place holder to encode a disk name or > partition name. http://en.wikipedia.org/wiki/Master_boot_recordI''ve just played a bit ... btrfs-show tells ** ** WARNING: this program is considered deprecated ** Please consider to switch to the btrfs utility ** Label: USBmm uuid: 43ad1782-5d1c-4211-9333-506bcfdbc3a5 Total devices 1 FS bytes used 28.00KB devid 1 size 3.78GB used 423.50MB path /dev/sdb Label: mylabel uuid: e9716633-49f1-44a0-a3b4-90ba9736a540 Total devices 3 FS bytes used 28.00KB devid 2 size 1.00GB used 110.38MB path /dev/sdb2 devid 1 size 1.00GB used 275.94MB path /dev/sdb1 devid 3 size 1.00GB used 263.94MB path /dev/sdb3 Btrfs Btrfs v0.19 # ---------------------------------------- The "USBmm" entry remains from mkfs.btrfs -d raid0 -m raid1 -L USBmm /dev/sdb Then I run "fdisk /dev/sdb" and created 4 partitions on "/dev/sdb" without previous overwriting it with zeros. And then mkfs.btrfs -d raid0 -m raid1 -L mylabel /dev/sdb1 /dev/sdb2 /dev/sdb3 Inspecting the first sectors of "/dev/sdb" shows the string "USBmm" at the beginning of the second 64-kByte block (0x10120 ... 0x1012f). The "mylabel" entries are somewhere after the first 128 kByte. 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
Hallo, Hugo, Du meintest am 03.01.13: [...]>>> And then for blkid: >> >>> # blkid >>> /dev/sdb: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" >>> UUID_SUB="a5bbaa83-6d6f-45dc-9804-9442350c3bc9" TYPE="btrfs" >>> /dev/sdc: LABEL="test2" UUID="3d5390d0-a41b-4f70-a4e5-b47295d3c717" >>> UUID_SUB="01e0bc77-cfdf-4bd7-bfd3-05e14affa66a" TYPE="btrfs" >> >> Strange - in another way. >> >> Here "blkid" (without any device) hangs. See the attachment ("strace >> blkid").Additional: Working as "root": blkid hangs (at least sometimes). Working as underprivileged user: /sbin/blkid shows many informations (and doesn''t hang). But it doesn''t show the btrfs devices/partitions. /sbin/blkid /dev/sdb shows the btrfs label. Maybe it''s mostly or only a blkid problem - I''ll subscribe the "util- linux" mailinglist. -------------------------------- 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 Jan 4, 2013, at 1:59 PM, Helmut Hullen <Hullen@t-online.de> wrote:> > Additional: > > Working as "root": > > blkid > > hangs (at least sometimes).Maybe use the latest debug kernel for your distro and see if you can reproduce the hang, and what you get in dmesg with the debug kernel. What version of util-linux-ng? Chris Murphy -- 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, 3. Januar 2013 schrieb Helmut Hullen:> Hallo, Hugo,Hi Helmut,> Du meintest am 03.01.13: > > [...] > > >>> Trying to use filesystem labels to give unique and stable device > >>> IDs is the wrong tool for the job. > > >> I beg to differ. On my machines it''s the simpliest way, and it''s a > >> sure way. > > > No, because it doesn''t *work*. This is not a bug. This is how > > things have always behaved -- you''re relying on an assumption (one FS > > per device) which simply isn''t true any longer. > > No - I don''t rely on such an assumption. > In the special case I''m just working with I want to use the whole disk > only for btrfs. > > In other cases I work with partitions, and there is just the same > problem: at least "blkid" and "findfs" don''t work when more than 1 > device has the same label (p.e. /dev/sda3 and /dev/sdc5).Helmut, it has been shown here in the thread, that they *do* work in newer versions. If they don´t work for you please compare your version with the ones that do work and file a bug report for your Linux distribution. I use labels in fstab as well and since usually especially for the boot devices no device with same label comes in, it works. But using labels you have to be aware that there might happen name clashes. A BTRFS filesystem which is on more than one device, be it partitition, disk, LV or what not and having the same label for itself on every device is *no* such name clash, is just working as intended. And it should work in /etc/fstab, provided that btrfs device scan is run before you try to mount it. No matter how much you try *not to understand* that *filesystems* are labeled here instead of devices, it is still filesystems that are labeled here. Each one in a different place on the volume(s) it spans somewhere in its metadata, usually suberblock. Thats why blkid has to support a filesystem in order to print its label, if it doesn´t support it yet, it can´t find the label, cause it doesn´t know where the *filesystem* has stored it. And here just to show it again to you: The files of 1 GB: merkaba:/mnt/zeit> truncate -s 1G btrfs1 merkaba:/mnt/zeit> truncate -s 1G btrfs2 merkaba:/mnt/zeit> truncate -s 1G btrfs3 The devices for them: merkaba:/mnt/zeit> losetup /dev/loop0 btrfs1 merkaba:/mnt/zeit> losetup /dev/loop1 btrfs2 merkaba:/mnt/zeit> losetup /dev/loop2 btrfs3 mkfs.btrfs with label: merkaba:/mnt/zeit> mkfs.btrfs -L schlumpf -d raid1 -m raid1 /dev/loop[0-2] WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using failed to read /dev/sr0 failed to read /dev/sr0 adding device /dev/loop1 id 2 failed to read /dev/sr0 adding device /dev/loop2 id 3 fs created label schlumpf on /dev/loop0 nodesize 4096 leafsize 4096 sectorsize 4096 size 3.00GB Btrfs Btrfs v0.19 Label there and fine: merkaba:/mnt/zeit> blkid | grep schlumpf /dev/loop0: LABEL="schlumpf" UUID="08802eb0-2040-4b7d-a4eb-81617f492168" UUID_SUB="453b462b-d1cc-4977-865e-f4ab7d1dee2c" TYPE="btrfs" /dev/loop1: LABEL="schlumpf" UUID="08802eb0-2040-4b7d-a4eb-81617f492168" UUID_SUB="41c9810e-41fb-4ac4-8010-718790c83b82" TYPE="btrfs" /dev/loop2: LABEL="schlumpf" UUID="08802eb0-2040-4b7d-a4eb-81617f492168" UUID_SUB="8b2b091a-ec88-4c0b-80e6-df06f6d629b7" TYPE="btrfs" merkaba:/mnt/zeit> findfs LABEL=schlumpf /dev/loop2 And changing the label: merkaba:/mnt/zeit> btrfs fi label /dev/loop0 schlumpfine failed to read /dev/sr0 failed to read /dev/sr0 merkaba:/mnt/zeit> blkid | grep schlumpf /dev/loop0: LABEL="schlumpfine" UUID="08802eb0-2040-4b7d-a4eb-81617f492168" UUID_SUB="453b462b-d1cc-4977-865e-f4ab7d1dee2c" TYPE="btrfs" /dev/loop1: LABEL="schlumpfine" UUID="08802eb0-2040-4b7d-a4eb-81617f492168" UUID_SUB="41c9810e-41fb-4ac4-8010-718790c83b82" TYPE="btrfs" /dev/loop2: LABEL="schlumpfine" UUID="08802eb0-2040-4b7d-a4eb-81617f492168" UUID_SUB="8b2b091a-ec88-4c0b-80e6-df06f6d629b7" TYPE="btrfs" merkaba:/mnt/zeit> findfs LABEL=schlumpf findfs: unable to resolve ''LABEL=schlumpf'' merkaba:/mnt/zeit#1> findfs LABEL=schlumpfine /dev/loop2 Thats with: merkaba:~> cat /proc/version Linux version 3.8.0-rc2-tp520 (martin@merkaba) (gcc version 4.7.2 (Debian 4.7.2-4) ) #34 SMP PREEMPT Thu Jan 3 15:46:16 CET 2013 merkaba:~> apt-show-versions btrfs-tools btrfs-tools/sid uptodate 0.19+20121004-1 on Debian/GNU sid. In any of these do not work for you, upgrade and/or file bug against your distribution to provide fixed packages. Thanks, -- 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
Hallo, Martin, Du meintest am 05.01.13:>> No - I don''t rely on such an assumption. >> In the special case I''m just working with I want to use the whole >> disk only for btrfs. >> >> In other cases I work with partitions, and there is just the same >> problem: at least "blkid" and "findfs" don''t work when more than 1 >> device has the same label (p.e. /dev/sda3 and /dev/sdc5).It seems to be a problem which is related to "blkid".> Helmut, it has been shown here in the thread, that they *do* work in > newer versions.> If they don?t work for you please compare your version with the ones > that do work and file a bug report for your Linux distribution.blkid from util-linux 2.21.2 (libblkid 2.21.0, 25-May-2012 findfs from the same "util-linux" packet kernel 3.6.11 Is that new enough? ------------------------------------------- Reproducable: USB stick with 3 btrfs partitions cold start without stick, logged in as "root" blkid works Stick inserted: blkid works fdisk -l works btrfs device scan works blkid works btrfs-show works blkid hangs blkid /dev/sdb1 works I don''t know who may be responsible for this problem - btrfs or blkid or both. 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
Hallo, Hugo, Du meintest am 03.01.13:>> My usual way: >> >> mkfs.btrfs -d raid0 -m raid1 /dev/sdb /dev/sdc /dev/sdd ... >> >> One call for some devices. >> Wenn I add the option "-L mylabel" then each device gets the same >> label, and therefore some other programs can''t find the (one) device >> with the defined label.[...]>> Especially >> >> blkid >> findfs LABEL=mylabel >> >> don''t work.> How do you mean, "don''t work"?Seems to be a problem which is invoked by "btrfs-show". Working with an USB stick (3 btrfs partitions, labelled), working as "root", kernel 3.6.11 cold start inserting the stick btrfs device scan ok btrfs fi show ok blkid ok cold start inserting the stick btrfs device scan ok blkid ok btrfs-show ok (?) blkid hangs Maybe the simpliest way is to delete "btrfs-show". 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 Jan 5, 2013, at 5:44 AM, Helmut Hullen <Hullen@t-online.de> wrote:> > blkid from util-linux 2.21.2 (libblkid 2.21.0, 25-May-2012 > findfs from the same "util-linux" packet > kernel 3.6.11 > > Is that new enough?I don''t know. I''m running 3.6.11 and util-linux 2.22.1. The changelog for 2.22.x''s have many blkid entries, but only one btrfs entry. It may be a general bug with blkid that isn''t directly attributable to btrfs though. Chris Murphy-- 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 Jan 5, 2013, at 6:15 AM, Helmut Hullen <Hullen@t-online.de> wrote:> > Seems to be a problem which is invoked by "btrfs-show".Old command. I''m not sure if it''s kept up to date. You should use ''btrfs filesystem show'' or ''btrfs fi show'' for short. Chris Murphy -- 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, Jan 05, 2013 at 12:10:48PM -0700, Chris Murphy wrote:> > On Jan 5, 2013, at 6:15 AM, Helmut Hullen <Hullen@t-online.de> wrote: > > > > Seems to be a problem which is invoked by "btrfs-show". > > Old command. I''m not sure if it''s kept up to date. You should use ''btrfs filesystem show'' or ''btrfs fi show'' for short.Indeed. btrfs-show, btrfs-vol and btrfsctl have been deprecated for quite some time (well over a year), and they''re not well maintained. 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 --- A clear conscience. Where did you get this taste --- for luxuries, Bernard?
Hallo, Chris, Du meintest am 05.01.13:>> Seems to be a problem which is invoked by "btrfs-show".> Old command. I''m not sure if it''s kept up to date. You should use > ''btrfs filesystem show'' or ''btrfs fi show'' for short.Yes - i''ve learned my lesson ... But then: the best solution for other people might be deleting "btrfs- show" from the packet. 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 Jan 5, 2013, at 2:03 PM, Helmut Hullen <Hullen@t-online.de> wrote:> Hallo, Chris, > > Du meintest am 05.01.13: > > >>> Seems to be a problem which is invoked by "btrfs-show". > >> Old command. I''m not sure if it''s kept up to date. You should use >> ''btrfs filesystem show'' or ''btrfs fi show'' for short. > > Yes - i''ve learned my lesson ... > But then: the best solution for other people might be deleting "btrfs- > show" from the packet.Best solution would be for the deprecated commands to be removed from btrfs-progs or -tools or wherever they''re coming from. At this point, if that kills things that depend on them, so much the better. They too need to be updated to use the correct and maintained commands. Chris Murphy-- 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 Helmut On 01/03/2013 10:52 PM, Helmut Hullen wrote:> I know a similar behaviour p.e. when I run > > btrfs-show > > Then btrfs seems to test all block devices in "/dev" (no "udev" system) > and then tells most times"btrfs-show" and "btrfs filesystem show" behave differently. The former (which is deprecated) scans every block device found under /dev. The latter scans every block device found in /proc/partition. For "btrfs filesystem show" it is possible to have the old behaviour passing the "--all-devices" option. The same switch exists also for "btrfs device scan". In order to avoid misunderstanding I suggest you to use "btrfs filesystem show"> > failed to read /dev/<nonexistent device>: No such device or address > > But those (unnecessary) messages come quick, with only some seconds > delay. > > ----------------- > > The above log file comes from a machine without floppy disk (a laptop). > Running "blkid" on an elder tower (with installed and usable floppy > disk) also checks for "/dev/fd0" and then tells "ok". > > Tomorrow I''ll test this behaviour on another laptop. Could be a "blkid" > error. > > 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 >-- gpg @keyserver.linux.it: Goffredo Baroncelli (kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 -- 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
Seemingly Similar Threads
- tool for a comprehensive list of the storage structure
- To loop or not to loop with btrfs
- Determine if a given fs is a btrfs fs
- // RESEND // 7.6: Software RAID1 fails the only meaningful test
- [PATCH] NEW API: add blkid command to print the attributes of the device