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

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

Hannes Reinecke wrote:
> David Dillow wrote:
>> On Fri, 2009-06-19 at 11:08 -0500, Victor Lowther wrote:
>>> Or you can include ethtool and check every half second until a timeout  
>>> to see if the link is back.
>> With most switches, you'll get a link back almost immediately, but it
>> will be in blocking mode and won't transmit your packets for 20-30
>> seconds.
> 
> <And a huge grin spreads over my face>
> Finally. I'm not alone anymore:-)
> (I have been fighting the STP issue for years now.)

You can say that loud. Over the years I've tried various solutions,
from sleeping, to catching states via netlink, to guessing STP
timeouts (on newer switches probability of RSTP-like behaviour is
95%) to your mentioned ping... 

> No, no, no. You don't want to add 'just' a sleep here because things
> don't work as expected. Certainly not in this case.

Sleep isn't a good solution, I agree there. But it's simple.
Hence the RFT to see if someone can construct a real life case
where it actually isn't enough.

> The problem here is that most programs don't / can't distinguish
> between an EHOSTUNREACH during startup (where we should retry as
> the link / connection might not be up yet) and an EHOSTUNREACH
> during normal operation (where we should return the error as this
> is a genuine error condition).
> 
> The only safe way here is to send a ping to the host port we're
> trying to connect to, and limit this with a timeout.
> And start up the command once the ping succeeds.
> Otherwise timeout and start error recovery.

Yes. If we know that 1) We're using the correct interface and
2) provided server data is correct. Otherwise we just unnecessary
lengthen to boot process.

--
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