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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
