toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

Re: Hardware for F330
by sthaug＠nethelp.no 05 May '99

05 May '99

> >- Does anybody know of narrow disks that can be purchased today and which > >will work with 4.3.3D2? (I have come to point that I no longer care if the > >disks are Netapp approved - I just want to have a reasonable chance of the > >disks working.) > > Netapp has other narrow approved disks they can sell you. You should buy > those. We seem to have some conflicting information here. The Norwegian vendor claims that there are *no* narrow disks in the Netapp price list any more - ie. no new narrow disks (of any kind) can be obtained from Netapp. The best that the Norwegian vendor can do is to get us refurbished narrow disks. We are only moderately interested in this... Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Upgrading F630 from DOT 4.3.4D5 to 5.2.2
by Ozzie Sabina 05 May '99

05 May '99

The problem with our Gigabit NIC which my collegue Jay Soffian has mentioned on the list as of late is continuing to bite us with increasing frequency. Because of this, and the conversation on the list that this has been fixed in the 5.x releases, we want to upgrade that filer ASAP. I know that we need to upgrade our filer firmware to 2.1_a1 (we're currently at 1.8_a1). What I have questions about are the firmware revisions on the disks, SCSI adapters, etc.: 1. I'm most concerned about the disks. This is typical of what is reported about our disks from a sysconfig -v: 0: SEAGATE ST19171W 0023 Size=8.3GB (17783112 blocks) I believe that the "0023" is the firmware revision. I know that in some cases, this has to be upgraded along with the machine's firmware. The documentation of what requirements the different DOT versions have for disk firmware is pretty much non-existant on NOW (or I can't find it). Is this something I'd do after upgrading the DOT version (as http://now.netapp.com/knowledge/docs/ontap/rel512/html/upgrade/fb37.htm seems to hint at ), or something I should do beforehand? 2. The SCSI adapter reports "Firmware Version 2.26". Is this something that would need to be upgraded? Is it even something that can be upgraded? 3. In addition, there are firmware versions reported on what I guess are the shelves themselves: EMU 0: P/N 500408 S/N 2550270236 Firmware Rev 1.19 Is this something we can/need to upgrade as well? 4. Other than that, is there anything else that we should check on beforehand? (We more than meet the memory requirements). Thanks, Oz

1 0

RE: A few general bitches and moans.
by Chen, Ray 05 May '99

05 May '99

Re: SCSI protocol efficiency vs. IDE protocol efficiency: A good point. I'll add another one. One has to think beyond the protocol design and also think about protocol implementation. Even with SCSI drives, not all drives are the same. Some do a better job of implementing the SCSI protocol than others. In a prior life, the workstation I/O folks were qualifying low and mid-cost SCSI drives to ship with the workstations instead of the ~$1000 high-end SCSI drives we were putting in our servers. They found that the lower-cost drives couldn't keep up with the higher-cost drives when you tried things like striping a bunch of the drives together on a bus. When you're pushing SCSI hard, all it takes is something simple like the drive not releasing the bus quickly enough and your performance starts to degrade. (And then there are mechanical issues, too, like how well the enclosures damp vibrations so that the drives don't interfere with each other when seeking.) And I don't even want to talk about data corruption under heavy and demanding workloads. Disk drives are no different from any other commodity product. You get what you pay for. The question is whether or not the extra cost is worth the extra benefit. I use el-cheapo EIDE drives on my PC at home. I'm comfortable with that because I know the I/O workload against the drive is going to pretty minimal so the drive should be just fine. If I wanted to do high-performance I/O and I cared about my data, I'd be using expensive server-class disk drives. I would also eat the extra cost if I could afford it and buy qualified drives directly from my system vendor as opposed to from a 3rd-party (either that or make really certain that my drives were running the same firmware revision as the system vendor's drives. Firmware revisions do matter.). Ray Chen rcc(a)netapp.com > The real issue with SCSI vs IDE is bus utilization. > > The SCSI protocols were designed such that the bus could be > freed for other > users, in-between the time the request for data was sent to > the drive, and the > time data was returned. Thus commands for data could be sent > to several > drives, before the time the first drive could reply with the > requested data. > > The IDE protocols were designed for simplicity, it results in > the bus being > allocated to one request, for the duration of a single > request. It wastes time > for simplicity. > > Due to the sporatic disk access behavior of workstations, IDE > and SCSI drive > perform similarly. > > However, do to the much more consistant but varied disk > access of file servers, > the SCSI bus out-performs the IDE bus due to its time > efficiency. The only > mechanism to combat the IDE bus efficiency would be to have > one IDE bus for > each drive. Having one IDE bus per drive, would eliminates > the minor cost > advantage that IDE drives have over SCSI drives. > > Note: Another issue that has not been mentioned, is system > uptime. I have not > seen an IDE drive that has been adapted to support > hotplugging. This is > critical for online maintenance. > > -- > Matthew Lee Stier * Fujitsu Network Communications > Unix Systems Administrator | Two Blue Hill Plaza > Ph: 914-731-2097 Fx: 914-731-2011 | Sixth Floor > Matthew.Stier(a)fnc.fujitsu.com * Pearl River, NY 10965 > > >

1 0

Re: Running CIFS
by Jason D. Kelleher 05 May '99

05 May '99

In message <7F608EC0BDE6D111B53A00805FA7F7DA03A83938(a)TAHOE.netapp.com>, "Muh lestein, Mark" writes: >A mixed qtree already works exactly as you want it to. In a mixed qtree the >security of a file is based on the last security-setting operation. If an A >CL is >set which denies you access, but you still need to do something with a file, >then as root you can change the security on any files/dirs in that qtree (using >chmod, chown, or chgrp), which changes the security-style to UNIX. After that, Ok, so far I've read this alot. No maybe I'm missing something 'cause I get the following errors trying to put it into practice. Here's a test on a directory w/ NTFS permissions allowing only full control to the owner: root@jagular: fs0/home/kelleher [130] # root@jagular: fs0/home/kelleher [130] # ls -ald test_dir drwx------ 2 kelleher users 4096 May 5 14:47 test_dir root@jagular: fs0/home/kelleher [131] # root@jagular: fs0/home/kelleher [131] # ls -al test_dir test_dir: Permission denied total 8 root@jagular: fs0/home/kelleher [132] # root@jagular: fs0/home/kelleher [132] # chown 755 test_dir chown: test_dir: Not owner root@jagular: fs0/home/kelleher [133] # root@jagular: fs0/home/kelleher [133] # chown root test_dir chown: test_dir: Not owner root@jagular: fs0/home/kelleher [134] # I can however su to the UNIX user, chmod it, and then get access to the file: root@jagular: fs0/home/kelleher [134] # su kelleher jagular% jagular% chmod 755 test_dir jagular% jagular% exit jagular% root@jagular: fs0/home/kelleher [135] # root@jagular: fs0/home/kelleher [135] # ls -al test_dir total 72 drwxr-xr-x 2 kelleher users 4096 May 5 14:47 . drwxr-xr-x 25 kelleher users 32768 May 5 15:25 .. -rwx------ 1 kelleher users 0 May 5 14:47 test_file root@jagular: fs0/home/kelleher [136] # root@jagular: fs0/home/kelleher [136] # Is this what you mean? >those files follow regular UNIX rules, which allows root full access. If the >user wants to put an ACL back on afterwards, no problem. > >We have found that using ACLs in a mixed qtree can be helpful in a number of >situations. That's because ACLs are enforced even for NT Admins and root. For >example, we found that some files were being accidentally deleted by root/Admin >users, so we put an ACL on those files which allows only READ access to all >users. That prevents deleting, even by root or NT Admins. Of course, if we >actually want to delete the files we just change the permissions to allow that, >since in a mixed qtree both root and NT Admins have a special dispensation >tochange the permissions. Sounds like the problem is too many people with root/Admin access. Your solution only requires these people to take an extra step (give themselves the permissions) before they accidentally mess something up. If I were you I'd work on getting rid of their access. (Not that it's an easy thing to do.) jason

1 0

RE: Anybody have any comment on this article, as relating to FCAL reliability?
by Chen, Ray 05 May '99

05 May '99

Speaking not as a NetApp employee but rather as a generic filesystem engineer, I'd say that the fundamental point being raised by the article is valid -- "Is Ultra-SCSI an attractive alternative to FC?" However, if I were being polite, I'd also say that the article was somewhat misleading, dishonest, and inaccurate. If I were being blunt and honest, I'd say ... ah, never mind :-). Personally, I do think there's an open issue as to whether Ultra-SCSI is good enough for small servers with reasonable capacity requirements and I suspect that issue will be driven by cost. If Ultra-SCSI adapters and drives have significantly better price/performance ratio, then Ultra-SCSI will win on the low end and FC will win on the high end. If they're about even, I suspect FC will win. Ray > -----Original Message----- > From: Jaye Mathisen [mailto:mrcpu@internetcds.com] > Sent: Wednesday, May 05, 1999 1:26 AM > To: toasters(a)mathworks.com > Subject: Anybody have any comment on this article, as relating to FCAL > reliability? > > > > (Long night tonight waiting on formatting RAID array.s :() > > > > I do not have an FC-AL arrays at this time, although I know it > is something that is rolling out. > > The comments on reliability concern me a bit, at least for > me, my NetApps > have been "plug" and go. > > No muss, no fuss. > > http://www.performance-computing.com/features/9903sra.shtml > > Just curious if people are having trouble with their FC-Al > disks on their > Netapps... >

1 0

RE: Running CIFS
by Muhlestein, Mark 05 May '99

05 May '99

A mixed qtree already works exactly as you want it to. In a mixed qtree the security of a file is based on the last security-setting operation. If an ACL is set which denies you access, but you still need to do something with a file, then as root you can change the security on any files/dirs in that qtree (using chmod, chown, or chgrp), which changes the security-style to UNIX. After that, those files follow regular UNIX rules, which allows root full access. If the user wants to put an ACL back on afterwards, no problem. We have found that using ACLs in a mixed qtree can be helpful in a number of situations. That's because ACLs are enforced even for NT Admins and root. For example, we found that some files were being accidentally deleted by root/Admin users, so we put an ACL on those files which allows only READ access to all users. That prevents deleting, even by root or NT Admins. Of course, if we actually want to delete the files we just change the permissions to allow that, since in a mixed qtree both root and NT Admins have a special dispensation to change the permissions. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Jason D. Kelleher [mailto:kelleher@susq.com] Sent: Wednesday, May 05, 1999 11:13 AM To: Muhlestein, Mark Cc: 'Mark D Fowle'; 'toasters(a)mathworks.com' Subject: Re: Running CIFS In message <7F608EC0BDE6D111B53A00805FA7F7DA03A83931(a)TAHOE.netapp.com>, "Muh lestein, Mark" writes: >There is a document on the NOW site that should help: > >http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/ > >This is primarily for 5.3, but it is also useful for earlier releases. It h >as a >lot of explanations of our approach, a security FAQ, and a bunch of other >(hopefully useful) security-related stuff. > >Mark Muhlestein -- mmm(a)netapp.com This is nice. Especially since the System Administrator's Guide doesn't talk about the usermap.cfg file. (Even though the sample file refers you to it. Just 'cause the filer is _usually_ simple to setup and maintain is no excuse for poor/missing documentation.) I've been trying to setup access to a "mixed" quota tree such that no NT admin as access to it, but a UNIX root user can over-ride NTFS permissions. I know this sounds weird, but there are _way_ too many NT admin accounts floating around. That's why I don't want NT admins to have access to (read: be able to screw up) the filer. But because I'm one of those "pesky UNIX admins" I can't get and admin account, so I need root to be able to over-ride NTFS permissions. Is this even possible? I'm not having much luck. jason >-----Original Message----- >From: Mark D Fowle [mailto:Fowle_Mark_D@CAT.com] >Sent: Wednesday, May 05, 1999 6:58 AM >To: toasters >Subject: Running CIFS > > >I am trying to set up a mixed environment on 2 720's. I have created a test > share and a usermap.cfg file that has >domain\user unix-user mapped out. My problem is that only 2 our 7 peo >ple > can get access to the share. What >else might I be missing? > >Mark Fowle >Caterpillar - BCP >fowelmd(a)cat.net

1 0

Re: Running CIFS
by Jason D. Kelleher 05 May '99

05 May '99

In message <7F608EC0BDE6D111B53A00805FA7F7DA03A83931(a)TAHOE.netapp.com>, "Muh lestein, Mark" writes: >There is a document on the NOW site that should help: > >http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/ > >This is primarily for 5.3, but it is also useful for earlier releases. It h >as a >lot of explanations of our approach, a security FAQ, and a bunch of other >(hopefully useful) security-related stuff. > >Mark Muhlestein -- mmm(a)netapp.com This is nice. Especially since the System Administrator's Guide doesn't talk about the usermap.cfg file. (Even though the sample file refers you to it. Just 'cause the filer is _usually_ simple to setup and maintain is no excuse for poor/missing documentation.) I've been trying to setup access to a "mixed" quota tree such that no NT admin as access to it, but a UNIX root user can over-ride NTFS permissions. I know this sounds weird, but there are _way_ too many NT admin accounts floating around. That's why I don't want NT admins to have access to (read: be able to screw up) the filer. But because I'm one of those "pesky UNIX admins" I can't get and admin account, so I need root to be able to over-ride NTFS permissions. Is this even possible? I'm not having much luck. jason >-----Original Message----- >From: Mark D Fowle [mailto:Fowle_Mark_D@CAT.com] >Sent: Wednesday, May 05, 1999 6:58 AM >To: toasters >Subject: Running CIFS > > >I am trying to set up a mixed environment on 2 720's. I have created a test > share and a usermap.cfg file that has >domain\user unix-user mapped out. My problem is that only 2 our 7 peo >ple > can get access to the share. What >else might I be missing? > >Mark Fowle >Caterpillar - BCP >fowelmd(a)cat.net

1 0

RE: Running CIFS
by Muhlestein, Mark 05 May '99

05 May '99

There is a document on the NOW site that should help: http://now.netapp.com/knowledge/docs/olio/guides/53_troubleshooting/ This is primarily for 5.3, but it is also useful for earlier releases. It has a lot of explanations of our approach, a security FAQ, and a bunch of other (hopefully useful) security-related stuff. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Mark D Fowle [mailto:Fowle_Mark_D@CAT.com] Sent: Wednesday, May 05, 1999 6:58 AM To: toasters Subject: Running CIFS I am trying to set up a mixed environment on 2 720's. I have created a test share and a usermap.cfg file that has domain\user unix-user mapped out. My problem is that only 2 our 7 people can get access to the share. What else might I be missing? Mark Fowle Caterpillar - BCP fowelmd(a)cat.net

1 0

Re: NetApp Warranty
by sirbruce＠ix.netcom.com 05 May '99

05 May '99

On 05/05/99 11:11:34 you wrote: >Is there a way to purchase this level of support? We have some >non-critical F540s that _if_ they fail, I'd like to get them fixed, >but it doesn't have to happen same day and I don't have a problem >paying for the parts. > >The only hardware support I'm aware of covers cost of repair, so it is >priced accordingly. I'm looking for a more cost-effective level of >support on these non-critical filers. Sorry... I should have said that I'm not speaking from authority here; I was just trying to reconcile what the rep supposedly said with what the web site supposedly said. Either could be wrong and there really could be 1 year of hardware support. As to if you can just purchase software/phone support for additional years, I don't know, but I would assume you can. Surely Netapp wants you to buy more support, yes? I suppose it's possible that any extension includes hardware support too. Bruce

2 1

Re: F540 F520...
by sirbruce＠ix.netcom.com 05 May '99

05 May '99

On 05/04/99 23:43:32 you wrote: >Hmmmm, I have an F540 filer. I'm sure it's a 540. Positive. Says 540 on >it somewhere. I'm sure. > >No such thing as a 540 on www.netapp.com. There's a 520, which looks >pretty darn similar. Can I just s/540/520/g, and be a happy camper? Note to Netapp - All filer models, no matter how old, should still have information accessible off the web site. The price of keeping this information on there is minimal. By not keeping this information someone is just going to wind up doing it third-party with some sort of filer FAQ. Note to Jaye - If you actually have a older file model like the F540, you will need access to more than just general information. Most of the technical details *should*, in an ideal world, be available off now.netapp.com. Have you tried looking there? Bruce

2 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