Kostas Georgiou <k.georgiou@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
