Bug#677504: lintian fixes

Michael Tokarev mjt at tls.msk.ru
Tue Jun 19 11:13:32 UTC 2012


16.06.2012 13:34, Sergey Kirpichev wrote:
> On Fri, Jun 15, 2012 at 12:47 AM, Michael Tokarev<mjt at tls.msk.ru>  wrote:
>> I'll try to review this stuff while being in a sea beach,
>> maybe will commit something.

Unfortunately I can't do anything from here at all. The wifi in the hotel
works, but they've everything filtered out except of outgioing tcp ports
80 and 443, and these have quite short expiration timeout too (about 30
sec).  So I can only browse the web, which is not how I can review anything
at all :(  I'm on a tinc vpn which I've set up to work over tcp port 443,
but it reconnects every 30 secs approx, and is very very slow - to d/load
the message I'm replying to (about 6Kb) it took about 20 reconnects, and
I've no idea how much will it take to send this message.

I looked at the patches, it all look quite well, but I can't commit anything
from here anyway.

> Would be nice, if you take look on #556610 too.

Yes, but this one is a feature/enhancement.  I'm not sure we ever want to
go this route -- the result smells too complicated.  Well, the sizes of the
typical arrays are increasing, and hence the time required to complete the
checks, so it becomes more and more important, so we have to do something
with that.

>> But to me, much more important issue is the timing issue we have
>> in initramfs. Â Namely, there are a few known valid setups which
>> does not work with mdadm currently. Â #675452 ... So, if you do have some
>> time and are willing to help, that's where to look at :)
>
> Comment was added.

Yes, I've seen these. But at this point before wheezy release I don't want
to enable asyncronous array processing like this.  Once we enable that in
in the initramfs, we have to enable it in regular userspace too, so that
other parts of arrays will be processed later.  This has to be supported
from initramfs to regular userspace and whole thing has to be switched to
asyncronous processing, which needs quite good testing in various usage
scenarios out there.

For now, the most appropriate course of actions, I think, is to run udevadm
settle before mdadm --assemble and, if after --assemble, the root device
is not there still, sleep a few seconds and repeat WHOLE series of scripts
in initramfs again, up to a configured amount of times.  This should already
work for cryptoloop which should not ask for a password again if the device
is already configured, and this should work for lvm on top of md raid too,
with lvm not being asyncronous like md is.

This is just an opinion anyway, maybe incremental/asyncronous mode isn't
that difficult. Except it does not solve non-incremental lvm anyway.

Thanks,

/mjt who hopes he'll be able to send this reply out somehow....





More information about the pkg-mdadm-devel mailing list