Yes, I get all that. But in backup/recovery scenarios where say you've lost 3 drives out of 12 in 4 arrays (this happened to us). You've got to figure out what physical drives have to be replaced and then put the correct mbr and partitions back on their replacements from backups even before you can even get to stamping them with the old array uuid and then the higher level tools that understand uuid and filesystem labels at the end of the food chain can do their thing. It's great to have these logical views of the devices but in hardware failure/recovery scenarios you need a solid physical view of things so that you minimize confusion during hardware recovery and the risk of further damage. Many times during recovery you have to replace hardware, boot into rescue, perform some work, shutdown, install more hardware or change something about hardware, boot back into rescue, ... And each time you boot back into rescue, guess what, your device letters are changing so throw away your notes from the last boot and start over. So having all the tools provide a means of working in a physical view for recoveries would be a great thing.On Mon, May 26, 2008 at 07:56:27PM -0400, Gerry Reno wrote:specific piece of hardware. But the tool output now is still using this type of device identification (sda) which in the future is actuallyNor did PATA except for the four "legacy" devices (hda-hdd) which have no meaning for modern devicesgenerate a backup state picture for physical SATA devices that encompasses mbr, partition tables, raid configuraton, lvm configuration, and filesystem mounting using mdadm, {pv|lv|vg}display, {f|sf}disk or parted. This was all very straightforward with PATA devices but is anything but with these SATA devices.SATA is hotplug, beyond "which is the boot volume" there isn't anything which ties a drive to a given port. LVM/MD and friends all understand uuid/label for good reason.