mdadm/Monitor.c - never removes MD devices from statelist
mdadm/Monitor.c - never removes MD devices from statelist
am 11.09.2011 20:32:12 von Alexander Lyakas
Hi everybody,
looking at the code of Monitor.c and doing some tests with it, I see
that it is capable of detecting new arrays, when they appear in
/proc/mdstat (if --scan is given). However, once array is added to
'statelist', it is never removed from there. Is this intentional?
Perhaps only if --scan is given, and device disappears from
/proc/mdstat, then it should be removed from monitoring, otherwise it
could stick there forever, even though the array has been gone long
time ago. And if it appears again, it will be picked up anyways.
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mdadm/Monitor.c - never removes MD devices from statelist
am 12.09.2011 05:36:46 von NeilBrown
On Sun, 11 Sep 2011 21:32:12 +0300 Alexander Lyakas
wrote:
> Hi everybody,
> looking at the code of Monitor.c and doing some tests with it, I see
> that it is capable of detecting new arrays, when they appear in
> /proc/mdstat (if --scan is given). However, once array is added to
> 'statelist', it is never removed from there. Is this intentional?
> Perhaps only if --scan is given, and device disappears from
> /proc/mdstat, then it should be removed from monitoring, otherwise it
> could stick there forever, even though the array has been gone long
> time ago. And if it appears again, it will be picked up anyways.
>
You are right - arrays are never removed.
Is that a problem? Probably not, though I guess you could probably create
a scenario where there were lots of inactive devices cluttering memory.
Is it worth fixing? I don't know - it depends on how intrusive the patch is.
We would only want to remove arrays with ->err set if 'scan' was set, but
when it is, it possible makes sense.
Want to try creating a patch?
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mdadm/Monitor.c - never removes MD devices from statelist
am 12.09.2011 10:32:23 von Alexander Lyakas
Hello Neil,
yes, I will try to produce a patch (although I am using git, I have
never done patches yet).
But I don't understand why do you require 'err' to be set. I would say
that when there is a "DeviceDisappeared" event plus --scan is set,
then you should remove. (And also perhaps if this array does not
appear in the device list provided by the user).
Alex.
On Mon, Sep 12, 2011 at 6:36 AM, NeilBrown wrote:
> On Sun, 11 Sep 2011 21:32:12 +0300 Alexander Lyakas
il.com>
> wrote:
>
>> Hi everybody,
>> looking at the code of Monitor.c and doing some tests with it, I see
>> that it is capable of detecting new arrays, when they appear in
>> /proc/mdstat (if --scan is given). However, once array is added to
>> 'statelist', it is never removed from there. Is this intentional?
>> Perhaps only if --scan is given, and device disappears from
>> /proc/mdstat, then it should be removed from monitoring, otherwise i=
t
>> could stick there forever, even though the array has been gone long
>> time ago. And if it appears again, it will be picked up anyways.
>>
>
> You are right - arrays are never removed.
>
> Is that a problem? =A0Probably not, though I guess you could probably=
create
> a scenario where there were lots of inactive devices cluttering memor=
y.
>
> Is it worth fixing? =A0I don't know - it depends on how intrusive the=
patch is.
> We would only want to remove arrays with ->err set if 'scan' was set,=
but
> when it is, it possible makes sense.
>
> Want to try creating a patch?
>
> NeilBrown
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mdadm/Monitor.c - never removes MD devices from statelist
am 21.09.2011 07:06:13 von NeilBrown
--Sig_/YPkB83MBwKqp2SoF_A4I9wC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Mon, 12 Sep 2011 11:32:23 +0300 Alexander Lyakas
wrote:
> Hello Neil,
> yes, I will try to produce a patch (although I am using git, I have
> never done patches yet).
If you are using git, then patches are easy:
git show --format=3Demail
>=20
> But I don't understand why do you require 'err' to be set. I would say
> that when there is a "DeviceDisappeared" event plus --scan is set,
> then you should remove. (And also perhaps if this array does not
> appear in the device list provided by the user).
A DeviceDisappeared event sets ->err to 1. So testing ->err is an easy way
to test if the device disappeated.
It doesn't matter if the device was listed by the user: if --scan is set we
will find it again anyway.
NeilBrown
>=20
> Alex.
>=20
>=20
> On Mon, Sep 12, 2011 at 6:36 AM, NeilBrown wrote:
> > On Sun, 11 Sep 2011 21:32:12 +0300 Alexander Lyakas
..com>
> > wrote:
> >
> >> Hi everybody,
> >> looking at the code of Monitor.c and doing some tests with it, I see
> >> that it is capable of detecting new arrays, when they appear in
> >> /proc/mdstat (if --scan is given). However, once array is added to
> >> 'statelist', it is never removed from there. Is this intentional?
> >> Perhaps only if --scan is given, and device disappears from
> >> /proc/mdstat, then it should be removed from monitoring, otherwise it
> >> could stick there forever, even though the array has been gone long
> >> time ago. And if it appears again, it will be picked up anyways.
> >>
> >
> > You are right - arrays are never removed.
> >
> > Is that a problem? =A0Probably not, though I guess you could probably c=
reate
> > a scenario where there were lots of inactive devices cluttering memory.
> >
> > Is it worth fixing? =A0I don't know - it depends on how intrusive the p=
atch is.
> > We would only want to remove arrays with ->err set if 'scan' was set, b=
ut
> > when it is, it possible makes sense.
> >
> > Want to try creating a patch?
> >
> > NeilBrown
> >
--Sig_/YPkB83MBwKqp2SoF_A4I9wC
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iD8DBQFOeXDFG5fc6gV+Wb0RAplkAJ47YN4g+CbSLIlDriDjf/ZZUSg1uQCg wi5T
SvtHwoYcUQSoMszH7/ACvQo=
=zALK
-----END PGP SIGNATURE-----
--Sig_/YPkB83MBwKqp2SoF_A4I9wC--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html