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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
