Customize the error emails of `mdadm --monitor`
Hi,
Is there a way to list the _number_ in addition to the name of a problematic component? The kernel trend to move all block devices into the sdX namespace combined with the dynamic name allocation renders messages like "/dev/sdc1 has problems" meaningless. It would make remote server support so much easier, by allowing the administrator to label drive trays Component0 Component1 Component2... etc, and be sure that the local tech support person will not pull out the wrong drive from the system.
Thanks
Peter
Quoted 4 lines · Peter Rabbitson
Hi,
Is there a way to list the _number_ in addition to the name of a problematic component? The kernel trend to move all block devices into the sdX namespace combined with the dynamic name allocation renders messages like "
/dev/sdc1has problems" meaningless. It would make remote server support so much easier, by allowing the administrator to label drive trays Component0 Component1 Component2... etc, and be sure that the local tech support person will not pull out the wrong drive from the system.
Any takers? Or is it a RTFM question (in which case I certainly overlooked the relevant doc)?
Peter
Quoted 13 lines · Peter Rabbitson
Quoted 11 lines · Peter Rabbitson
Hi,
Is there a way to list the _number_ in addition to the name of a problematic component? The kernel trend to move all block devices into the sdX namespace combined with the dynamic name allocation renders messages like "
/dev/sdc1has problems" meaningless. It would make remote server support so much easier, by allowing the administrator to label drive trays Component0 Component1 Component2... etc, and be sure that the local tech support person will not pull out the wrong drive from the system.
Quoted 2 lines
Any takers? Or is it a RTFM question (in which case I certainly overlooked the relevant doc)?
If you use udev, have you looked in /dev/disk? I think it solves the problem you need by allowing one to see either the disks by id or by path. Making the reverse map is then trivial (for a reasonable number of disks).
regards,
iustin
Quoted 4 lines · Iustin Pop
Quoted 3 lines · Peter Rabbitson
Quoted 2 lines · Peter Rabbitson
Hi,
Quoted 9 lines
Quoted 3 lines
Quoted 2 lines
Is there a way to list the _number_ in addition to the name of a problematic component? The kernel trend to move all block devices into the sdX namespace combined with the dynamic name allocation renders messages like "
/dev/sdc1has problems" meaningless. It would make remote server support so much easier, by allowing the administrator to label drive trays Component0 Component1 Component2... etc, and be sure that the local tech support person will not pull out the wrong drive from the system.Any takers? Or is it a RTFM question (in which case I certainly overlooked the relevant doc)?
If you use udev, have you looked in
/dev/disk? I think it solves the problem you need by allowing one to see either the disks by id or by path. Making the reverse map is then trivial (for a reasonable number of disks).
This would not work as arrays are assembled by the kernel at boot time, at which point there is no udev or anything else for that matter other than /dev/sdX. And I am pretty sure my OS (debian) does not support udev in initrd as of yet.
Pete
Quoted 23 lines · Peter Rabbitson
Quoted 13 lines · Iustin Pop
Quoted 12 lines · Peter Rabbitson
Quoted 11 lines · Peter Rabbitson
Hi,
Is there a way to list the _number_ in addition to the name of a problematic component? The kernel trend to move all block devices into the sdX namespace combined with the dynamic name allocation renders messages like "
/dev/sdc1has problems" meaningless. It would make remote server support so much easier, by allowing the administrator to label drive trays Component0 Component1 Component2... etc, and be sure that the local tech support person will not pull out the wrong drive from the system.Quoted 8 lines
Quoted 2 lines
Any takers? Or is it a RTFM question (in which case I certainly overlooked the relevant doc)?
If you use udev, have you looked in
/dev/disk? I think it solves the problem you need by allowing one to see either the disks by id or by path. Making the reverse map is then trivial (for a reasonable number of disks).
Quoted 4 lines
This would not work as arrays are assembled by the kernel at boot time, at which point there is no udev or anything else for that matter other than
/dev/sdX. And I am pretty sure my OS (debian) does not support udev in initrd as of yet.
Ah, I see. But then, sysfs should help (I presume sysfs being a standard kernel filesystem can be mounted in the initrd). I think that most of the information the kernel has for the device is present in sysfs. At least a crude form of path mapping to the real controller is available via the symlink /sys/block/sdN/device. I don't know if it really helps your case.
iustin
Quoted 4 lines · Peter Rabbitson
This would not work as arrays are assembled by the kernel at boot time, at which point there is no udev or anything else for that matter other than
/dev/sdX. And I am pretty sure my OS (debian) does not support udev in initrd as of yet.
But I think sending mails from the initrd isn't supported either, so if you already hack the initrd, you can get the path information from sysfs. udev is nothing magical, it just walks the sysfs tree and calls some little helper programs when collecting the information for building /dev/disk; you can do that yourself if you want.
Gabor
Signature · 4 lines
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------Quoted 4 lines · Gabor Gombas
Quoted 1 line · Peter Rabbitson
This would not work as arrays are assembled by the kernel at boot time, at which point there is no udev or anything else for that matter other than
/dev/sdX. And I am pretty sure my OS (debian) does not support udev in initrd as of yet.
Quoted 8 lines
But I think sending mails from the initrd isn't supported either, so if you already hack the initrd, you can get the path information from sysfs. udev is nothing magical, it just walks the sysfs tree and calls some little helper programs when collecting the information for building
/dev/disk; you can do that yourself if you want.Gabor
I think I did not make my problem clear enough. The _device name_ reported in the emails is the one with which the array was initially assembled. For this I have two choices:
* Kernel auto-assembly - the parts are properly detected and assembled, but there is no strong relationship between component number and sdX, especially if asynchronous scsi scanning takes place.
* Assembly by mdadm.conf - I can put whatever block devices I want in there, and they will be preserved in the email, but it is very cumbersome to do it for root and other system partitions.
So I was asking if the component _number_, which is unique to a specific device regardless of the assembly mechanism, can be reported in case of a failure.
Quoted 3 lines · Peter Rabbitson
So I was asking if the component _number_, which is unique to a specific device regardless of the assembly mechanism, can be reported in case of a failure.
So you need to write an event-handling script and pass it to mdadm (--program). In the script you can walk sysfs and/or call the appropriate helper programs to extract all the information you need and format it in the way you want. For example, if you want the slot number of a failed disk, you can get it from /sys/block/$2/md/dev-$3/slot (according to the manpage, not tested).
Gabor
Signature · 4 lines
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------Quoted 11 lines · Gabor Gombas
Quoted 1 line · Peter Rabbitson
So I was asking if the component _number_, which is unique to a specific device regardless of the assembly mechanism, can be reported in case of a failure.
So you need to write an event-handling script and pass it to mdadm (--program). In the script you can walk sysfs and/or call the appropriate helper programs to extract all the information you need and format it in the way you want. For example, if you want the slot number of a failed disk, you can get it from
/sys/block/$2/md/dev-$3/slot(according to the manpage, not tested).
Now that's some real advice. I have not thought of that. Thank you!
Peter