Re: [RFT PATCH] Delay netroot mounting by 1 second

[Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>]

David Dillow wrote:
> On Mon, 2009-06-22 at 18:17 +0200, Seewer Philippe wrote:
>> David Dillow wrote:
>>> Certainly we don't want to sleep if there is no reason to... why slow
>>> down the boot if the network admin has the switch nicely configured for
>>> us?
>> What if he hasn't?
> 
> That's where this part comes in:
> 
>>> It may just be a matter of letting DHCP retry a sufficiency long time
>>> before we look at the results and try to boot. As long as we don't down
>>> the link after getting our information, the mount/login to the root
>>> device should proceed fairly quickly. If we do down the link, the
>>> blocking mode timer starts again and our very quick boot takes at least
>>> 40-60 seconds.
>> DHCP timeout already is 60 seconds. That's dhclient's default if you
>> don't provide other options.
> 
> Ok, then we just need to set the udev settle time to 60 seconds in the
> event of a netroot and avoid downing the link wherever possible. Given
> that timeout, the only problem cases are static configs and MTU changes
> on devices that cannot do that while UP'd.

I'd prefer not use an absolute settle time but instead "test/wait" the
queue. But that's a minor detail.

> 
>> The problem only manifests itself it we have to correct the mtu after dhcp,
>> which currently set's the interface down and up (paranoia I guess), or if
>> we do static configuration.
>>
>> For dhcp the solution could be easy: Either we ignore the mtu or don't 
>> down/up the interface to set it.
> 
> We shouldn't ignore the MTU, and we generally have to down/up the
> interface to set it. Certainly, we should try to set it without downing
> the interface, and fall back to the down/set/up sequence if that fails.
> That would avoid further delay when good hardware/drivers allows it.

Hmmm... I'm not sure that a failing 'ip set eth0 mtu xy' is an indicator
that we have to down/set mtu/up the interface. But to be honest, the 
hardware/driver combinations I'm able to test on seem to be working 
without down/up.

Are there any other methods to decide if we can set the mtu on the fly? 

> In the event of static config, or needing to down/up, I think it makes
> sense to try to ping the server for a period of time and see if we are
> able to communicate, before we try to get our root. You had even
> suggested something similar some time back with your original network
> scripts.
> 
> But that's not a 'sleep 60' just because we may happen be on a network
> with a long blocking state. Perhaps I misread what we're talking about
> and we're on the same page.

Actually, if I'm not mistaken STP can have a maximum timeout of 90
seconds. Add some paranoia and you're at 100. :-)

But yes, sleep 60 is a really bad idea for impatient people like you or me.

On the other hand, I'd really prefer other solutions to "ping" (if there
are any). Having used it myself doesn't mean I like it. First of all,
needing another utility enlarges the initrd even more, there's a possible
risk of having paranoid firewalls and we'd have to check the effective
service-port which isn't possible with standard iputils-ping.

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html