From: "Gregory Baker" <gregory.baker@amd.com>
To: nfs@lists.sourceforge.net
Cc: julia bauer <julia.bauer@amd.com>,
Trond Myklebust <Trond.Myklebust@netapp.com>
Subject: Re: inconsistent mount attributes (ro/rw), RHEL5 / Netapp
Date: Thu, 19 Apr 2007 13:24:29 -0500 [thread overview]
Message-ID: <4627B3DD.5050409@amd.com> (raw)
In-Reply-To: <1176948355.6422.72.camel@heimdal.trondhjem.org>
It becomes more interesting (well, to me anyways) when you compare the
behavior of RHEL3/4 (ro,rw netgroup export from filer works) with RHEL 5
(ro,rw netgroup export from filer no works).
---+ System environment
[root@build-el3-64 greg]# uname -a
Linux build-el3-64 2.4.21-47.ELsmp #1 SMP Wed Jul 5 20:30:30 EDT 2006
x86_64 unknown unknown GNU/Linux
[root@build-el3-64 greg]# rpm -qa | grep nfs-utils
nfs-utils-1.0.6-44EL
[root@build-el3-64 mnt2]# mount -V
mount: mount-2.11y
---+ NFS server (Netapp) environment
[greg@apathy greg]$ sudo rsh eng version
NetApp Release 7.2P4: Tue Nov 28 02:55:54 PST 2006
---++ NFS export file entry
[greg@apathy greg]$ sudo rsh eng exportfs | grep pandora
/vol/vol4/pandora
-sec=sys,ro,rw=@volexport-pandora,root=@volexport-pandora,anon=4058
---++ netgroup member (for export file entry above)
[root@build-el3-64 mnt2]# show_netgroup volexport-pandora | grep
build-el3-64
build-el3-64.amd.com
---+ Demonstration of ro/rw mount reporting and working
[root@build-el3-64 greg]# mount
eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2
[root@build-el3-64 greg]# mount -v | grep mnt2
eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt2 type nfs
(rw,addr=163.181.34
.137)
[root@build-el3-64 greg]# cat /proc/mounts | grep mnt2
eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs
rw,v3,rsize=32768,wsize=327
68,hard,udp,lock,addr=eng 0 0
[root@build-el3-64 greg]# cd /mnt2
[root@build-el3-64 mnt2]# touch asdf
[root@build-el3-64 mnt2]# ls -la asdf
-rw-r--r-- 1 root root 0 Apr 19 13:18 asdf
Ideas?
Thanks,
--Greg
Trond Myklebust wrote:
> On Wed, 2007-04-18 at 16:53 -0500, Gregory Baker wrote:
>> Note I have cases open with Redhat and Netapp, but was curious if other
>> people have also seen inconsistent mount attributes (ro/rw) when
>> mounting RHEL5 client vs. Netapp 7.2 Ontap.
>>
>> ---+ System environment
>>
>> [greg@adcgar04 greg]$ uname -a
>> Linux adcgar04 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:14 EST 2007 x86_64
>> unknown unknown GNU/Linux
>>
>> [greg@adcgar04 greg]$ rpm -qa | grep nfs-utils
>> nfs-utils-1.0.9-16.el5
>> nfs-utils-lib-1.0.8-7.2
>> nfs-utils-lib-devel-1.0.8-7.2
>> nfs-utils-lib-1.0.8-7.2
>> nfs-utils-lib-devel-1.0.8-7.2
>>
>> [greg@adcgar04 greg]$ mount -V
>> mount (util-linux 2.13-pre7)
>>
>> ---+ NFS server (Netapp) environment
>>
>> [greg@apathy greg]$ sudo rsh eng version
>> NetApp Release 7.2P4: Tue Nov 28 02:55:54 PST 2006
>>
>> ---++ NFS export file entry
>>
>> [greg@apathy greg]$ sudo rsh eng exportfs | grep pandora
>>
>> /vol/vol4/pandora
>> -sec=sys,ro,rw=@volexport-pandora,root=@volexport-pandora,anon=4058
>>
>> ---++ netgroup member (for export file entry above)
>>
>> [greg@apathy greg]$ show_netgroup volexport-pandora | grep adcgar
>> adcgar04.amd.com
>>
>> ---+ Demonstration of inconsistent ro/rw mount reporting
>>
>> [root@adcgar04 /]# mount eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2
>>
>> [root@adcgar04 /]# mount -v | grep mnt2
>> eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt2 type nfs
>> (rw,addr=163.181.34.137)
>>
>> [root@adcgar04 /]# cat /proc/mounts | grep mnt2
>> eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs
>> ro,vers=3,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng
>> 0 0
>>
>> [root@adcgar04 /]# cd /mnt2/
>>
>> [root@adcgar04 mnt2]# touch asdf
>> touch: cannot touch `asdf': Read-only file system
>>
>> ---+ Discussion
>>
>> ---++Linux (RHEL3/4) NFS servers that have similiar exportfs options
>>
>> /tmp *(ro,anonuid=4058) @volexport-pandora(rw,no_root_squash)
>>
>> do not cause the inconsistent behavior between mount -v and /proc/mounts
>> (and it is mounted rw as expected on the client).
>>
>> ---++ A reply from NetApp had this info:
>>
>> Starting with ONTAP 7.2.1 onward, ONTAP will display the "most
>> pessimistic" permissions to NFSv3 and NFSv4 clients. NFSv2 clients will
>> see permissions the same way as in previous releases of ONTAP, i.e. the
>> "most optimistic" permissions.
>>
>> And mounting using NFS v2 (instead of v3) does give us the expected
>> rw/rw consistency and ability.
>>
>> ---++ So now what?
>>
>> Should the linux mount -v and cat /proc/mounts be consistent with what
>> is actually happening?
>
> There is no way for the Linux client to find out that this is a
> read-only volume at mount time. Only when you try an operation that
> actually attempts to modify the filesystem will the protocol allow the
> server to return NFSERR_ROFS.
> Furthermore, there is nothing in the protocol that states that a
> filesystem that issues NFSERR_ROFS will return the same reply the next
> time the same modification is attempted. Filesystems may switch from
> being read only to not being read only at will.
>
>> Should netapp exports syntax handle a wildcard ro and a netgroup rw?
>
> That is a very good question, but it deserves to be directed to the
> appropriate people at netapp and is not really appropriate for
> nfs@lists.sourceforge.net (which is more about Linux NFS). If you
> haven't already done so, I'd suggest opening an official escalation of
> the matter. Your embedded netapp sales representative (sorry, but I'm
> not entirely up to date on who that is) should be able to help you with
> this.
>
> Cheers
> Trond
>
--
----------------------------------------------------------------------
Greg Baker 512-602-3287 (work)
gregory.baker@amd.com 512-602-6970 (fax)
5204 E. Ben White Blvd MS 625 512-555-1212 (info)
Austin, TX 78741
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-04-19 18:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-18 21:53 inconsistent mount attributes (ro/rw), RHEL5 / Netapp Gregory Baker
[not found] ` <1176948355.6422.72.camel@heimdal.trondhjem.org>
2007-04-19 18:24 ` Gregory Baker [this message]
2007-04-19 18:31 ` Trond Myklebust
2007-04-19 20:37 ` Gregory Baker
2007-04-19 22:11 ` Trond Myklebust
2007-04-19 22:23 ` Gregory Baker
2007-04-23 18:36 ` Gregory Baker
2007-04-24 19:57 ` Gregory Baker
2007-04-24 22:01 ` Gregory Baker
2007-05-04 20:30 ` Gregory Baker
2007-05-04 21:41 ` Trond Myklebust
2007-05-05 15:37 ` Ian Kent
2007-05-05 17:17 ` Trond Myklebust
2007-05-05 18:27 ` Ian Kent
2007-05-05 18:49 ` Trond Myklebust
2007-05-06 4:51 ` Ian Kent
2007-05-14 13:17 ` Karel Zak
2007-05-14 13:24 ` Trond Myklebust
2007-05-14 14:39 ` Ian Kent
2007-05-14 15:47 ` Trond Myklebust
2007-05-14 15:56 ` Paul Krizak
2007-05-14 16:06 ` Trond Myklebust
2007-05-14 16:06 ` Ian Kent
2007-05-14 22:41 ` Neil Brown
2007-05-14 23:11 ` Trond Myklebust
2007-05-14 23:58 ` Neil Brown
2007-05-16 0:27 ` Trond Myklebust
2007-05-16 1:36 ` [PATCH 1/2] NFS: Add the mount option nosharedcache Trond Myklebust
2007-05-16 3:46 ` Neil Brown
2007-05-16 13:22 ` Trond Myklebust
2007-05-17 2:13 ` [PATCH 1/2] NFS: Add the mount option "nosharecache" Trond Myklebust
2007-05-18 3:12 ` Ian Kent
2007-05-18 13:20 ` Trond Myklebust
2007-05-18 14:57 ` Ian Kent
2007-05-17 2:13 ` [PATCH] mount.nfs: Add support for the 'nosharecache' option Trond Myklebust
2007-05-17 2:13 ` [PATCH 2/2] NFS: Error when mounting the same filesystem with different options Trond Myklebust
2007-05-29 2:35 ` Neil Brown
2007-06-05 23:49 ` Trond Myklebust
2007-05-16 1:37 ` Trond Myklebust
2007-05-15 13:58 ` inconsistent mount attributes (ro/rw), RHEL5 / Netapp Chuck Lever
2007-05-15 14:33 ` Trond Myklebust
2007-05-15 16:57 ` Gregory Baker
2007-05-14 14:30 ` Ian Kent
2007-05-14 13:03 ` Karel Zak
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=4627B3DD.5050409@amd.com \
--to=gregory.baker@amd.com \
--cc=Trond.Myklebust@netapp.com \
--cc=julia.bauer@amd.com \
--cc=nfs@lists.sourceforge.net \
/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.