toasters

toasters@lists.teaparty.net

1 participants
13528 discussions

what data is being used?
by Daniel Quinlan 26 Jun '98

26 Jun '98

Are there any tools to gauge NFS load (reads, writes, NFS ops, whatever), perhaps on a quota tree or directory level. Why would I want to know such a thing? Say I have an 200GB F540 filer with two large trees. And I just purchased a 200GB F630 filer. I want to move one of the trees, but not both. I want to move the busier one, not the other one. There are some basic things I've been looking at in the above situation, but maybe someone here knows about a better method/technique/tool. I hoping someone will mention such an obvious solution that I'll be glad I didn't mention what sort of thing I've been doing. :-) - Dan

1 0

Re: Making CIFS hidden files from unix
by Daniel Quinlan 26 Jun '98

26 Jun '98

Steve Losen <scl(a)sasha.acc.virginia.edu> writes: > When we add new user accounts to our NetApp, we don't know if the owner > will use CIFS, unix, or both. (We use unix file protection semantics.) So > we are going to put unix dot files in the new home directory. But it > would be nice to prevent or discourage CIFS users from deleting them -- in > particular the .forward file. We were thinking that if we could make the > dot files "hidden" and "system", that that would help, even though CIFS > users can override and see hidden files if they want. > > [...] > > Is this overly complex? Is there a simpler way? Yes. I think so. A simpler solution is to configure sendmail to look for .forward files somewhere other than home directories. We put all .forward files (as well as procmail stuff) in a centralized location (physically on the mail server). For example, /local/mail/<username>/.forward /local/mail can be (auto)mounted to allow editing on clients. You can put symbolic links in user home directories, and it won't matter if people delete the links. This also allows for faster and more reliable mail delivery since the .forward files are now located on the mail server. You don't need to worry about someone's home directory being unavailable. - Dan

1 0

Making CIFS hidden files from unix
by Steve Losen 25 Jun '98

25 Jun '98

When we add new user accounts to our NetApp, we don't know if the owner will use CIFS, unix, or both. (We use unix file protection semantics.) So we are going to put unix dot files in the new home directory. But it would be nice to prevent or discourage CIFS users from deleting them -- in particular the .forward file. We were thinking that if we could make the dot files "hidden" and "system", that that would help, even though CIFS users can override and see hidden files if they want. Our account adding software is on unix, and I think I have a way to do what I want. I'll make a "new user" prototype directory and set the unix permissions on the dot files, then get on a PC and set "hidden" and "system" on them. I'll use the netapp dump utility to dump the prototype dir to a file. When I create a user, I'll use the netapp restore to bring back the prototype directory, chown the files to the new user, overwrite the .forward, and mv the prototype into place as the user's home dir. This preserves any CIFS hidden attributes, I presume. It looks like restore always restores back to the original location of the dumped directory. Is it possible to get restore to restore elsewhere? We're running NetApp Release 4.3.1. Is this overly complex? Is there a simpler way? Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

2 1

Re: always safe to delete dump snapshots?
by Paul Albers 25 Jun '98

25 Jun '98

Dan and Bruce, This was bug #650 and has been fixed in all the OnTap OS releases since 4.3x. The request to delete this snapshot_for_dump.<num> will fail. -paul At 08:42 AM 6/25/98 -0500, you wrote: >On 06/25/98 01:38:27 you wrote: >> >>Is it always safe to attempt to delete a snapshot_for_dump.<num>? >> >>Another way to phrase my question -- it will *never* succeed when a >>dump is in progress, right? >> >>Yes, I know it's supposed to not succeed, but since I'm writing a >>program to automatically delete snapshots, I'm exercising more >>paranoia than usual. > >Well, there USED to be an old bug that's been around since the >beginning that trying to delete one while a dump was in progress >would crash the filer. This bug was even mentioned in bold >letters in the admin guide (either in the snapshot or the dump >sections). Assuming they've fixed it to do what you say, then >you're correct. > >If they haven't, then you don't want to automatically delete those >files, unless you have some way of knowing ahead of time that they >are no longer associated with a dump process (say, one that failed >in some ungraceful way). Since this usually happened because of a >crash, one thing I used to do was include an automatic snap delete >at the end of the rc file to delete the snapshot_for_dump after the >filer had started up. The appearance of the snapshot_for_dump.n >mechanism broke that... I made the suggestion that having the OS >automatically delete those might be a good idea, but on the other >hand it might not... the user may really want to restart the >backup off that old image, rather than taking a new one right at >that moment. > >Bruce > > >

1 0

Re: always safe to delete dump snapshots?
by varun＠netapp.com 25 Jun '98

25 Jun '98

> From sirbruce(a)ix.netcom.com Thu Jun 25 06:45:51 1998 ... > Well, there USED to be an old bug that's been around since the > beginning that trying to delete one while a dump was in progress > would crash the filer. This bug was even mentioned in bold > letters in the admin guide (either in the snapshot or the dump > sections). Assuming they've fixed it to do what you say, then > you're correct. > This is bug 650. Fixed since release 4.2. You should get a "Snapshot in use by dump." message if you attempt to delete a snapshot that's being dumped.

1 0

Re: always safe to delete dump snapshots?
by sirbruce＠ix.netcom.com 25 Jun '98

25 Jun '98

On 06/25/98 01:38:27 you wrote: > >Is it always safe to attempt to delete a snapshot_for_dump.<num>? > >Another way to phrase my question -- it will *never* succeed when a >dump is in progress, right? > >Yes, I know it's supposed to not succeed, but since I'm writing a >program to automatically delete snapshots, I'm exercising more >paranoia than usual. Well, there USED to be an old bug that's been around since the beginning that trying to delete one while a dump was in progress would crash the filer. This bug was even mentioned in bold letters in the admin guide (either in the snapshot or the dump sections). Assuming they've fixed it to do what you say, then you're correct. If they haven't, then you don't want to automatically delete those files, unless you have some way of knowing ahead of time that they are no longer associated with a dump process (say, one that failed in some ungraceful way). Since this usually happened because of a crash, one thing I used to do was include an automatic snap delete at the end of the rc file to delete the snapshot_for_dump after the filer had started up. The appearance of the snapshot_for_dump.n mechanism broke that... I made the suggestion that having the OS automatically delete those might be a good idea, but on the other hand it might not... the user may really want to restart the backup off that old image, rather than taking a new one right at that moment. Bruce

1 0

always safe to delete dump snapshots?
by Daniel Quinlan 25 Jun '98

25 Jun '98

Is it always safe to attempt to delete a snapshot_for_dump.<num>? Another way to phrase my question -- it will *never* succeed when a dump is in progress, right? Yes, I know it's supposed to not succeed, but since I'm writing a program to automatically delete snapshots, I'm exercising more paranoia than usual. Thanks. - Dan

1 0

NFS performance question
by Alexei Rodriguez 24 Jun '98

24 Jun '98

Hey folks. I have a PII-400 machine running Solaris x86 2.6 which is using the dnet0 interface (built in interface on the motherboard) for the mounts. The mount that is giving us some problems is off of a f630 running 4.3.4D5 over gigabit. The PII has a 10/100 interface (adaptec I believe). The behavior I am seeing is as follows: - large file ops (like cat /dev/zero > foo) are bursty - iostat shows the filer 100% busy but the filer is not breaking a sweat. The stats: root@sealion:~/ # iostat -xn 2 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 fd0 1.9 0.6 18.5 4.0 0.0 0.0 17.8 10.5 0 2 c0t0d0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 4.5 0 0 maytag:/home 0.0 0.0 0.0 0.0 0.0 0.0 0.0 27.9 0 0 maytag:/export/cim 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/httpd 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/logarchive 0.0 41.8 0.0 331.8 660.8 3.1 15796.9 74.4 20 62 whirlpool:/export/c0 0.0 0.0 0.4 0.0 0.0 0.0 0.1 94.9 0 0 maytag:/export/depot/col.x86-solaris26 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sealion:vold(pid261) extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t0d0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/home 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/cim 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/httpd 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/logarchive 0.0 0.0 0.0 0.0 0.0 4.0 0.0 0.0 0 100 whirlpool:/export/c0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/depot/col.x86-solaris26 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sealion:vold(pid261) extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t0d0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/home 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/cim 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/httpd 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/logarchive 0.0 0.0 0.0 0.0 0.0 4.0 0.0 0.0 0 100 whirlpool:/export/c0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 maytag:/export/depot/col.x86-solaris26 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sealion:vold(pid261) ^C root@sealion:~/ # root@sealion:~/ # nfsstat -m /content from whirlpool:/export/c0 Flags: vers=3,proto=udp,sec=sys,hard,intr,link,symlink,rsize=8192,wsize=8192,retrans=5 Lookups: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms) Reads: srtt=2 (5ms), dev=2 (10ms), cur=1 (20ms) Writes: srtt=7 (17ms), dev=3 (15ms), cur=2 (40ms) All: srtt=7 (17ms), dev=3 (15ms), cur=2000 (40000ms) I was just wondering if anybody else had seen this sort of behavior on their end. I suspect this is hardware on my end (cable, card, etc) but swapping has not helped. Thanks. Alexei

1 0

Re: 'quota resize' - any way around it ?
by sirbruce＠ix.netcom.com 22 Jun '98

22 Jun '98

On 06/22/98 13:44:18 you wrote: >- just accept the fact that NetApp doesn't consider this wish to very >important and turn the quotas on/off as often as is feasible. So long as once/day was acceptable, this is what I would do. But if not, then... >- preload the /etc/quotas file with entries for all possible UIDs, then >just change the quota as they request it. This way the /etc/quotas will >always be the same length and contain the same number of users. ... this is probably what I would do. Assuming that's not too many UIDs that it's computationally expensive. Depending on how many users I expect to reasonably have, I might start with a smaller number and then add new ones in blocks ahead of their actual use (and then do a quota off/on that night). Bruce

1 0

Re: ATM and Fore SPANS failover
by Barbara Naden 18 Jun '98

18 Jun '98

At 10:35 PM 6/17/98 -0400, David B. Ritch wrote: >Actually, etherchannel is supported by Sun, Auspex, and Cisco. There >may be others, but those are the one that I know of. > >David Ritch > EtherChannel support is in the DATAOntap 5.1 release and is currently in external test. Barbara Naden >Alexei Rodriguez wrote: >[...] >> Sounds like etherchannel... I think Alteon was trying this with their Gigabit >> stuff; unfortunately, no other vendor supports this feature. > >

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