Jeff Layton wrote:
> On Wed, 25 Jul 2007 15:36:18 -0400
> Chuck Lever <chuck.lever@oracle.com> wrote:
> 
>> I thought "nointr" was the default because it is safest.
>>
> 
> I could see maybe with soft mounts, but in conjunction with a hard
> mount (which is the default) is there danger of corruption?

If you hit ^C during a multi-segment write, I believe there is the 
possibility of data corruption.

>> Jeff Layton wrote:
>>> The current string-based mount options default to "nointr" mounts. This
>>> is consistent with the current behavior of the struct-based mount
>>> options for NFSv2/3, but inconsistent with v4.
>>>
>>> I've just sent a nfs-utils patch to make the default be "intr" for all
>>> NFS flavors. This patch makes the default the same when using
>>> string-based mount options.
>>>
>>> Signed-off-by: Jeff Layton <jlayton@redhat.com>
>>>
>>> diff --git a/fs/nfs/super.c b/fs/nfs/super.c
>>> index b2a851c..55f9b8b 100644
>>> --- a/fs/nfs/super.c
>>> +++ b/fs/nfs/super.c
>>> @@ -1122,7 +1122,9 @@ static int nfs_validate_mount_data(struct nfs_mount_data **options,
>>>  		char *c;
>>>  		int status;
>>>  		struct nfs_parsed_mount_data args = {
>>> -			.flags		= (NFS_MOUNT_VER3 | NFS_MOUNT_TCP),
>>> +			.flags		= (NFS_MOUNT_INTR |
>>> +					   NFS_MOUNT_VER3 |
>>> +					   NFS_MOUNT_TCP),
>>>  			.rsize		= NFS_MAX_FILE_IO_SIZE,
>>>  			.wsize		= NFS_MAX_FILE_IO_SIZE,
>>>  			.timeo		= 600,
>>> @@ -1608,6 +1610,7 @@ static int nfs4_validate_mount_data(struct nfs4_mount_data **options,
>>>  	default: {
>>>  		unsigned int len;
>>>  		struct nfs_parsed_mount_data args = {
>>> +			.flags		= NFS4_MOUNT_INTR,
>>>  			.rsize		= NFS_MAX_FILE_IO_SIZE,
>>>  			.wsize		= NFS_MAX_FILE_IO_SIZE,
>>>  			.timeo		= 600,
>>> _______________________________________________
>>> NFSv4 mailing list
>>> NFSv4@linux-nfs.org
>>> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
> 
>