[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mdadm and UUIDs for its component drives



moorning martin: thanks for responding. apologies for not thinking to
ask on debian-user earlier, and apologies for the long-winded style:
just got ddragged out of bed to go chase a lamb out of the garden that
was eating our flowers and vegetables.  if i wasn't stumbling about
half-asleep or concerned for our future food supply i'd find a lamb
head-butting fence posts incredibly funny.

On Sat, Jun 25, 2011 at 8:26 PM, martin f krafft <madduck@debian.org> wrote:

> also sprach Luke Kenneth Casson Leighton <luke.leighton@gmail.com> [2011.06.25.1938 +0200]:
>> mdadm i can confirm goes and hunts down the symlinks and adds
>> /dev/sdd!  i don't _want_ it to add /dev/sdd, i want it to add
>> /dev/disk/by-id/usb-WD_blah_blah :)
>>
>> question is: how?  or, does it not matter: does mdadm use UUIDs internally?
>
> Yes, it uses UUIDs. The problem you describe should not happen.

 ok, so the question therefore morphs into a long-winded
self-answering one: what is it about mdadm that causes people not to
be aware that UUIDs are used internally, such that they invest quite a
bit of time to e.g. modify their udev rules in /etc/ (rather than add
alternatives to /usr/local) and thus make their lives more awkward for
future upgrades, and search for "solutions" such as endeavouring to
use --add /dev/disk/by-id/XXX?

 the answer is that mdadm tracks down the hardlink and displays, as
best i can tell, only that, with no immediately obvious options to get
it to display the disk UUIDs.

 sooo.... here's some further questions:

 * is there an option to mdadm to make it display UUIDs instead of or
as well as the disk name?

 * if not, would adding one be a good idea?

 * also, how about making mention of how mdadm works, in the man page
somewhere reaaasonably prominently?

the basic gist is that mdadm is a fantastic tool, does a far better
job than people believe or understand it to be doing, protects them
from themselves and any lack of knowledge of its inner workings, but
that means that unfortunately it's under-promoted and in danger of
being ignored (or worse, NIH-rewritten!)

 i would hate to see a "better" tool being written which has, at the
very top of its home page, and in all freshmeat and sourceforget
prominent short descriptions, "yeah!  we're l33t!  our software RAID
tool uses UUIDs, which makes it better than mdadm.  we r0ck!"

 :)

 l.


Reply to: