linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hullen@t-online.de (Helmut Hullen)
To: linux-btrfs@vger.kernel.org
Subject: Re: Option LABEL
Date: 03 Jan 2013 20:08:00 +0100	[thread overview]
Message-ID: <CO8j2OqeCXB@helmut.hullen.de> (raw)
In-Reply-To: <20130103183341.GC19051@carfax.org.uk>

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

  reply	other threads:[~2013-01-03 19:11 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-03 15:14 Option LABEL Helmut Hullen
2013-01-03 16:08 ` Hugo Mills
2013-01-03 16:29   ` Helmut Hullen
2013-01-03 17:01     ` Hugo Mills
2013-01-03 17:43       ` james northrup
2013-01-03 17:57       ` Helmut Hullen
2013-01-03 18:10         ` cwillu
2013-01-03 18:20           ` Helmut Hullen
2013-01-03 19:18             ` Chris Murphy
2013-01-03 19:35               ` Chris Murphy
2013-01-03 20:28                 ` Helmut Hullen
2013-01-03 21:23                   ` Hugo Mills
2013-01-03 21:27                     ` Chris Murphy
2013-01-03 22:07                       ` Helmut Hullen
2013-01-03 21:52                     ` Helmut Hullen
2013-01-06 16:02                       ` Goffredo Baroncelli
2013-01-04 12:11                     ` Helmut Hullen
2013-01-04 20:59                     ` Helmut Hullen
2013-01-04 21:41                       ` Chris Murphy
2013-01-03 19:59               ` Helmut Hullen
2013-01-03 21:17                 ` Chris Murphy
2013-01-04 12:56                   ` Helmut Hullen
2013-01-03 18:33         ` Hugo Mills
2013-01-03 19:08           ` Helmut Hullen [this message]
2013-01-03 19:28             ` Hugo Mills
2013-01-03 20:18               ` Helmut Hullen
2013-01-05 11:36                 ` Martin Steigerwald
2013-01-05 12:44                   ` Helmut Hullen
2013-01-05 19:08                     ` Chris Murphy
2013-01-05 13:15   ` Helmut Hullen
2013-01-05 19:10     ` Chris Murphy
2013-01-05 19:13       ` Hugo Mills
2013-01-05 21:03       ` Helmut Hullen
2013-01-05 21:21         ` Chris Murphy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CO8j2OqeCXB@helmut.hullen.de \
    --to=hullen@t-online.de \
    --cc=helmut@hullen.de \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).