Btw, I filed a bug (bugs.os.o) for the ZFS FMRI scheme, and included a
suggested fix in the description. I don't have a CR number for it yet.
Its possible that this should go through the request-sponsor process.
Once I have the CR number I'll be happy to follow up with it. (It would
be nice if N
On Fri, 2010-06-18 at 09:07 -0400, Eric Schrock wrote:
> On Jun 18, 2010, at 4:56 AM, Robert Milkowski wrote:
>
> > On 18/06/2010 00:18, Garrett D'Amore wrote:
> >> On Thu, 2010-06-17 at 18:38 -0400, Eric Schrock wrote:
> >>
> >>> On the SS7000 series, you get an alert that the enclosure has be
On Jun 18, 2010, at 4:56 AM, Robert Milkowski wrote:
> On 18/06/2010 00:18, Garrett D'Amore wrote:
>> On Thu, 2010-06-17 at 18:38 -0400, Eric Schrock wrote:
>>
>>> On the SS7000 series, you get an alert that the enclosure has been detached
>>> from the system. The fru-monitor code (generaliz
On 18/06/2010 00:18, Garrett D'Amore wrote:
On Thu, 2010-06-17 at 18:38 -0400, Eric Schrock wrote:
On the SS7000 series, you get an alert that the enclosure has been detached
from the system. The fru-monitor code (generalization of the disk-monitor)
that generates this sysevent has not y
On Thu, 2010-06-17 at 18:38 -0400, Eric Schrock wrote:
> On Jun 17, 2010, at 6:13 PM, Garrett D'Amore wrote:
> >
> > So how do you diagnose the situation where someone trips over a cable,
> > or where the drive was bumped and detached from the cable? I guess I'm
> > OK with the idea that these ar
On Jun 17, 2010, at 6:13 PM, Garrett D'Amore wrote:
>
> So how do you diagnose the situation where someone trips over a cable,
> or where the drive was bumped and detached from the cable? I guess I'm
> OK with the idea that these are in a REMOVED state, but I'd like the
> messaging to say someth
On Thu, 2010-06-17 at 17:53 -0400, Eric Schrock wrote:
> On Jun 17, 2010, at 4:35 PM, Garrett D'Amore wrote:
> >
> > I actually started with DKIOCGSTATE as my first approach, modifying
> > sd.c. But I had problems because what I found is that nothing was
> > issuing this ioctl properly except for
On Jun 17, 2010, at 4:35 PM, Garrett D'Amore wrote:
>
> I actually started with DKIOCGSTATE as my first approach, modifying
> sd.c. But I had problems because what I found is that nothing was
> issuing this ioctl properly except for removable/hotpluggable media (and
> the SAS/SATA controllers/fr
On Thu, 2010-06-17 at 16:16 -0400, Eric Schrock wrote:
> On Jun 17, 2010, at 3:52 PM, Garrett D'Amore wrote:
> >
> > Anyway, I'm happy to share the code, and even go through the
> > request-sponsor process to push this upstream. I would like the
> > opinions of the ZFS and FMA teams though... is
On Jun 17, 2010, at 3:52 PM, Garrett D'Amore wrote:
>
> Anyway, I'm happy to share the code, and even go through the
> request-sponsor process to push this upstream. I would like the
> opinions of the ZFS and FMA teams though... is the approach I'm using
> sane, or have I missed some important d
So I've been working on solving a problem we noticed that when using
certain hot pluggable busses (think SAS/SATA hotplug here), that
removing a drive did not trigger any resulting response from either FMA
or ZFS *until* something tried to use that device. (This removal of a
drive can be thought o
11 matches
Mail list logo