Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Feb 2010 10:20:06 -0800 (PST)
From:      Nate Eldredge <nate@thatsmathematics.com>
To:        Dmitry Marakasov <amdmi3@amdmi3.ru>
Cc:        freebsd-hackers@freebsd.org, Oliver Fromme <olli@lurza.secnetix.de>, freebsd-stable@freebsd.org
Subject:   Re: NFS write corruption on 8.0-RELEASE
Message-ID:  <Pine.GSO.4.64.1002121012480.5432@zeno.ucsd.edu>
In-Reply-To: <20100212180032.GC94665@hades.panopticon>
References:  <freebsd-hackers.77287.1265825437.20100210174338.GC39752@hades.panopticon> <201002102046.o1AKkrvj085173@lurza.secnetix.de> <20100212180032.GC94665@hades.panopticon>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Feb 2010, Dmitry Marakasov wrote:

> * Oliver Fromme (olli@lurza.secnetix.de) wrote:
>
>> This is an excerpt from Solaris' mount_nfs(1M) manpage:
>>
>>     File systems that are mounted read-write or that  con-
>>     tain  executable  files  should always be mounted with
>>     the hard option.  Applications using soft mounted file
>>     systems  may incur unexpected I/O errors, file corrup-
>>     tion, and unexpected  program  core  dumps.  The  soft
>>     option is not recommended.
>>
>> FreeBSD's manual page doesn't contain such a warning, but
>> maybe it should.  (It contains a warning not to use "soft"
>> with NFSv4, though, for different reasons.)
>
> Interesting, I'll try disabling it. However now I really wonder why
> is such dangerous option available (given it's the cause) at all,
> especially without a notice. Silent data corruption is possibly the
> worst thing to happen ever.

Tell me about it. :)

But in this case I'm not sure I understand.  As I understand it, the 
difference between soft and hard is that in the case of soft, a timeout 
will result in the operation failing and returning EIO or the like (hence 
"unexpected I/O errors").  And if the operation is being done to fault in 
a mapped page, you'd have to notify the process asynchronously by sending 
a signal like SIGBUS which it may not be expecting (hence "unexpected core 
dumps").  But in what scenario would you see file corruption?  Unless you 
have a buggy program that doesn't check return values from system calls or 
handles signals in a stupid way, I don't see how this can happen, and I'm 
not sure what the Sun man page is referring to.

-- 

Nate Eldredge
nate@thatsmathematics.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1002121012480.5432>