David Zeuthen wrote:
How about giving a hint as to which _physical_ disk it is? Imagine you
had a couple of scsi controllers each with a bunch of disks, plus some
sata and USB volumes and you add one (which might currently have labels
that match other drives) and want to format it. Which one is it? Or a
drive in the system fails and isn't detected. How do you find which one
it was?
You mean like showing "/ (/dev/sdb1)" instead of "/"? It's doable..
No - sdb1 tells me what order the OS detected it it. It says nothing
about the physical connection or even which controller is involved.
Does anyone actually use this system with a large number of disks that
sometimes need attention? If the drive that was sdb yesterday fails in
a way that keeps it from being detected, sdb will mean something else
after a reboot.
Might make sense in some cases. FWIW, I'm (or alexl) is going to revisit
most of this before F9 as part of the gio/gvfs hacking. Stay tuned!
How do you change the UUID's on md arrays? I often clone machines by
separating RAID1 drives and letting them sync to new partners. If those
separated drives ever find themselves back in the same machine, I
wouldn't want them to rebuild automatically.
I'm failing to see why this question relevant to this discussion?
Same general rant about not being able to tell/control what is really
going on. I don't like the system to guess, especially when I know the
answer will likely be wrong.
I'm simply just asking the Anaconda to a) use UUID instead of LABEL (if
applicable; e.g. some FS's don't have UUID); and b) use some sane labels
by default. The user is still free to edit /etc/fstab to use LABEL=
instead of UUID= and/or relabel his drives or do whatever he wants.
And similarly, I'd like a way to peg these to physical
controller/cable/drive selects because the UUIDs and labels are all
going to be the same on disks that I've cloned with DD or letting
RAID1's rebuild. I know you can't on USB, but about everything else has
a controller/target/LUN concept to identify it.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
