upstart plans for F10+

Jeff Moyer jmoyer at redhat.com
Fri May 23 13:32:08 UTC 2008


Kostas Georgiou <k.georgiou at imperial.ac.uk> writes:

> On Thu, May 22, 2008 at 06:13:23PM -0400, Colin Walters wrote:
>
>> On Thu, May 22, 2008 at 4:44 PM, Bill Nottingham <notting at redhat.com> wrote:
>> >
>> > I mean, right now we have a static init script that runs once
>> > on boot to mount NFS, SMB, etc, and set up network block devices.
>> > It's also (in F9) kicked when NM brings up a new default route.
>> >
>> > What would be sane is to have it just mount things when it can
>> > reach the proper network, and lazily unmount them when that
>> > network goes away.
>> 
>> The issue with this is that at least last time I checked, at least
>> some file systems like NFS basically don't handle the network going
>> away from underneath them; if you have any userspace processes
>> accessing them they'll be wedged unrecoverably in D state.  I gave up
>> long ago on using kernel-based network filesystems on my laptop for
>> this reason.
>> 
>> Simo says CIFS handles this, so maybe other filesystems could be fixed.
>> 
>> But anyways, mounting after the network is available (triggered by NM)
>> makes sense probably.
>
> This is a bit dangerours...
>
> Have a look at /etc/init.d/netfs and tell me what will happen if you have
> an fs marked _netdev and the fsck fails if netfs doesn't run at init but
> under NM at some random point.
>
> In my opinion you only use netfs for filesystems that you want available
> at boot and n general you also want them to be always available, processes
> freezing until the network is available is not a problem but a feature.
> For everything else that isn't needed at boot there is always autofs.

Lots of deployments use autofs for file systems that are needed "at
boot."  Further, autofs will not react favorably if file systems are
unmounted out from under it.  I agree with the sentiment that, if the
network goes down, allow the file system to continue to retry until the
network is back online.

Cheers,

Jeff




More information about the fedora-devel-list mailing list