toasters April 2007

toasters@lists.teaparty.net

68 participants
51 discussions

Re: network troubleshooting
by Davies,Matt 24 Apr '07

24 Apr '07

Steve, Could you expand on what the problem is ? What model of Cisco switches are involved, and is qos enabled on the network ? Cheers Matt -----Original Message----- From: owner-toasters(a)mathworks.com <owner-toasters(a)mathworks.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Tue Apr 24 17:37:53 2007 Subject: network troubleshooting Hello World! Our Network admin has been working with Cisco to troubleshoot some issues (limited to 1 switch on 1 particular floor). While our Filers are not involved in this issue, fingers are generally pointed in that direction just because they exist....on the network. Our network admin is looking for information from the Filers that would be akin to a TCP dump. Ifstat, netstat and statit output are not providing the information being looked for (handshake info, etc). I haven't run across this particular issue before and don't recall ever seeing it presented to Toasters. Does anyone know of a way to get the actual communication dumps (again, a TCP dump) from a Filer? Thanks! Steve _____________________________________________________________ This e-mail (including all attachments) is confidential and may be privileged. It is for the exclusive use of the addressee only. If you are not the addressee, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately at help(a)generalatlantic.com <mailto:help@generalatlantic.com>. Thank You.

1 0

OT: EMC mailing list
by Jeff Mery 24 Apr '07

24 Apr '07

Anyone know of an EMC mailing list? Ideally one that leans towards Clariion/CX kit? Jeff Mery - MCSE, MCP National Instruments ------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------

2 1

Re: inconsistent mount attributes (ro/rw), RHEL5 / Netapp]
by Gregory Baker 23 Apr '07

23 Apr '07

Trond Myklebust wrote: > On Thu, 2007-04-19 at 15:37 -0500, Gregory Baker wrote: > >> ---+ BAD RHEL 5 64 system > ... >> [root@adcgar04 mnt2]# 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 > > That would be your problem right there. Is the same volume perhaps > mounted read-only somewhere else on the same client? That is no longer > allowed. > > Cheers > Trond > Ah, news to me! So if you mount a volume ro at one mount point /mnt1 and then try to mount the same volume rw at a second mount point /mnt2 you'll run into problems? Apologies, didn't catch this in release notes. --Greg ---+ A New Beginning [root@adcgar04 /]# umount -a -t nfs [root@adcgar04 /]# mount -v | grep pandora [root@adcgar04 /]# cat /proc/mounts | grep pandora [root@adcgar04 /]# mount eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 [root@adcgar04 /]# mount -v | grep pandora 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 pandora eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs rw,vers=3,rsize=65536,wsize=65536,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng 0 0 [root@adcgar04 /]# touch /mnt2/asdf ---+ The ro Strikes Back [root@adcgar04 /]# mount -o ro eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt1 [root@adcgar04 /]# mount -o rw eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 [root@adcgar04 /]# mount -v | grep mnt eng:/vol/vol4/pandora/pandora-k26_g25_64-2 on /mnt1 type nfs (ro,addr=163.181.34.137) 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 mnt eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt1 nfs ro,vers=3,rsize=65536,wsize=65536,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng 0 0 eng:/vol/vol4/pandora/pandora-k26_g25_64-2 /mnt2 nfs ro,vers=3,rsize=65536,wsize=65536,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=eng 0 0 [root@adcgar04 /]# touch /mnt2/asdf touch: cannot touch `/mnt2/asdf': Read-only file system Choudhury, Bikash wrote: > There are two different things happening here. > > 1) The ro/rw rule in the filer exports file > > 2) The mount -v and cat/proc/mounts > > 1) Regarding the ro/rw rule that you have in the export file, I run a > small test in my lab. I have tried to replicate the problem with the > same rule as you have sent in your exports but I have not used the > netgroups instead used the ip subnets. I ran these tests on 7.2.2 filer. > > fas960c-svl04*> exportfs > > /vol/test_vol > -sec=sys,ro=172.17.39.0/22,rw=172.17.39.0/29,root=172.17.39.72,nosuid > > /vol/vol0/home -sec=sys,rw,nosuid > > /vol/vol0 -sec=sys,rw,anon=0,nosuid > > This is what you noticed on the Linux client: > > [root@ibmx335-svl14 mnt]# mount fas960c-svl04:/vol/test_vol /mnt/b1 > > [root@ibmx335-svl14 mnt]# ls -al > > total 20 > > drwxr-xr-x 3 root root 4096 Feb 28 03:12 . > > drwxr-xr-x 25 root root 4096 Feb 24 09:27 .. > > drwxr-xr-x 3 root root 4096 Nov 20 11:11 b1 > > [root@ibmx335-svl14 mnt]# cd /etc > > [root@ibmx335-svl14 etc]# touch /mnt/b1/testfile1 > > touch: cannot touch `/mnt/bik/testfile1': Permission denied > > On the filer I checked the permission for that file system. You can > probably run the same command on your filer to check the exact > permissions for /vol/vol4/Pandora. Replace the ip address with the one > for your RHEl5 client. > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol rw > > exportfs: 172.17.39.72 does not have rw access to /vol/test_vol (Access > reduced) > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol ro > > exportfs: 172.17.39.72 has ro access to /vol/test_vol > > > > This is definitely going to happen BECAUSE; take a look at the > /etc/exports file. The –ro is set on /22 subnet. This means 22 bits out > 32 are used as network address and the remaining 10 bits determine the > number of host i.e: 2^10. This indicates that the /22 with 255.255.252.0 > subnet has more number of clients that /29 with subnet 255.255.255.248. > When –ro is specified on a bigger network (/22) and –rw is listed with > the (/29) network, the more restricted one takes precedence, i.e ‘-ro’. > In my example the linux client had ip address 172.17.39.72 which falls > in the bigger network (/22) and is not in the (/29) network. Therefore > the client gets ‘-ro’ access instead of ‘rw’. When you try you a ‘touch’ > a file as ‘root’ from this client, you get ‘permission denied’ which is > legitimate because this client has ‘ro’ access. > > In your case you have -ro set on /vol/vol4/Pandora to every one and then > have -rw set to @volexport-pandora,root=@volexport-pandora which is part > of the wide spectrum that has '-ro' set. > > Then I switched the ‘ro’ to the (/29) network and ‘rw’ to (/22) network. > This is what it looks now. > > On the filer after the switch > > fas960c-svl04*> exportfs > > /vol/test_vol > -sec=sys,ro=172.17.39.0/29,rw=172.17.39.0/22,root=172.17.39.72,nosuid > > /vol/vol0/home -sec=sys,rw,nosuid > > /vol/vol0 -sec=sys,rw,anon=0,nosuid > > On the client after the switch: > > [root@ibmx335-svl14 etc]# touch /mnt/b1/testfile1 > > [root@ibmx335-svl14 etc]# ls -l /mnt/b1 > > total 0 > > -rw-r--r-- 1 root root 0 Feb 27 10:46 testfile1 > > > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol ro > > exportfs: 172.17.39.72 has ro access to /vol/test_vol > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol rw > > exportfs: 172.17.39.72 has rw access to /vol/test_vol > > > > Now I am able to touch the file w/o any problems. In your case > adcgar04.amd.com is part of the bigger network that has ‘ro’ access. As > suggested in the man page ‘ro’ will take precedence over ‘rw’ and > touching a file from a host in the /22 network will end up with a > ‘permission denied’. Currently this is by design. However, there is an > RFE 237892 open for this configuration to work. If you decide to upgrade > then you may consider 7.2.2 but this release does not fix this RFE. > > 2) I was currently running the above test from a RHEL5 client. But I did > not notice any difference in the mount options between 'mount -v' and > 'cat /proc/mounts'. > > [root@ibmx335-svl47 etc]# uname -a > > Linux ibmx335-svl47 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 > i686 i686 i386 GNU/Linux > > [root@ibmx335-svl47 ~]# rpm -qa |grep nfs-utils > > nfs-utils-1.0.9-16.el5 > > nfs-utils-lib-1.0.8-7.2 > > [root@ibmx335-svl47 ~]# mount -v|grep b1 > > 172.17.44.44:/vol/test_vol on /mnt/b1 type nfs4 > (*rw*,vers=4,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,addr=172.17.44.44) > > [root@ibmx335-svl47 ~]# cat /proc/mounts|grep b1 > > 172.17.44.44:/vol/test_vol /mnt/b1 nfs4* > rw*,vers=4,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,add > > Bikash R.Choudhury > > -----Original Message----- > From: Gregory Baker [mailto:gregory.baker@amd.com] > Sent: Wednesday, April 18, 2007 3:23 PM > To: toasters(a)mathworks.com > Cc: julia bauer > Subject: inconsistent mount attributes (ro/rw), RHEL5 / Netapp] > > 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? > > Should netapp exports syntax handle a wildcard ro and a netgroup rw? > > Comments and feedback welcome. > > Thanks, > > --Greg > > -- > > ---------------------------------------------------------------------- > > Greg Baker 512-602-3287 (work) > > gregory.baker(a)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(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nfs > > > -- > > ---------------------------------------------------------------------- > > Greg Baker 512-602-3287 (work) > > gregory.baker(a)amd.com 512-602-6970 (fax) > > 5204 E. Ben White Blvd MS 625 512-555-1212 (info) > > Austin, TX 78741 > -- ---------------------------------------------------------------------- Greg Baker 512-602-3287 (work) gregory.baker(a)amd.com 512-602-6970 (fax) 5204 E. Ben White Blvd MS 625 512-555-1212 (info) Austin, TX 78741

1 1

ndmpcopy and the newb Part II
by Brian Dunbar 20 Apr '07

20 Apr '07

Me again. When last we met I had a question about ndmpcopy - the copy went over well - files moved, the application that needs those files had a brief outage and all is well. I'm cleaning up the source volume - 'best practice' here is to remove files, remove snapshots and shrink the volume to 10g should we need a place to stash files. Removed the files, done. Removed the snapshots, done. Except for one guy that is being stubborn. The fellow with just a bit more experience with these than I do claims it must be because a server is still has that volume mounted and if I showmount that appears to be the case .. except the remote host in question no longer has that mounted - going by 'df -k' and /etc/vfstab. Now - a very long time ago - back in November of 06 - this volume was cloned and mounted so that an application under development could see the contents of the file store there. Is there something special - clearly there might be - about clones and mirrors that require an extra effort to delete a snapshot? Or am I doing something fundamentally wrong? I would not ordinarily go the newb well twice in a fortnight but I've been looking at this since early this morning and I'm no closer to figuring out WHY than when I started. Thanks. HOST:/:# rsh co-dsk-007 snap list aprod4 Volume aprod4 working... %/used %/total date name ---------- ---------- ------------ -------- 28% (28%) 0% ( 0%) Nov 16 15:30 clone_aprod4_cln_aglif.1 (busy,vclone) "Busy? Surely the OS isn't going to let me blow away something that is marked as busy .." HOST:/:# rsh co-dsk-007 snap delete aprod4 clone_aprod4_cln_aglif.1 Snapshot clone_aprod4_cln_aglif.1 is busy because of "How bout that. What about the nfs mounts?" LOCALHOST:/sbin:showmount -a co-dsk-007 | grep aprod4 206.209.246.192:/vol/aprod4 co-ap-103v.plexus.com:/vol/aprod4 co-ap-930v.plexus.com:/vol/aprod4_cln_aglifs "Both hosts have been vi /etc/vfstab 'd and umounted and even rebooted to death at this point .." Brian Dunbar Systems Administrator II Plexus brian.dunbar(a)plexus.com Desk: (920) 751-3364 Cell: (920) 716-2027

3 5

FAS3020 + FC LTO Gen 3.
by Ken Williams 20 Apr '07

20 Apr '07

Toasters! I have been trying for a couple weeks now to get my 3020 to properly see an LTO Gen 3 FC Tape drive. Environment: FAS3020, attached to Cisco MDS Fabric with ISL between two MDS9509s attached to HP Ultrium 3 LTO3 Drive. The LTO3 drive is installed in a StorageTek L700 Library which fiber channel robotic control. The backup environment is Symantec Netbackup. There is no extra HBA cards in the FAS3020, so we are using the onboard card. The Good: I can manually load a tape, the Filer sees the drive/tape. The Bad: The system always reports back that the tape is a LTO1 200GB read only. Naturally I tried several other tape drives and tape media, all with the same problem. I have 2 FAS940s that do not have any issue talking to LTO3 Tape drives. I've downloaded the latest device configuration files from now, I've been working with the technical support at netapp. My best assumption is that the drives are in the wrong block mode. Has anyone seen anything like this? __________________________________________________________ Ken Williams Storage Administrator, Business Technology Operations Sacramento Municipal Utility District E-Mail: kwillia(a)smud.org Phone: (916) 732-6744 Cell: (916) 240-4213

4 5

Add two disks to an aggregate and reallocate
by Willeke, Jochen 20 Apr '07

20 Apr '07

Hi toasters, can we rise aggr-size from e.g. 14 to 16 add two disks and do an reallocate without having to much performance impact because of "hot-disks"?!?! Has anybody made experiences with this? rdgs Jochen

1 0

Re: inconsistent mount attributes (ro/rw), RHEL5 / Netapp]
by Gregory Baker 19 Apr '07

19 Apr '07

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 Choudhury, Bikash wrote: > There are two different things happening here. > > 1) The ro/rw rule in the filer exports file > > 2) The mount -v and cat/proc/mounts > > 1) Regarding the ro/rw rule that you have in the export file, I run a > small test in my lab. I have tried to replicate the problem with the > same rule as you have sent in your exports but I have not used the > netgroups instead used the ip subnets. I ran these tests on 7.2.2 filer. > > fas960c-svl04*> exportfs > > /vol/test_vol > -sec=sys,ro=172.17.39.0/22,rw=172.17.39.0/29,root=172.17.39.72,nosuid > > /vol/vol0/home -sec=sys,rw,nosuid > > /vol/vol0 -sec=sys,rw,anon=0,nosuid > > This is what you noticed on the Linux client: > > [root@ibmx335-svl14 mnt]# mount fas960c-svl04:/vol/test_vol /mnt/b1 > > [root@ibmx335-svl14 mnt]# ls -al > > total 20 > > drwxr-xr-x 3 root root 4096 Feb 28 03:12 . > > drwxr-xr-x 25 root root 4096 Feb 24 09:27 .. > > drwxr-xr-x 3 root root 4096 Nov 20 11:11 b1 > > [root@ibmx335-svl14 mnt]# cd /etc > > [root@ibmx335-svl14 etc]# touch /mnt/b1/testfile1 > > touch: cannot touch `/mnt/bik/testfile1': Permission denied > > On the filer I checked the permission for that file system. You can > probably run the same command on your filer to check the exact > permissions for /vol/vol4/Pandora. Replace the ip address with the one > for your RHEl5 client. > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol rw > > exportfs: 172.17.39.72 does not have rw access to /vol/test_vol (Access > reduced) > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol ro > > exportfs: 172.17.39.72 has ro access to /vol/test_vol > > > > This is definitely going to happen BECAUSE; take a look at the > /etc/exports file. The –ro is set on /22 subnet. This means 22 bits out > 32 are used as network address and the remaining 10 bits determine the > number of host i.e: 2^10. This indicates that the /22 with 255.255.252.0 > subnet has more number of clients that /29 with subnet 255.255.255.248. > When –ro is specified on a bigger network (/22) and –rw is listed with > the (/29) network, the more restricted one takes precedence, i.e ‘-ro’. > In my example the linux client had ip address 172.17.39.72 which falls > in the bigger network (/22) and is not in the (/29) network. Therefore > the client gets ‘-ro’ access instead of ‘rw’. When you try you a ‘touch’ > a file as ‘root’ from this client, you get ‘permission denied’ which is > legitimate because this client has ‘ro’ access. > > In your case you have -ro set on /vol/vol4/Pandora to every one and then > have -rw set to @volexport-pandora,root=@volexport-pandora which is part > of the wide spectrum that has '-ro' set. > > Then I switched the ‘ro’ to the (/29) network and ‘rw’ to (/22) network. > This is what it looks now. > > On the filer after the switch > > fas960c-svl04*> exportfs > > /vol/test_vol > -sec=sys,ro=172.17.39.0/29,rw=172.17.39.0/22,root=172.17.39.72,nosuid > > /vol/vol0/home -sec=sys,rw,nosuid > > /vol/vol0 -sec=sys,rw,anon=0,nosuid > > On the client after the switch: > > [root@ibmx335-svl14 etc]# touch /mnt/b1/testfile1 > > [root@ibmx335-svl14 etc]# ls -l /mnt/b1 > > total 0 > > -rw-r--r-- 1 root root 0 Feb 27 10:46 testfile1 > > > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol ro > > exportfs: 172.17.39.72 has ro access to /vol/test_vol > > fas960c-svl04*> exportfs -c 172.17.39.72 /vol/test_vol rw > > exportfs: 172.17.39.72 has rw access to /vol/test_vol > > > > Now I am able to touch the file w/o any problems. In your case > adcgar04.amd.com is part of the bigger network that has ‘ro’ access. As > suggested in the man page ‘ro’ will take precedence over ‘rw’ and > touching a file from a host in the /22 network will end up with a > ‘permission denied’. Currently this is by design. However, there is an > RFE 237892 open for this configuration to work. If you decide to upgrade > then you may consider 7.2.2 but this release does not fix this RFE. > > 2) I was currently running the above test from a RHEL5 client. But I did > not notice any difference in the mount options between 'mount -v' and > 'cat /proc/mounts'. > > [root@ibmx335-svl47 etc]# uname -a > > Linux ibmx335-svl47 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 > i686 i686 i386 GNU/Linux > > [root@ibmx335-svl47 ~]# rpm -qa |grep nfs-utils > > nfs-utils-1.0.9-16.el5 > > nfs-utils-lib-1.0.8-7.2 > > [root@ibmx335-svl47 ~]# mount -v|grep b1 > > 172.17.44.44:/vol/test_vol on /mnt/b1 type nfs4 > (*rw*,vers=4,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,addr=172.17.44.44) > > [root@ibmx335-svl47 ~]# cat /proc/mounts|grep b1 > > 172.17.44.44:/vol/test_vol /mnt/b1 nfs4* > rw*,vers=4,rsize=65536,wsize=65536,hard,intr,proto=tcp,timeo=600,retrans=3,sec=sys,add > > Bikash R.Choudhury > > -----Original Message----- > From: Gregory Baker [mailto:gregory.baker@amd.com] > Sent: Wednesday, April 18, 2007 3:23 PM > To: toasters(a)mathworks.com > Cc: julia bauer > Subject: inconsistent mount attributes (ro/rw), RHEL5 / Netapp] > > 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? > > Should netapp exports syntax handle a wildcard ro and a netgroup rw? > > Comments and feedback welcome. > > Thanks, > > --Greg > > -- > > ---------------------------------------------------------------------- > > Greg Baker 512-602-3287 (work) > > gregory.baker(a)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(a)lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/nfs > > > -- > > ---------------------------------------------------------------------- > > Greg Baker 512-602-3287 (work) > > gregory.baker(a)amd.com 512-602-6970 (fax) > > 5204 E. Ben White Blvd MS 625 512-555-1212 (info) > > Austin, TX 78741 > -- ---------------------------------------------------------------------- Greg Baker 512-602-3287 (work) gregory.baker(a)amd.com 512-602-6970 (fax) 5204 E. Ben White Blvd MS 625 512-555-1212 (info) Austin, TX 78741

1 0

inconsistent mount attributes (ro/rw), RHEL5 / Netapp]
by Gregory Baker 19 Apr '07

19 Apr '07

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? Should netapp exports syntax handle a wildcard ro and a netgroup rw? Comments and feedback welcome. Thanks, --Greg -- ---------------------------------------------------------------------- Greg Baker 512-602-3287 (work) gregory.baker(a)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(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs -- ---------------------------------------------------------------------- Greg Baker 512-602-3287 (work) gregory.baker(a)amd.com 512-602-6970 (fax) 5204 E. Ben White Blvd MS 625 512-555-1212 (info) Austin, TX 78741

2 1

RE: how to obtain patch releases
by Davin Milun 18 Apr '07

18 Apr '07

What's the feeling on 7.2.1.1P1, which is what I was about to deploy? Davin. At 13:47, on Mar 27, 2007, "Kevin Davis" wrote: > I'd stay away from 7.2.1P1 if I were you. We got slammed by _at least_ > 2 nasty bugs, and are now considering our options for applying > subsequent patches. (7.2.1.1D3, etc...) > > > > *------------------------------------------*-----------------------* > | Kevin Davis (UNIX Sysadmin) | Natick, Massachusetts | > | 508.647.7660 | 01760-2098 | > | mailto:kevin.davis@mathworks.com *-----------------------* > | http://www.mathworks.com | | > *------------------------------------------*-----------------------* > > > > > -----Original Message----- > > From: owner-toasters(a)mathworks.com > > [mailto:owner-toasters@mathworks.com] On Behalf Of J. Greg Mackinnon > > Sent: Monday, February 05, 2007 10:34 AM > > To: toasters > > Subject: how to obtain patch releases > > > > We currently are running OnTap 7.2.0 and not having fun with > > it. 7.2.1 contains many important fixes, but 7.2.1P1 has > > some critical fixes as well. I am getting fed up waiting for > > the next GA release, and I am willing to take the risk of > > running a patch build. The only problem... > > I cannot figure out how to download it! > > > > In the past I have found patch release download links in the > > NOW KB when referencing a related bug number... not so this time. > > > > Anyone know how to get the binaries? Open a support case? > > Bribe a NetApp tech? > > > > Thanks, > > -Greg Mackinnon > > University of Vermont

3 2

RE: Information on how Netapp single_image mode works
by Mike Ball 18 Apr '07

18 Apr '07

Thanks for the responses but I am still confused about how the paths are determined. For example, lets say I have a FAS6030C (Node1 and Node2) running Data Ontap 7.2.1 with each head having 2 target ports each in a switched fibre fabric. In this fabric, I have a Windows host (running Snapdrive 4.2.1 and DSM 3.0) with a dual port fibre card. I create lun0 on Node1 from the Windows host via Snapdrive. How is the path chosen by the FAS6030C? Is there a round robin algorithm which gives out the target port on Node1 to the Windows host? -----Original Message----- From: Paul Rosham [mailto:paulrosham@yahoo.com.au] Sent: Monday, April 16, 2007 11:26 PM To: 'Jack Lyons'; 'Nils Vogels' Cc: Mike Ball; toasters(a)mathworks.com Subject: RE: Information on how Netapp single_image mode works In addition, anything with a reasonable NVRAM/Cluster interconnect setup (i.e. 3000, 6000 series) the additional latency of the request passing to the correct head via the cluster interconect is almost negligible. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jack Lyons Sent: Tuesday, 17 April 2007 11:10 AM To: Nils Vogels Cc: Mike Ball; toasters(a)mathworks.com Subject: Re: Information on how Netapp single_image mode works one caveat, based on my experience the host based software will see all paths to the filer as equal, so if you hit the WWPN on the "other" head of the cluster, you will get an error message and an ASUP. It is annoying, and as far as I know, not a problem. Jack Nils Vogels wrote: > Hey Mike, > > On 4/16/07, Mike Ball <MBall(a)datalink.com> wrote: >> >> I am trying to find additional information on how Netapp single_image >> mode works in a clustered environment as it pertains to pathing. >> Single_image mode pulls all the WWPN's from the Netapp cluster and >> presents it to the SAN as one WWNN. What I would like to know is how >> paths are determined from hosts to cluster nodes if no target portals >> are defined? >> > > There will be multiple paths available (at least 2, one for ClusterA, > one for ClusterB) and you generally will need host-based path > selection software to select the active one. > > Some software selects on 'Most Recently Used', other selects on fixed > path, this may vary per multipathing-software. >

6 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters April 2007