Option LABEL

Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 4729 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Option LABEL

[james northrup]

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

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[cwillu]

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.

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Chris Murphy]

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

Re: Option LABEL

[Chris Murphy]

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

Re: Option LABEL

[Helmut Hullen]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

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

[-- Attachment #2: blkid-trace.log --]
[-- Type: text/plain, Size: 6525 bytes --]

execve("/sbin/blkid", ["blkid"], [/* 47 vars */]) = 0
brk(0)                                  = 0x8050000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40024000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=55572, ...}) = 0
mmap2(NULL, 55572, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40025000
close(3)                                = 0
open("/lib/libblkid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0A\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=163440, ...}) = 0
mmap2(NULL, 162160, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40033000
mmap2(0x40059000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26) = 0x40059000
close(3)                                = 0
open("/lib/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\16\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=13244, ...}) = 0
mmap2(NULL, 16004, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4005b000
mmap2(0x4005e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2) = 0x4005e000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\227\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1790836, ...}) = 0
mmap2(NULL, 1591836, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x4005f000
mprotect(0x401dd000, 4096, PROT_NONE)   = 0
mmap2(0x401de000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17e) = 0x401de000
mmap2(0x401e1000, 10780, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401e1000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401e4000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401e5000
set_thread_area({entry_number:-1 -> 6, base_addr:0x401e4bc0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x401de000, 8192, PROT_READ)   = 0
mprotect(0x40021000, 4096, PROT_READ)   = 0
munmap(0x40025000, 55572)               = 0
brk(0)                                  = 0x8050000
brk(0x8071000)                          = 0x8071000
getuid32()                              = 0
geteuid32()                             = 0
getgid32()                              = 0
getegid32()                             = 0
prctl(PR_GET_DUMPABLE)                  = 1
getuid32()                              = 0
geteuid32()                             = 0
getgid32()                              = 0
getegid32()                             = 0
prctl(PR_GET_DUMPABLE)                  = 1
open("/etc/blkid.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/run/blkid/blkid.tab", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=1212, ...}) = 0
fcntl64(3, F_GETFL)                     = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(3, {st_mode=S_IFREG|0644, st_size=1212, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40025000
_llseek(3, 0, [0], SEEK_CUR)            = 0
read(3, "<device DEVNO=\"0x0801\" TIME=\"135"..., 4096) = 1212
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/sdb5", F_OK)               = 0
access("/dev/sdb", F_OK)                = 0
access("/dev/sdc", F_OK)                = 0
access("/dev/sdd", F_OK)                = 0
read(3, "", 4096)                       = 0
_llseek(3, 1212, [1212], 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=1212, ...}) = 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, /* 1115 entries */, 32768) = 32744
getdents64(3, /* 666 entries */, 32768) = 21160
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) = 412
stat64("/dev/fd0", {st_mode=S_IFBLK|0660, st_rdev=makedev(2, 0), ...}) = 0
access("/dev/fd0", F_OK)                = 0
time(NULL)                              = 1357238073
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 ...>

Re: Option LABEL

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Option LABEL

[Chris Murphy]

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

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Goffredo Baroncelli]

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

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Chris Murphy]

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

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Chris Murphy]

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 mylabel

That 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

Re: Option LABEL

[Helmut Hullen]

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_record

I'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

Re: Option LABEL

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 6011 bytes --]

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.                              

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 4617 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Option LABEL

[Helmut Hullen]

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 information

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

Re: Option LABEL

[Martin Steigerwald]

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

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Chris Murphy]

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

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Chris Murphy]

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

Re: Option LABEL

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

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?                         

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Option LABEL

[Helmut Hullen]

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

Re: Option LABEL

[Chris Murphy]

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