Re: udev causing data loss?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Florian Kulzer wrote:
> If that is your only example, then you should change your vote to:
>
> | particularly hated; massive nuisance causing data loss and grief:
> | the modern Linux kernel!!! (asynchronous device discovery)
>
> Here is a simple test to demonstrate that udev takes over the name that
> the kernel chooses:
>
> $ udevadm test $(udevadm info --query=path --name /dev/sda) | grep get_name
> udev_rules_get_name: add symlink 'disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0'
> udev_rules_get_name: no node name set, will use kernel name 'sda'
Good point, well taken; and thank you, Florian. I love it when I'm no
longer believing something that isn't true. Therefore, I wish to retract
a number of my UDEV rants over the past few years :-)
And I'll change my whinage to something about the scan order in the
kernel. I know something had do be done to deal with changing times, and
asynchronous discovery is way cool, but stuff inside the box oughta come
first. And the names should stay put after the install, not just after
the boot (the installer could create some UDEV rules??). It'd also be
nice if the names were predictable, and maybe even had some mnemonic value.
I don't think this is too much to ask...
At the time of my misadventure, I was still expecting sda to be the
lowest ID on the lowest SCSI bus -- there were no SATAs at the time, not
around here anyway. I use UUIDs for boot and fstab now and and never
rely on the /dev block device names to mean much of anything (except the
ones I set myself in 10-local.rules using vendor and model -- haven't
seen a disk drive serial number in udevinfo yet).
I still claim, though, that the floating /dev node names has broken, or
at least caused major PITA with, an awful lot of CL utilities and shell
scripts.
mdadm, I noticed yesterday, seems to be able to figure things out and
build its RAID arrays from the correct disks, even when the /dev names
are have changed since the arrays were defined. Bears looking into -- I
suspect UUIDs, but one mustn't jump to conclusions :-)
- --
Glenn English
ghe@slsware.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkfChwACgkQ04yQfZbbTLYAtgCcDypWVWvGQRysNUT8crkBAghU
KHsAnAmG5HUx4+jPAFaxN+ZB00ChfVio
=0XQW
-----END PGP SIGNATURE-----
Reply to: