toasters

toasters@lists.teaparty.net

13515 discussions

NFSv4 and access circumvention
by Brian Parent 08 Jul '05

08 Jul '05

If you're the main administrator for a Network Appliance filer, and you did *not* receive the following field alert from NetApp, please let me know. I'm trying to determine whether a wider publication effort is warranted. This is not a new bug, but it is a critical one. I discovered it one day (June 8, 2005) on accident, while experimenting with mounts and exports on one of my filers. I dug around in NetApp's NOW site, but didn't find any reference, partly because I didn't know what I was looking for, so I submitted a case. A bit more research revealed the relation to NFSv4, and then I was able to find the bug report on NOW. June 10 is when I suggested that before they close my case, they alert the rest of their customers. It took nearly 30 days for NetApp to finally post a field alert. I think that posting it was the right thing to do, but I'm not pleased that it took so long, and that they hadn't already posted it prior to my discovering it. ---------------------------------------------- From: "Nagabhushan, Dinesh" <Dinesh.Nagabhushan(a)netapp.com> Date: Wed, 6 Jul 2005 18:19:34 -0700 Subject: Field Alert #249: NFSv4 does not perform per operation access checks To: <bparent(a)ucsd.edu> Field Alert #249: NFSv4 does not perform per operation access checks SUMMARY: There is a defect (Bug 132072) in the NFSv4 implementation of Data ONTAP releases 6.4 through 6.5.3 that can allow access to exported filesystems in violation of the settings in the /etc/exports file. The unauthorized access would occur using NFSv4 only, which is enabled by default on systems licensed for NFS in Data ONTAP 6.4 and above. DETAILS: NFS provides the capability to restrict access to a set of specified client systems by using the access rw, ro, and root options in the /etc/exports file or when using the exportfs. The above referenced bug allows certain NFSv4 clients to bypass these restrictions and connect from a host that is not listed in the export options. Once the filesystem is mounted from an unauthorized host, the client has the capability to perform operations like read, write, or modify data within the filesystem PROVIDED THAT the standard filesystem permissions and ACLs allow for those operations to be performed. However, unless the export is configured to allow ONLY Kerberos authentication, the file permission lock-down does not help to mitigate the problem (because the user can choose the UID presented to the filer in the NFS request). WHO IS AFFECTED: You are affected if ALL of the following are true: * You do NOT have bugfix for bug 132072 (i.e. you have Network Appliance system(s) that are running Data ONTAP versions later than or equal to 6.4 but earlier than 6.5.4) , and * You have NFS clients in your environment that support NFSv4, and * NFSv4 is enabled on the above Network Appliance systems. This can be checked by typing "options nfs.v4.enable" at the command prompt. A value of "on" indicates that NFSv4 is enabled. WORK-AROUND: The workaround is to disable NFSv4 on all filers, NearStore systems, and ONTAP simulators. This can be accomplished by typing "options nfs.v4.enable off" at the system console prompt. In the event that you must use NFSv4 ,it is critical that Kerberos authentication be the only authentication system enabled. It is not sufficient to simply add krb5, krb5i, or krb5p to the export configuration; it is also necessary to ensure that sec=sys is NOT specified. SOLUTION: Network Appliance recommends that the workaround of disabling NFSv4 as stated above be used. Furthermore, if there is an opportunity to upgrade the systems please upgrade to Data ONTAP 6.5.4 or later. For any further assistance with upgrading and downloading software, please follow this link: http://now.netapp.com/NOW/cgi-bin/software ADDITIONAL INFORMATION: Online report for bug 132072 http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=132072 ----------------------------------------------

1 0

Aggregate inodes
by Chris Thompson 08 Jul '05

08 Jul '05

What does the output of "df -A -i" mean for a non-traditional aggregate? For example: > df -A -i main Aggregate iused ifree %iused main 108 31034 0% Such aggregates always seem to have 30000+ "inodes", regardless of size, and to use 3 more each time a flexible volume is allocated inside the aggregate. -- Chris Thompson Email: cet1(a)cam.ac.uk

1 0

Hey, Toasters join the LakeChapalaWebBoard
by cgesp.pr＠correo.mae.es 08 Jul '05

08 Jul '05

1 0

huge space reservations for LUN snapshots, max RAID-DP
by Rob Winters 07 Jul '05

07 Jul '05

Imagine my surprise upon discovering that the space reservation for LUN snapshots is 120%, instead of 20% to 30% for a file system. I think I understand why. I wonder what the practical field experience is with trimming that figure down to something the guy who paid for the NetApp will accept. Specifically, if what is on the LUN is a relatively stable NTFS file system, is "blocks changed" similar enough to "files changed", or are there "catastrophic events" that go out and touch many disk blocks at once, thus mandating the huge space reservation? If you under-allocate the reservation, then all disk blocks are suddenly written to, can you configure the NetApp to release the snapshots and commit the writes, or must it look like a premature disk full condition? It seems like a much more economical path will be to ignore the SnapDrive approach, ignore snapshots, and just use Volume Shadow Copy on the windows servers hosting the filesystem. This would get my space reservation back down to 20% to 30%. Any thoughts? Oh, a bonus question: I had a NetApp PS guy recommend 28-disk RAID-DP over 14-disk RAID-DP, saying that there is absolutely no significant difference in re-build time or any other down side. Any thoughts on that? Thanks! /// Rob -- Rob Winters SAIC, NASA Headquarters ISEM Contract

3 3

(no subject)
by coati11＠gmx.net 07 Jul '05

07 Jul '05

Hi all, who has experience with the new sun java messaging server ? We want to centralize the mailbox store on a filer via a nfs mount ( It is supported since february from sun ) The mailbox store on the filer should be in a consistent state after a snapshot was created ? right ? thx in advance -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

1 0

Re: huge space reservations for LUN snapshots, max RAID-DP
by Pou Lee 07 Jul '05

07 Jul '05

Hi all, Peter Smoot of Net App provides the following clarification and exposition concerning DOT LUN snapshots for your reference. I neglected to mention the "delta" functionality in my earlier post and have confused the space reservation with "mirror": even though for storage capacity consideration it's 100% like what a mirror will require, technically LUN snapshots only contain changed blocks as in the case in CIFS/NFS qtrees, not themselves a block by block copy as in a RAID 1 configuration. Pou ************* From Peter ***************************** A LUN snapshot really is just like a NAS snapshot. The snapshot itself only grows as blocks get written to the LUN, so if you take a second, third, fifth snapshot, you don't use up five times the space of the original LUN. Essentially, as you overwrite blocks in the LUN, we move the old block into a snapshot, grab a new block from the volume free space, and write the new data in that empty block. We don't actually move anything around on the platters, it's all done with pointers so it's very fast. The original 100% growth is something called the "space reservation". This space gets reserved so that after taking a snapshot, you can overwrite every single block in the LUN and know you've got space to hold that write. The above algorithm really is "grab a block from the volume free pool, but if that's empty, use a block from the space reservation". The trick is once the volume has no free blocks and you've started using the space reserve, you won't be allowed to create new snapshots. ... Internally, this is refered to as "2x plus delta". The 2x is the original LUN plus it's space reserve, for a total of 2x the size of the LUN. The delta is the number of snapshots times the data churn rate, which could be greater or less than the size of the LUN, depending on many factors. DataONTAP 7g has a volume setting called a "fractional_overwrite" which lets you reserve less than 100% of the LUN size in the space reserve. If you know most of your LUN isn't being overwritten, then a much smaller space reserve is fine. DataFabric Manager (DFM) 3.2 (available in about two weeks) has a bunch of monitoring to track how much space you've reserved and how much of the space reserve you're using, so you can tell whether you're reserving too much, too little, or just about right. ******************** End *************************** Hi Rob, FC/iSCSI LUN's in DataONTAP (DOT) implementation differs from CIFS/NFS qtrees in that they are block based rather than file based since LUN's need to be accessed in that manner on the client sides. Hence LUN snapshot is a misnomer. It is actually a mirrored LUN of the original, in more conventional terms. Thus it requires 100% more storage space for each "snapshot" per LUN. The additional 20+% in my understanding is the buffer space DOT needs to cache the block IO's. I think this 20% is per volume but it will increase if there are many LUN's and much IO activity. I was advised to leave at least 30% to accommodate such IO-intensive situations. Since the snapshot is a mirrored LUN, any block change in the original LUN is propagated to the snapshot in due time, i.e., after being cached/buffered first before written to disks. You can certainly reduce this buffer space down but at your own risk as usual since it will impact performance of the original LUN by taking away buffer/cache improvement for it not to mention that of the snapshot IO process. I have not created 28-disk RAID-DP volumes yet but have investigated this option for one of our Engineering efforts. A special license is required since it is not normally recommended either for technical rational or business justification, i.e., to sell more disks for parity usage. From the white papers that I read, DOT LUN is still based on WAFS, thus the need for 20 - 30% disk based buffer. This could be the reason Net App PS advises of lack of significant difference in operational functionality and performance between the 28- and 14-disk RAID DP. At the same time with more disks in a LUN, reconstruction in theory should either consume more CPU cycles or take longer for both orthogonal and diagonal (these are my own terms for the lack of official terminology that I have found so far) parity calculation since there are more spindles and blocks to go through for RAID-DP. So I will expect longer rebuild time for 28-disk set than 14-disk one. At the same time, RAID-DP plus at least a hot spare should decrease the possibility of the need for such reconstruction to practically zero short of catastrophic disasters according to Net App literature, so maybe that's why the difference here is not practically significant. Pou RE: >Imagine my surprise upon discovering that the space reservation for LUN >snapshots is 120%, instead of 20% to 30% for a file system. I think I >understand why. I wonder what the practical field experience is with >trimming that figure down to something the guy who paid for the NetApp will >accept. > >Specifically, if what is on the LUN is a relatively stable NTFS file system, >is "blocks changed" similar enough to "files changed", or are there >"catastrophic events" that go out and touch many disk blocks at once, thus >mandating the huge space reservation? > >If you under-allocate the reservation, then all disk blocks are suddenly >written to, can you configure the NetApp to release the snapshots and commit >the writes, or must it look like a premature disk full condition? > >It seems like a much more economical path will be to ignore the SnapDrive >approach, ignore snapshots, and just use Volume Shadow Copy on the windows >servers hosting the filesystem. This would get my space reservation back >down to 20% to 30%. Any thoughts? > >Oh, a bonus question: I had a NetApp PS guy recommend 28-disk RAID-DP over >14-disk RAID-DP, saying that there is absolutely no significant difference >in re-build time or any other down side. Any thoughts on that? > >Thanks! > > /// Rob >-- >Rob Winters >SAIC, NASA Headquarters ISEM Contract

1 0

Delivery Status Notification
by Mail Delivery Service 07 Jul '05

07 Jul '05

- These recipients of your message have been processed by the mail server: devnull(a)iprimus.com.au; Failed; 4.4.7 (delivery time expired)

1 0

Undelivered mail
by owner-LISTSERV＠LISTSERV.CLASSROOM.COM 07 Jul '05

07 Jul '05

--> Error description: Error-For: NET-HAPPENINGS(a)LISTSERV.CLASSROOM.COM Error-Code: 3 Error-Text: No such list. Error-End: One error reported.

1 0

Re: Returned mail: Data format error
by diederik＠wxs.nl 07 Jul '05

07 Jul '05

I'm not using this mail address anymore. Mail me at d i e d e r i k m A T x s 4 a l l . n l Diederik Meijer

1 0

CIFS/Samba Question
by Scott Sherrill 06 Jul '05

06 Jul '05

I have a 520 filer running 6.1.2 that I am trying to join to my samba domain (3.0.14). I run cifs setup and I get: <snip> CIFS supports three types of user authentication: 1. Windows Domain authentication. 2. Windows Workgroup authentication using the filer's user accounts. 3. /etc/passwd and/or NIS based authentication. What type of authentication will this filer use? [1]: The filer will use Windows Domain authentication. Enter the Windows Domain for the filer []:HPS CIFS - could not determine domain type. Assuming NT4 domain. CIFS - Connecting filer to the NT4 domain. CIFS - Primary Domain Controller must be active for installation. CIFS local server is shutting down... Now the truly sad thing is I did have this filer joined to my domain previously when I was running the beta version of Samba 3, but when I updated this summer, to the latest and greatest no luck. All help is appreciated. Thanks Scott

1 1

Jump to page:

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