Customize the error emails of `mdadm --monitor`

Customize the error emails of `mdadm --monitor`

[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/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

Re: Customize the error emails of `mdadm --monitor`

[Peter Rabbitson]

Peter Rabbitson wrote:
> 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.
> 

Any takers? Or is it a RTFM question (in which case I certainly 
overlooked the relevant doc)?

Peter

Re: Customize the error emails of `mdadm --monitor`

[Iustin Pop]

On Wed, Jun 06, 2007 at 01:31:44PM +0200, Peter Rabbitson wrote:
> Peter Rabbitson wrote:
> >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.
> >
> 
> 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

Re: Customize the error emails of `mdadm --monitor`

[Peter Rabbitson]

Iustin Pop wrote:
> On Wed, Jun 06, 2007 at 01:31:44PM +0200, Peter Rabbitson wrote:
>> Peter Rabbitson wrote:
>>> 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.
>>>
>> 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

Re: Customize the error emails of `mdadm --monitor`

[Iustin Pop]

On Wed, Jun 06, 2007 at 02:23:31PM +0200, Peter Rabbitson wrote:
> Iustin Pop wrote:
> >On Wed, Jun 06, 2007 at 01:31:44PM +0200, Peter Rabbitson wrote:
> >>Peter Rabbitson wrote:
> >>>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.
> >>>
> >>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.

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

Re: Customize the error emails of `mdadm --monitor`

[Gabor Gombas]

On Wed, Jun 06, 2007 at 02:23:31PM +0200, Peter Rabbitson wrote:

> 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

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: Customize the error emails of `mdadm --monitor`

[Peter Rabbitson]

Gabor Gombas wrote:
> On Wed, Jun 06, 2007 at 02:23:31PM +0200, Peter Rabbitson wrote:
> 
>> 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
> 

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.

Re: Customize the error emails of `mdadm --monitor`

[Gabor Gombas]

On Wed, Jun 06, 2007 at 04:24:31PM +0200, Peter Rabbitson wrote:

> 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

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

Re: Customize the error emails of `mdadm --monitor`

[Peter Rabbitson]

Gabor Gombas wrote:
> On Wed, Jun 06, 2007 at 04:24:31PM +0200, Peter Rabbitson wrote:
> 
>> 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