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 21:18:00 +0100	[thread overview]
Message-ID: <CO8jDv4uCXB@helmut.hullen.de> (raw)
In-Reply-To: <20130103192848.GD19051@carfax.org.uk>

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

  reply	other threads:[~2013-01-03 20:36 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
2013-01-03 19:28             ` Hugo Mills
2013-01-03 20:18               ` Helmut Hullen [this message]
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=CO8jDv4uCXB@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).