We have a new machine which has SATA. This is the first machine we have had with SATA. SATA and these changing device locations are giving me a headache. None of our disk device tools work with SATA. For instance we have a tool that will save all the MBR's and partition tables off to files such as 'hda.mbr' and 'hda.part'. With SATA this does not work because what was 'sda' during this boot may be 'sdc' on the next boot. So I need to find out if there is some best practice guide for how to rewrite our tools so that they can support SATA. We use LVM over RAID on all our drives and all our RAID and LVM tools appear to still work. It is only when dealing with the low-level disk devices themselves that we have problems. Can someone give me some suggestions as to how to manage things when using SATA?
Regards, Gerry
On Fri, 2008-05-23 at 13:41 -0400, Gerry Reno wrote:
We have a new machine which has SATA. This is the first machine we have had with SATA. SATA and these changing device locations are giving me a headache. None of our disk device tools work with SATA. For instance we have a tool that will save all the MBR's and partition tables off to files such as 'hda.mbr' and 'hda.part'. With SATA this does not work because what was 'sda' during this boot may be 'sdc' on the next boot. So I need to find out if there is some best practice guide for how to rewrite our tools so that they can support SATA. We use LVM over RAID on all our drives and all our RAID and LVM tools appear to still work. It is only when dealing with the low-level disk devices themselves that we have problems. Can someone give me some suggestions as to how to manage things when using SATA?
Regards, Gerry
Use disk UUIDs instead of device names.
On Fri, May 23, 2008 at 01:41:32PM -0400, Gerry Reno wrote:
We have a new machine which has SATA. This is the first machine we have had with SATA. SATA and these changing device locations are giving me a headache. None of our disk device tools work with SATA. For instance we have a tool that will save all the MBR's and partition tables off to files such as 'hda.mbr' and 'hda.part'. With SATA this does not work because what was 'sda' during this boot may be 'sdc' on the next boot. So I need to find out if there is some best practice guide for how to rewrite our tools so that they can support SATA. We use LVM over RAID on all our drives and all our RAID and LVM tools appear to still work. It is only when dealing with the low-level disk devices themselves that we have problems. Can someone give me some suggestions as to how to manage things when using SATA?
If you want stable device names, don't use /dev/sd* at all.
This is what /dev/disk/by-{id,label,path,uuid}/* are for
Dan.
On Fri, May 23, 2008 at 01:41:32PM -0400, Gerry Reno wrote:
So I need to find out if there is some best practice guide for how to rewrite our tools so that they can support SATA. We use LVM over RAID on all our drives and all our RAID and LVM tools appear to still work. It is only when dealing with the low-level disk devices themselves that we have problems. Can someone give me some suggestions as to how to manage things when using SATA?
You want to look at the volume itself. SATA is hotplug so talking about devices by their bus location is a bit meaningless.
You've got two useful identifiers
1. The serial number of the drive available directly either by using SG_IO to issue an IDENTIFY or the boot one (which is fine) via ioctls too. Or you can script parsing hdparm of course.
2. Labels on the file systems which is what RAID/LVM/etc all use.
For low level work where you want to know "this physical disk is the one I saw last week" the disk vendor|model|serial combination should be unique for any modern real world drive.
Alan Cox wrote:
On Fri, May 23, 2008 at 01:41:32PM -0400, Gerry Reno wrote:
So I need to find out if there is some best practice guide for how to rewrite our tools so that they can support SATA. We use LVM over RAID on all our drives and all our RAID and LVM tools appear to still work. It is only when dealing with the low-level disk devices themselves that we have problems. Can someone give me some suggestions as to how to manage things when using SATA?
You want to look at the volume itself. SATA is hotplug so talking about devices by their bus location is a bit meaningless.
You've got two useful identifiers
- The serial number of the drive available directly either by using
SG_IO to issue an IDENTIFY or the boot one (which is fine) via ioctls too. Or you can script parsing hdparm of course.
- Labels on the file systems which is what RAID/LVM/etc all use.
For low level work where you want to know "this physical disk is the one I saw last week" the disk vendor|model|serial combination should be unique for any modern real world drive.
The serial number might be ok until you replace the disk. Just have to remember to rerun the tools for the replacement and to note the replacement lineage. In scripts I think I could parse smartctl output for serial numbers or is there something better under /proc I can parse?
On Fri, May 23, 2008 at 04:24:01PM -0400, Gerry Reno wrote:
The serial number might be ok until you replace the disk. Just have to remember to rerun the tools for the replacement and to note the replacement lineage. In scripts I think I could parse smartctl output for serial numbers or is there something better under /proc I can parse?
hdparm is probably better to parse than hdparm. Especially
hdparm --Istdout
Alan Cox wrote:
On Fri, May 23, 2008 at 04:24:01PM -0400, Gerry Reno wrote:
The serial number might be ok until you replace the disk. Just have to remember to rerun the tools for the replacement and to note the replacement lineage. In scripts I think I could parse smartctl output for serial numbers or is there something better under /proc I can parse?
hdparm is probably better to parse than hdparm. Especially
hdparm --Istdout
Ok, I was trying to steer clear of hdparm if I could because I got bit a couple times with that command. But in this instance in a script it should be ok.
Just following up on this theme with respect to GRUB. When Anaconda installed GRUB it put entries into /boot/grub/device.map. But in grub> when I do a 'find /boot/grub/stage1' the list of devices containing the boot files is altogether different from what is in device.map. So my question is this: On systems with SATA, is device.map no longer used? Since it seems under GRUB that the devices where GRUB finds the boot files keep changing between boots is device.map even usable?
Gerry Reno wrote:
Just following up on this theme with respect to GRUB. When Anaconda installed GRUB it put entries into /boot/grub/device.map. But in grub> when I do a 'find /boot/grub/stage1' the list of devices containing the boot files is altogether different from what is in device.map. So my question is this: On systems with SATA, is device.map no longer used? Since it seems under GRUB that the devices where GRUB finds the boot files keep changing between boots is device.map even usable?
Also, with respect to modifying our low-level device management/backup tools to support SATA. This is turning out to be somewhat more difficult than just using hdparm. We rely on the output of mdadm, the lvm display commands, /etc/fstab and others to build a picture of the current state. The problem is that with SATA none of these tools is producing an output that maps the devices to a particular known location where you could find a particular piece of hardware. Prior to SATA for the most part people were using PATA devices and hda was always a specific piece of hardware. But the tool output now is still using this type of device identification (sda) which in the future is actually meaningless and therefore is quite useless for building a picture of the current state that could be used later to recover the state in the event of some disaster. I am looking for some suggestions as to how to generate 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.
Regards, Gerry
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 actually
Nor did PATA except for the four "legacy" devices (hda-hdd) which have no meaning for modern devices
generate 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.
On Tue, 27 May 2008, Alan Cox wrote:
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.
Does cryptsetup? That's the one thing I've noticed still uses /dev/sda or /dev/hda style device names
later, chris
Alan Cox wrote:
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 actually
Nor did PATA except for the four "legacy" devices (hda-hdd) which have no meaning for modern devices
generate 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.
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.
Regards, Gerry
Gerry Reno wrote:
The serial number might be ok until you replace the disk. Just have to remember to rerun the tools for the replacement and to note the replacement lineage. In scripts I think I could parse smartctl output for serial numbers or is there something better under /proc I can parse?
sg_inq /dev/sda
Denis Leroy wrote:
Gerry Reno wrote:
The serial number might be ok until you replace the disk. Just have to remember to rerun the tools for the replacement and to note the replacement lineage. In scripts I think I could parse smartctl output for serial numbers or is there something better under /proc I can parse?
sg_inq /dev/sda
Thanks. Here is the output I get from sg_inq:
# sg_inq /dev/sda standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 BQue=0 EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=0 [SPI: Clocking=0x0 QAS=0 IUS=0] length=96 (0x60) Peripheral device type: disk Vendor identification: ATA Product identification: Hitachi HDP72502 Product revision level: GM2O Unit serial number: GEK231RB045L2A
How new is this? Not sure the Vendor ID looks exactly right though.
-
Alan Cox -
Chris Ricker -
Daniel P. Berrange -
Denis Leroy -
Gerry Reno -
Jesse Keating