12:41 p.m.
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
1:30 p.m.
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.
--
Jesse Keating
Fedora -- Freedom² is a feature!
1:34 p.m.
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.
--
|: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
3 p.m.
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.
3:24 p.m.
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
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.
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?
3:34 p.m.
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
3:45 p.m.
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.
5:30 p.m.
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?
6:56 p.m.
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
3:22 a.m.
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.
8:27 a.m.
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
9:55 p.m.
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
6:25 p.m.
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
7:39 p.m.
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.
5873
days inactive
5878
days old
13 comments
6 participants
participants (6)
-
Alan Cox -
Chris Ricker -
Daniel P. Berrange -
Denis Leroy -
Gerry Reno -
Jesse Keating