On 04/27/2012 07:33 PM, Tollef Fog Heen wrote: > ]] Martin Wuertele > >> * Josselin Mouette <j...@debian.org> [2012-04-27 09:53]: >> >>> Le jeudi 26 avril 2012 à 22:29 +0200, Svante Signell a écrit : >>>>> Yes of course, because event-driven init systems have *always* been >>>>> *only* about mounting USB devices. >>>> >>>> Then explain the _real_ reasons for having an event driven boot system! >>> >>> BECAUSE THE LINUX KERNEL IS EVENT DRIVEN. >> >> That's a reason for udev/mdev, however I still fail to see why this >> results in the requirement for an event based boot process. > > A trivial example is $remote_fs isn't satisfied until /srv/somewhere is > mounted and /srv/somewhere comes off iscsi, which means it requires > networking to be up, which means network drivers loaded, etc. So the > event «network driver loaded» causes ifup to be spawned, which causes > $network to be satisfied which causes the iscsi daemons to be started > which causes mount to be called.
You actually want to start your iscsi stuff even your network is not available right now - and you for sure don't want to stop it just because the link flaps. iscsi is able to handle that just fine. You could even add multipath on top of iscsi to make it even more reliable. And for all that there is no need to have an init system which understands events. If you want to do something after your devices appear, use udev. As traffic yo your iscsi disk will be queued in case the connection gets lost there is also no need to find something new to handle link up/down events. If your link is gone forever there is a broken filesystem and some stuck IO fun anyway. You have to find something better to convince people. -- Bernd Zeimetz Debian GNU/Linux Developer http://bzed.de http://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f9d3909.2090...@bzed.de