experimenting with dmraid - disk status

Sandra Escandor sescandor at evertz.com
Fri Jun 10 13:11:17 UTC 2011


Hello Heinz,

Thanks for your reply. I took a bit of a break from this experiment, but
now I'm back. The output of "dm_dso_reg_tool -m" shows that the devices
have indeed been registered. But the metadata is not changed when one of
the disks becomes "disabled" (according to dmsetup status). The metadata
on the disks should reflect this with some sort of change in the
metadata, right? Or am I wrong?

Regards,
Sandra

-----Original Message-----
From: ataraid-list-bounces at redhat.com
[mailto:ataraid-list-bounces at redhat.com] On Behalf Of Heinz Mauelshagen
Sent: Friday, May 13, 2011 11:35 AM
To: ATARAID (eg, Promise Fasttrak, Highpoint 370) related discussions
Subject: RE: experimenting with dmraid - disk status


Hi Sandra,

your case described looks like the dmraid dmeventd isw plugin is not
installed and if it is, the devies aren't being registered for event
monitoring properly. Check with "dm_dso_reg_tool -m" if the devices got
registered properly which I assume is not the case.

Regards,
Heinz

On Fri, 2011-05-13 at 09:00 -0400, Sandra Escandor wrote:
> I'm not sure if my question was sent properly last time, so I'm
> resending :) Is it true that if in the middle of a RAID i/o, one of
the
> disks fail, dmevent doesn't actually change the metadata at all? My
> experiment procedure is listed below. Perhaps I did something wrong?
> 
> Thanks for clarifying,
> Sandra
> 
> -----Original Message-----
> From: Sandra Escandor 
> Sent: Tuesday, May 03, 2011 1:46 PM
> To: 'ATARAID (eg, Promise Fasttrak,Highpoint 370) related discussions'
> Subject: RE: experimenting with dmraid - disk status
> 
> Ok, I've set it up so that I transfer a large file onto the RAID, and
> then during the transfer, I pull out a member disk to simulate a disk
> failure. I would like to confirm if I should be seeing what I'm
seeing:
> 
> -The output of "dmraid -n" shows disk[0].status: 0x53a for all of the
> disks, even the one pulled out. I expected dmeventd to change one of
> them, since I'm doing I/O as you had mentioned. Is what I was
expecting
> incorrect?
> -The output of "dmraid -n" shows
isw_dev[0].vol.map[0].failed_disk_num:
> 255. I expected this to be the number of the disk that I have removed.
> Is what I am expecting for this field incorrect?
> 
> I do see that dmsetup and dm_dso_reg_tool give the proper output (as
> mentioned in the document "How to Guide: DMRAID Eventing - What To
> Expect"), so that's good. So, does this mean that dmeventd doesn't
> modify the metadata at all as what I had expected above?
> 
> Thanks,
> Sandra
> 
> -----Original Message-----
> From: ataraid-list-bounces at redhat.com
> [mailto:ataraid-list-bounces at redhat.com] On Behalf Of Heinz
Mauelshagen
> Sent: Tuesday, May 03, 2011 8:46 AM
> To: ATARAID (eg, Promise Fasttrak, Highpoint 370) related discussions
> Subject: RE: experimenting with dmraid - disk status
> 
> On Tue, 2011-05-03 at 07:58 -0400, Sandra Escandor wrote:
> > So, if I understood what you have said correctly, then the following
> > would be true:
> > 
> > - When there is no I/O being performed on the RAID, and then one of
> the
> > member disks becomes disconnected for some reason, then a dmeventd
> event
> > would not be generated.
> 
> Correct.
> 
> > - After a while, I/O does get performed on the RAID (with a member
> disk
> > disconnected), then that will be the time that a dmeventd event gets
> > generated.
> 
> Correct.
> 
> Any generated events are being based on io, not on _any_ other events
> such as unplugging a drive.
> 
> Heinz
> 
> > 
> > Is that right?
> > 
> > -----Original Message-----
> > From: ataraid-list-bounces at redhat.com
> > [mailto:ataraid-list-bounces at redhat.com] On Behalf Of Heinz
> Mauelshagen
> > Sent: Monday, May 02, 2011 4:53 PM
> > To: ATARAID (eg, Promise Fasttrak, Highpoint 370) related
discussions
> > Subject: RE: experimenting with dmraid - disk status
> > 
> > On Mon, 2011-05-02 at 15:19 -0400, Sandra Escandor wrote:
> > > After I installed the dmeventd package, I notice the following:
> > > (general setup: ICH10R controller, raid0+1, 4 member disks)
> > > - When I pull out a drive, then run dm_dso_reg_tool -m, the
section
> > > "Error Events Recorded by Kernel" for the superset and two subsets
> are
> > > still 0. Is this expected?
> > 
> > Unless you performed io on the set.
> > 
> > > - (Drive still physically disconnected) when I run dmraid -n, the
> > > metadata shows that the status of the disk that I pulled out still
> has
> > > the same status as the other disks which are plugged in (i.e
> > > disk[0].status: 0x53a is shown for all of the disks, even the one
> that
> > > I pulled out).
> > 
> > Same as above.
> > 
> > Heinz
> > 
> > > 
> > > The steps that I took to set up the device mapper raid event
> > monitoring
> > > are basically the same as the one found in: "How to Setup Device
> > Mapper
> > > Raid event Monitoring_0.74.pdf"
> > > (http://sources.redhat.com/lvm2/wiki/DMRAID_Eventing)
> > > EXCEPT: 
> > > * I obtained the dmeventd package from the Ubuntu repository
> > (Maverick)
> > > * I didn't install the patch (since I'm using kernel 2.6.35)
> > > * I changed the makefile of libdmraid-events so that it would link
> > with
> > > the pthread library (i.e added -lpthread to the makefile).
> > > 
> > > Is there another package that I need to install, or have I not set
> > this
> > > up properly?
> > > 
> > > Thanks for the clarifications,
> > > Sandra
> > > 
> > > -----Original Message-----
> > > From: Heinz Mauelshagen [mailto:heinzm at redhat.com] 
> > > Sent: Friday, April 29, 2011 10:14 AM
> > > To: Sandra Escandor
> > > Subject: RE: experimenting with dmraid - disk status
> > > 
> > > On Fri, 2011-04-29 at 08:00 -0400, Sandra Escandor wrote:
> > > > I forgot to mention my metadata type. Yes, I'm using Intel
> software
> > > raid
> > > > (so it's in isw format). Where would I be able to get this
plugin?
> > > 
> > > You should get them with any distros dmraid-events package.
> > > 
> > > Heinz
> > > 
> > > > 
> > > > Thanks,
> > > > Sandra
> > > > 
> > > > -----Original Message-----
> > > > From: ataraid-list-bounces at redhat.com
> > > > [mailto:ataraid-list-bounces at redhat.com] On Behalf Of Heinz
> > > Mauelshagen
> > > > Sent: Friday, April 29, 2011 3:58 AM
> > > > To: ataraid-list at redhat.com
> > > > Subject: Re: experimenting with dmraid - disk status
> > > > 
> > > > On Thu, 2011-04-28 at 09:30 -0400, Sandra Escandor wrote:
> > > > > Hello,
> > > > > 
> > > > >  
> > > > > 
> > > > > I was doing a bit of experimenting with dmraid. What I have
done
> > is
> > > to
> > > > > create a raid0+1 array, and then physically pull one of the
> disks
> > > out.
> > > > > I then use the command "dmraid -n" to look at the metadata on
> the
> > > > > member disks. I notice that the member disk listed by the
output
> > > that
> > > > > has the specific serial number of the disk that I pulled,
whose
> > > status
> > > > > I expect to be different from the other disks listed, still
has
> > the
> > > > > same status as the other still physically plugged in. (i.e
> > > > > disk[0].status: 0x53a is shown for all of the disks, even the
> one
> > > that
> > > > > I pulled out). Is this normal?
> > > > 
> > > > Yes, unless it's isw format, where a plugin exists to update the
> > > > metadata.
> > > > 
> > > > Heinz
> > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > The following is the output of "dmraid -V":
> > > > > 
> > > > > dmraid version: 1.0.0.rc16 (2009.09.16) shared
> > > > > 
> > > > > dmraid library version:  1.0.0.rc16 (2009.09.16) 
> > > > > 
> > > > > device-mapper version: 4.13.0
> > > > > 
> > > > >  
> > > > > 
> > > > > Thanks for clarifying,
> > > > > 
> > > > > Sandra 
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > Ataraid-list mailing list
> > > > > Ataraid-list at redhat.com
> > > > > https://www.redhat.com/mailman/listinfo/ataraid-list
> > > > 
> > > > 
> > > > _______________________________________________
> > > > Ataraid-list mailing list
> > > > Ataraid-list at redhat.com
> > > > https://www.redhat.com/mailman/listinfo/ataraid-list
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > Ataraid-list mailing list
> > > Ataraid-list at redhat.com
> > > https://www.redhat.com/mailman/listinfo/ataraid-list
> > 
> > 
> > _______________________________________________
> > Ataraid-list mailing list
> > Ataraid-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/ataraid-list
> > 
> > _______________________________________________
> > Ataraid-list mailing list
> > Ataraid-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/ataraid-list
> 
> 
> _______________________________________________
> Ataraid-list mailing list
> Ataraid-list at redhat.com
> https://www.redhat.com/mailman/listinfo/ataraid-list
> 
> _______________________________________________
> Ataraid-list mailing list
> Ataraid-list at redhat.com
> https://www.redhat.com/mailman/listinfo/ataraid-list


_______________________________________________
Ataraid-list mailing list
Ataraid-list at redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list




More information about the Ataraid-list mailing list