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