toasters

toasters@lists.teaparty.net

3 participants
13514 discussions

RE: SNMP traps (+ other monitoring issues)
by Hackworth, Brian 06 May '99

06 May '99

: The [miscGlobalStatus] MIB description is a little woolly however : : Is there a more detailed explanation of what event will : trigger what status? We were intentionally vague in describing the status, to allow us the flexibility to change the algorithm in future releases. The current algorithm is to report "critical" if there are any failed fans, power supplies, or if the chassis temperature is too hot. It reports "nonCritical" if there are any failed disks, or if any volume is 99% full. : However, when doing : the same power supply pull, we only get a message in the : 'info' file. I filed a bug report (14576) on this one. Power supply failures are more serious than "info"; we need both to get the severity right, and to make it consistent across the various flavors of reporting.

4 4

Re: Hardware for F330
by sirbruce＠ix.netcom.com 06 May '99

06 May '99

On 05/05/99 23:35:44 you wrote: >> 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... Sorry, I was going by what George Kahler said about them being replaced with the Fujitsus. My main point was that they don't *have* to be the same vendor of disks that you already have, which seemed to be a concern of yours. I suppose your vendor may be right bout the price list, although I find it pretty suprising that Netapp wouldn't find a replacement or wouldn't keep enough in stock to cover existing customers. Bruce

1 0

Re: Raid Scrub errors
by sirbruce＠ix.netcom.com 06 May '99

06 May '99

On 05/05/99 13:01:00 you wrote: > On Thursday I called back (having had second thoughts, but also having >been out of town), and asked for further clarification. In particular: > > (1) How can there be a parity inconsistency w/o some sort of disk error? Short of a software error in calculating parity or a similar write problem, there probably isn't a way. > If there was a hard error why is there no log entry for same? > If there was no error then how can the parity be wrong? A variety of ways. Two immediately spring to mind: 1. The block with the error did not go bad until after data had been written to it, but before data was read from it. 2. The drive thought the data was written correctly but was incorrect. 3. The drive thought the data was read correctly but was incorrect. > Disk_stat reports that since the filer was booted (2 months ago) > there have been 3 recovered errors. However I would not expect > a recovered error to produce a parity inconsistency, since the > correct data should have been recovered. I've usually seen parity inconsistencies as a result of an improper shutdown. However these are repaired immediately upon reboot. > (2) How does the system know that the error is in the parity block and > not in a data block? The response that we received from netapp > support indicated that it may have in fact rewritten a data block, > but logged it as a parity block. I don't think it may have in fact rewritten a data block (I could be wrong). Rather, they read all the data, and the parity block was inconsistent with the data, so they rewrote the parity information. I'm not sure if there is any way to know for sure that the parity is actually correct and it is the data block that is wrong. > In either case how can they > determine where the error is if a parity inconsistency occurs w/o > a corresponding media error? I think you're basically saying the same thing here; the problem could be in the data block, not the parity block. In any case, assuming it is parity then they can determine which block goes on that stripe. > (3) How can we (as end users) map the stripe number to disk blocks, and > then further to the data and/or filesystem info (Inode) blocks. I don't think there's any way without an expensive scan of various metadata files. However, it would be nice if every such disk message contained such information. > (4) Short of wacky how can we be really sure of our filesystem/data integrity? No way, but if the filesystem is fine then wacky won't tell you if the data is corrupt either. If the block of zeroes got all flipped to ones, and the parity was rewritten to accomodate that, there's no way to know that it happened unless you happen to know the block should be otherwise in a given file. > What I got back was (in essence) don't worry, everything is fine and >some canned (RAID for dummies) answers about why raid scrubbing is run >and a brief synopsis of the error messages. >Except for items 3 and 4... > >(3) You can't, not really. I believe this and really didn't really expect > any other answer, just wishful thinking. > >(4) Use wacky and don't forget you have to take the filer out of service > and it can take up to 10 hours to check the filesystem [for large values > of filesystem]. Or upgrade to 5.3 and it only takes about a hour. > > > Could someone give me a pointer to a document that answers questions 1 >and 2? Or a brief answer to the group? Does anyone else get these >messages? Yep. The bottom line is - don't worry about it, as they are probably of no consequence. If you continue to get inconsistent parity, it could be a pointer to some other problem. Bruce

1 0

Re: A few general bitches and moans. (turning back into what would peoplr like in a very-low-end filer?)
by mds＠gbnet.net 06 May '99

06 May '99

On Wed 5 May, 1999, tkaczma(a)gryf.net wrote: > > The price differences between SCSI and IDE are not that significant > anymore, but I was wondering why someone didn't come up with and IDE Wrongo. SCSI is still way more expensive than EIDE. It's just the EIDE disk are meant for cheap-and-cheerful low-requirements users and SCSI occupies the middle-high disk market. But we're talking about a VLE filer here, so we can make different assumptions, maybe. > appliance. The argument that I would come up with is that you can only > have 2 devices on one bus, much too few for a RAID 5 set. This also Bzzt. Irrelevant, add more busses because EIDE busses are also quite cheap. > applies to your request for a 3 disk appliance. The power of striping > comes from the number of drives. The more drives you add the smaller the > parity overhead. With 3 drives 33.3 ... % is "wasted" on parity. With 14 > drives the "waste" goes down to about 7%. Parity overhead in terms of space maybe, but computation goes up linearly at best and might go up higher (reconstructing blocks from parity when a disk blows). Tradeoff time. > > > (And no, I'm not interested in the philosophical war of IDE vs SCSI. > > Fact: IDE is currently cheaper than SCSI. Fact: I want this box to be > > cheap. Check and mate. :)) I agree. But I'd do things slightly differently. > No mate, and probably not even check. SCSI drives are not THAT much more > expensive anymore. You must remember that you can have only 2 IDE drives Oh yeah they are. Here in the UK I spent 360quid on an UW 9GB Seagate (end user price) where a 10GB UDMA EIDE drive cost 190quid (end user price). > on the bus, among other limitations. The money you save in drives will > probably be made up in the complexity of the controllers and software. > Everything costs money, the drives are only a fraction of the cost. I've seen PCI-EIDE controllers advertised for about the same as SCSI host adapters, but I'd put them together on the motherboard with an integral network interface (10/100Base-TX). Performance on the SCSI is a bit better but not *that* much better. I'd bet that a good board designer could easily put 3 EIDE controllers on a PCI bus, giving you (4 devices per EIDE controller, last time I counted) 12 disk connections. The motherboard could have the EIDE connections, one cheap integral SCSI host adapter for tapes, one network interface and one set of battery-backed memory (just back up all memory - don't have separate NVRAM, we're talking small and compact here). Given a K6-3 or Celeron and DOT this baby would cost quite a bit less in parts costs than the latest and greatest filers, but wouldn't be an embarrassment to NetApp (of that I'd be quite quietly confident). You could make the mboard quite small and make the whole thing into a single rack-mount shelf/deskside tower style thing, with the disks presented at the front and the power-supply, motherboard access, serial-line, floppy drive, network connector and SCSI connector round the back. >-- End of excerpt from tkaczma(a)gryf.net

4 3

TEST ONLY - DELETE THIS!
by Whitman, Michael 06 May '99

06 May '99

Just a one time TEST -----Original Message----- From: tkaczma(a)gryf.net [mailto:tkaczma@gryf.net] Sent: Wednesday, May 05, 1999 8:00 AM To: toasters(a)mathworks.com Subject: Re: A few general bitches and moans. I agree with you on many points, but ... On Tue, 4 May 1999, Jaye Mathisen wrote: > o CIFS support has got some big holes. > > - The inability to belong to multiple domains. > Not all my domains trust each other. Oops, now the filer > is essentially unusable for some of them. Can NT boxes do this? > - Even the ability to have a different network interface belong to a > different domain would be useful. Not a panacea, but at least > useful. Can NT boxes do this as well? > o The general suckiness of NFS now being insufficient to backup the filer > with CIFS. Probably not a solveable problem, but it still sucks. If NFS sucks so much use CIFS only. Apparently they both suck in some ways that are different from another because you ARE using them to complement each other. > Heck, I saw some very scary numbers from consensys for their IDE raid > product, use IDE drives instead of scsi in this bad boy, and cut them > costs down. WD makes 7200 RPM drives now, at 18GB's a pop, and 5 of 'em > fit in a 3 high bay. The price differences between SCSI and IDE are not that significant anymore, but I was wondering why someone didn't come up with and IDE appliance. The argument that I would come up with is that you can only have 2 devices on one bus, much too few for a RAID 5 set. This also applies to your request for a 3 disk appliance. The power of striping comes from the number of drives. The more drives you add the smaller the parity overhead. With 3 drives 33.3 ... % is "wasted" on parity. With 14 drives the "waste" goes down to about 7%. > (And no, I'm not interested in the philosophical war of IDE vs SCSI. > Fact: IDE is currently cheaper than SCSI. Fact: I want this box to be > cheap. Check and mate. :)) No mate, and probably not even check. SCSI drives are not THAT much more expensive anymore. You must remember that you can have only 2 IDE drives on the bus, among other limitations. The money you save in drives will probably be made up in the complexity of the controllers and software. Everything costs money, the drives are only a fraction of the cost. > Nothing like not having the right serial cable wired up, and > having to type all those stupid commands by hand when you make a booboo, > and plus the grief of having to boot off two floppies. Well, instead of Flash cards carry a serial cable and write macros in your terminal program so you don't have to type commands by hand. Try a terminal program like Telemate or Telix. I assume you're a PC user. > o Or add an option to read rc from disk 3 on a DOS formatted floppy. But it reads it from the drive array, so what's the point? > o Fine, you don't want to use something like PCMCIA cards, then since > Netapp only allows its network cards, allow tftp of the rc file from > one of the interfaces. Why? You should have it on your drives. Besides, you can upload it using the console connection. > I guess the CIFS stuff is what's torquing me off right now the most, I > don't want to have to slap a bunch of storage on some NT boxes when I have > this filer sitting there perfectly suited (in theory) to do the job..., > and I refuse to purchase 1 filer per domain. Can your NT boxes be each in two different domains at the same time? Talk to B. G. III for using such a decrepid protocol as lanmanager. Tom

1 0

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

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