linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: not all volume types export UUIDs (was: /dev/disk/by-id
Date: Wed, 02 Jul 2008 14:19:10 +0000	[thread overview]
Message-ID: <1215008350.9721.27.camel@linux.site> (raw)
In-Reply-To: <20080702102820.GB16076@piper.oerlikon.madduck.net>

On Wed, 2008-07-02 at 12:28 +0200, martin f krafft wrote:
> also sprach Kay Sievers <kay.sievers@vrfy.org> [2008.07.02.1000 +0200]:
> > UUID's are the right solution here. Fix your mkswap, or re-run it, it
> > has support for this for long:
> 
> Yes, you are right, this does work for many of my cases.

> Unfortunately, there are still volume types out there without UUID
> support, such as LVM (I think), mdadm, and non-LUKS dm-crypt.

Then we should just add links for the raid-members. We already recognize
most of the metadata, just don't do anything with it.

> For
> those, UUIDs will not be available.

Oh, most of them have UUID's.

Anyway, the ID's are _bus_-id's, so the prefix is what we want. They are
in almost all cases unique on the same bus. Most devices which can move
from one bus to another will never share the same id's, like an
USB-storage device has no way to access ATA-data of the enclosed disk,
it will show the serial number of the usb-interface-device, which is
totally different.
ATA and SCSI are special, because of the Linux kernel using SCSI as a
transport for ATA, but we already create ata-* links for SCSI devices
which will show up if vendor=ATA, so this case is already covered.

What kind of id's do you have in mind, which would be the same across
buses?

Thanks,
Kay


  reply	other threads:[~2008-07-02 14:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-02 10:28 not all volume types export UUIDs (was: /dev/disk/by-id symlinks martin f krafft
2008-07-02 14:19 ` Kay Sievers [this message]
2008-07-02 15:49 ` not all volume types export UUIDs (was: /dev/disk/by-id martin f krafft
2008-07-02 15:56 ` Greg KH
2008-07-02 16:06 ` Kay Sievers
2008-07-02 16:17 ` Karl O. Pinc
2008-07-02 16:28 ` not all volume types export UUIDs (was: /dev/disk/by-id symlinks should not include bus) type Kay Sievers
2008-07-03  5:30 ` not all volume types export UUIDs (was: /dev/disk/by-id martin f krafft
2008-07-03  9:02 ` Kay Sievers
2008-07-03 13:42 ` not all volume types export UUIDs (was: /dev/disk/by-id symlinks should not include bus) type Matthew Dharm
2008-07-03 15:12 ` not all volume types export UUIDs (was: /dev/disk/by-id Kay Sievers
2008-07-03 15:33 ` not all volume types export UUIDs (was: /dev/disk/by-id symlinks should not include bus) type Matthew Dharm
2008-07-03 15:36 ` not all volume types export UUIDs (was: /dev/disk/by-id Kay Sievers
2008-07-05 11:55 ` martin f krafft
2008-07-05 12:32 ` Kay Sievers

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=1215008350.9721.27.camel@linux.site \
    --to=kay.sievers@vrfy.org \
    --cc=linux-hotplug@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).