On Jan 3, 2013, at 12:18 PM, Chris Murphy <li...@colorremedies.com> wrote:
> 
> On Jan 3, 2013, at 12:08 PM, hul...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to