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
next prev parent 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).