Date: Mon, 1 Jun 1998 17:35:49 -0400 (EDT) From: Mikhail Teterin <mi@video-collage.com> To: current@FreeBSD.ORG Subject: Re: NFS discovery Message-ID: <199806012135.RAA21867@xxx.video-collage.com> In-Reply-To: <35730F59.510D55FB@tdx.co.uk> from Karl Pielorz at "Jun 1, 98 09:30:17 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Karl Pielorz once stated: => NFS hung ups are a strange topic, in my experience. People agree that => they are "bad", but one is not supposed to complain about them... =I remember having a long conversation with a friend a few years back =(can I get any more vague?) - Where he was praising NFS's ability to =crash - as it assures that say your running a program on a remote =system, it will either run to completion - or hang if the server =dies... This I presume works on the assumption that it helps somehow =to have a client that's 'hung' in mid-air (i.e. at least you know if =failed) rather than risking any corruption that might have been caused =by the server disappearing for a while... This is true. However, there must be a thing right before having to reboot the whole system. I must be able to avoid the total reboot of the client (in which case my in-mid-air app will loose its data anyway) and getting rid of the hung mountpoint. =I think you can change this behaviour - have a look at the man page =for 'mount_nfs' - in particular things like the '-i' option & 'soft' =mounting etc... This is different and, AFAIK, it slows down your usual NFS work... -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806012135.RAA21867>