All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: nfsv4@linux-nfs.org, nfs@lists.sourceforge.net
Subject: Re: [PATCH] NFS: have string-based mount options default to "intr" mounts
Date: Wed, 25 Jul 2007 15:48:24 -0400	[thread overview]
Message-ID: <46A7A908.3080906@oracle.com> (raw)
In-Reply-To: <20070725154107.063c3b9a.jlayton@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

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
> 
> 

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 259 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

  reply	other threads:[~2007-07-25 19:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-25 18:56 [PATCH] NFS: have string-based mount options default to "intr" mounts Jeff Layton
2007-07-25 19:36 ` Chuck Lever
2007-07-25 19:41   ` Jeff Layton
2007-07-25 19:48     ` Chuck Lever [this message]
2007-07-25 20:16     ` Trond Myklebust
2007-07-25 20:36       ` Peter Staubach
2007-07-26  2:44         ` Trond Myklebust
2007-07-25 20:43       ` Jeff Layton
2007-07-25 21:07         ` Peter Staubach
2007-07-25 23:48           ` Jeff Layton
2007-07-25 23:51             ` Jeff Layton
  -- strict thread matches above, loose matches on Subject: below --
2007-07-25 20:05 [PATCH] NFS: have string-based mount options default to intr mounts Rick Macklem

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46A7A908.3080906@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=jlayton@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=nfsv4@linux-nfs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.