Bug#556610: Please do incremental checks every night instead of a full monthly one

[NeilBrown]

On Wed, 25 Dec 2013 19:13:27 +0400 Sergey B Kirpichev <skirpichev at gmail.com>
wrote:

> > The main issue which all proposed solutions share is when
> > there's a large array, say, md0, and a small array, say,
> > md1, both shares the same set of underlying disks, so md
> > subystem will not check/repair them in parallel.  In this
> > situation, we will never check md1 if checking md0 takes
> > more time than we allow in a month (28 days).
> 
> What do you think about suggested above solution
> (set sync_force_parallel to 1 during cronjobs)?  This workaround
> is implemented in the updated (attached) patch.
> 
> See also: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=556610#74
> 
> BTW, how bad is in general to set
> sync_force_parallel to 1 per default?  (Cc'd to Neil Brown.)

It is very unlikely to have a positive effect.
If it has any effect, it will significantly slow down any check/repair etc
that is happening.

> 
> I think, it would be nice to end (not pause) check if it's reached
> sync_max.  Perhaps, there is deep reasons why md's interface
> doesn't work in this way.  Neil, could you explan this a bit?

There might be a reason to continue the resync.
If you want to "end" the resync, then have some program wait for
sync_completed to reach sync_max, then write 'idle' to 'sync_action'.

If you (or someone here) want to write a general "incremental check" script
then I think that is a great idea, but rather than treating it as a "Debian"
thing, post the proposal to linux-raid at vger.kernel.org and get feedback and
suggestions there and when it is ready we can include it in the upstream
mdadm package.

NeilBrown


> 
> > I'll think about it all more.
> 
> Any news?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-mdadm-devel/attachments/20140106/f4544cee/attachment.sig>