toasters

toasters@lists.teaparty.net

2 participants
13529 discussions

Re: snapshot and df does not match?
by sirbruce＠ix.netcom.com 25 Nov '98

25 Nov '98

On 11/17/98 09:26:50 you wrote: > >Hi All, > >Eventhough my snap list shows less than 100%, Why my df command shows >130%? > >Is there any hidden files that I need to delete? >How does this sanp list matches with df's capacity? The percentages in snap list have always been a little confusing. I think they give you the amount of space the snapshot takes up relative to the total disk space used on the filer, and the total disk space available on the filer. Neither of which would relate to the space you've chosen to reserve for snapshots. I could be wrong, though; I don't have a man page handy and frankly, I've always pretty much ignored the values in snap list as they didn't really contain any useful information to me. All the 130% means is that you've exceeded your snapshot reserve. You have a couple of choices: 1. If you think this is typical and don't mind the space usage, increase your snapshot reserve. 2. If you think this is typical and DO mind the space usage, you will need to change your snapshot schedule to exclude, for example, the weekly snapshots. 3. If you think this is not typical, and you simply had a bunch of stuff deleted this week, you can either live with it for a day or two until it's deleted "naturally", or delete it manually yourself. There are some other things you could do too, but those are the main options. Bruce

3 2

FW:
by Barden, Des [HAL02:8883:EXCH] 24 Nov '98

24 Nov '98

subscribe Des Barden Team Leader Unix/LAN IS Regional Services (Harlow) Esn: 742-5856 > -----Original Message----- > From: Barden, Des [HAL02:8883:EXCH] > Sent: 24 November 1998 10:03 > To: 'toasters(a)mathworks.com' > Subject: > > Subscribe > > > Des Barden > Team Leader Unix/LAN > IS Regional Services (Harlow) > Esn: 742-5856 >

1 0

RE: F630 grinds to a halt daily after update to 5.1.2?
by Matt Stein 23 Nov '98

23 Nov '98

> Netapp's given me 5.1.2P1 in hopes of it fixing things. Luckily for us, > the box needed it's nightly reboot *after* getting that on there. I'll > let you all know if this fixed things. Nope, 5.1.2P1 also has this problem. We're downgrading back to 5.0.1D4. They've been no help yet on the core files, so I think that's our best bet. -- mat.

1 0

RE: NetApp soon to be user
by sirbruce＠ix.netcom.com 21 Nov '98

21 Nov '98

On 11/20/98 09:45:21 you wrote: > >Rick, > >We have run into a couple of significant issues with CIFS that may, or may >not, be relevant. First issue is: >Well, it turns out that there is some "feature" in NT that causes IIS to >hang if oplocks are on. To me, this is an issue with IIS. If you use IIS, you'll get this same problem when talking via CIFS to another NT box. The answer is to not use IIS (or NT entirely), or, as you point out, turn off oplocks. >The second issue is a hardcoded limit in the filer that does not allow for >more then slightly more then 65K of directories in one directory tree. Most >folks wouldn't run into this, but we create an NT folder for every user who >uses our site to build their own web pages. This limit is not documented >(there is a limit of approx. 300,000 file sin one directory and a maxfiles >limit that is dependent on number/capacity of disk drives that are >documented). This does bother me. I don't know when the limit appeared, as it doesn't seem to be a part of the WAFL design, and slipping it in through a "backdoor" without mentioning it is disturbing. As you mentioned, there is a limit on the number of files, or actually directory entries, in one directory, which was set as a matter of performance; however, there is a maxdirsize parameter you can set to increase it. Directories should naturally be treated the same way, so if you're correct that some other limit has been added (maybe it was always there and I just didn't know), it would be nice if someone from Netapp could address why this limit exists and if/when it will be lifted and/or made user-configurable. Mind you, if you tried to put 65K directories in your NT or UNIX server, you will run into a severe performance degredation. You really should look into setting them in deeper subdirectories. This appears to be another reason NOT to use IIS.... Bruce

2 1

F630 grinds to a halt daily after update to 5.1.2?
by Matt Stein 21 Nov '98

21 Nov '98

I know this isn't a support channel, but Netapp's not been useful at all, so what the heck: I have an F630 that's run well enough for five months. On Sunday we upgraded our filer to 5.1.2 from 5.0.1d4 at the suggestion of our Netapp SE. Since then, it's come grinding to a halt each day. NFS access starts getting really slow, and eventually completely unresponsive. Network activity is not high. sysstat shows that cpu, disk, and net are all getting lower and lower as clients start dropping their mounts. Things do not improve until eventually we reboot it. The telnet interface is fine and responsive all the way through. Netapp's support has asked for crash dumps, etc., but nothing's helped, and we're heading into a weekend. They also recommended *not* downgrading back to 5.0.1d4. Apparently 5.1.2 has bug fixes that we require(news to me). Has *anyone* seen this? Suggestions? Thoughts? Hitz voodoo solutions welcome. :) -- mat.

2 2

Re: F630 grinds to a halt daily after update to 5.1.2?
by sirbruce＠ix.netcom.com 21 Nov '98

21 Nov '98

On 11/20/98 20:38:35 you wrote: >> this happens. After eliminating that, my best advice would be to change >> the client mounts to use different NFS protocols... UDP instead of TCP, >> and/or v2 instead of v3. Doing so may prevent or may make it less >> likely that you'll 'tickle' the Netapp bug. Also, check out the different > >Well, we have mostly v2 clients, but the v3 tcp client and the v3 udp >clients have all seen exactly the same behaviour. No, you misunderstand. The v3 clients or the tcp clients could be *causing* the bug to occur in the netapp, which then consumes resources to kill all clients. So, changing the clients to a different mechanism may avoid the problem. Get it? Bruce

2 1

Re: F630 grinds to a halt daily after update to 5.1.2?
by sirbruce＠ix.netcom.com 21 Nov '98

21 Nov '98

On 11/20/98 17:57:42 you wrote: > > >I know this isn't a support channel, but Netapp's not been useful at all, >so what the heck: > >I have an F630 that's run well enough for five months. On Sunday we >upgraded our filer to 5.1.2 from 5.0.1d4 at the suggestion of our Netapp >SE. > >Since then, it's come grinding to a halt each day. NFS access starts >getting really slow, and eventually completely unresponsive. Network >activity is not high. sysstat shows that cpu, disk, and net are all >getting lower and lower as clients start dropping their mounts. Things do >not improve until eventually we reboot it. The telnet interface is fine >and responsive all the way through. While many things could cause this, this sounds to me like a classic resource contention issue, where the filer accumulates more and more operations that are waiting on a blocked process (like a raid stripe being written out), and eventually it can't do anything more. This sort of thing can also happen at a higher level in the networking code. There have certainly been bugs that have exhibited the symptoms you describe in the past. >Netapp's support has asked for crash dumps, etc., but nothing's helped, >and we're heading into a weekend. They also recommended *not* downgrading >back to 5.0.1d4. Apparently 5.1.2 has bug fixes that we require(news to >me). > >Has *anyone* seen this? Suggestions? Thoughts? I'm surprised the crash dumps haven't helped. My first recommendation would be to downgrade. The "apparently" doesn't cut it; either they can tell you specifically what was fixed and you can assess the risk of downgrading, or you should just do it anyway. But if doing so would be a big problem according to Netapp, then you need to look for other solutions. If that is the case, I assume you've already looked at the obvious culprits like making sure you're not doing a dump, restore, etc. when this happens. After eliminating that, my best advice would be to change the client mounts to use different NFS protocols... UDP instead of TCP, and/or v2 instead of v3. Doing so may prevent or may make it less likely that you'll 'tickle' the Netapp bug. Also, check out the different interfaces you have... perhaps switching from ATM to Gigabit, or from Gigabit to 100tx, may alleviate the problem. (If you can check mounts through each interface when the "slowdown" occurs, you may be able to confirm a particular interface as the culprit.) Bruce

2 1

RE: NetApp soon to be user
by Sam Schorr 20 Nov '98

20 Nov '98

Rick, We have run into a couple of significant issues with CIFS that may, or may not, be relevant. NT uses a thing called oplocks (opportunistic locking) as a "performance enhancement". The filer supports this method of locking. In our environment, we do not have individual user shares - we have a number of NT servers running Microsoft's IIS. Thus our Internet servers (IIS) receive both PUT (file write) and GET (file read) requests through the internet that come in as anonymous users. IIS has several NT user accounts that it uses to make the corresponding access calls. In our case, those calls are to create directories and files which we put on a 740. Well, it turns out that there is some "feature" in NT that causes IIS to hang if oplocks are on. Essentially, somewhere in the SMB traffic that is hitting a shared file from multiple "users", if the number of simultaneous requests is large, NT timeouts which hangs the user - in our case, an entire IIS server. Doing a CIFS TERMINATE on that server can free it, but this is a horrible practice. The workaround is to turnoff oplocks and control file access through application logic. The second issue is a hardcoded limit in the filer that does not allow for more then slightly more then 65K of directories in one directory tree. Most folks wouldn't run into this, but we create an NT folder for every user who uses our site to build their own web pages. This limit is not documented (there is a limit of approx. 300,000 file sin one directory and a maxfiles limit that is dependent on number/capacity of disk drives that are documented). The last issue is multi-homing on an NT domain environment. If you want more info on that, let me know - it doesn't sound like you would run into this. Sam Schorr Homestead Technologies ph: (650) 549-3152 fax: (650) 364-7329 sschorr(a)homestead.com Don't just build a home page...build a Homestead!! http://www.homestead.com -----Original Message----- From: Berkenbush, Richard E. [mailto:BERKENBUSH@pcmail.systems.gec.com] Sent: Friday, November 20, 1998 7:05 AM To: 'toasters(a)mathworks.com' Subject: NetApp soon to be user Hello all, I am in the process of purchasing a 720 to be used for TDM storage for SDRC in a mixed UNIX and NT environment. We also would like to consider its use for PDM storage using Sherpa and Oracle. Our intentions are to pilot the 720 with SDRC and phase in the PDM data base for pilot purposes only. Should this be successful, we would then purchase a higher end model such as the 740 or 760. Also we have a need to consider an enterprise wide data storage solution which would involve UNIX and NT data up to 3500 G. Has anyone out there had any bad experience with the Network Appliance products that I should be aware of? End Thank you, Rick Berkenbush Marconi Aerospace Systems Inc.

1 0

NetApp soon to be user
by Berkenbush, Richard E. 20 Nov '98

20 Nov '98

Hello all, I am in the process of purchasing a 720 to be used for TDM storage for SDRC in a mixed UNIX and NT environment. We also would like to consider its use for PDM storage using Sherpa and Oracle. Our intentions are to pilot the 720 with SDRC and phase in the PDM data base for pilot purposes only. Should this be successful, we would then purchase a higher end model such as the 740 or 760. Also we have a need to consider an enterprise wide data storage solution which would involve UNIX and NT data up to 3500 G. Has anyone out there had any bad experience with the Network Appliance products that I should be aware of? End Thank you, Rick Berkenbush Marconi Aerospace Systems Inc.

2 1

subscribe toasters
by Ståle Aartun 20 Nov '98

20 Nov '98

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