toasters September 2000

toasters@lists.teaparty.net

122 participants
161 discussions

quad ethernet -> gigabit on Cisco switches
by Todd C. Merrill 06 Sep '00

06 Sep '00

We are considering moving our F740 and F760 toasters from quad 100-Mbit ethernet EtherChannel'ed on a Cisco 5500 switch to the gigabit NICs on a new Cisco switch, a 6509. We're doing this 'cause: 1. We need more ports. Period. 2. The 6509 has a higher density of ports and gig ports. 3. The gigabit NICs are supposedly much faster, and you can offload the checksum processing from the main CPU to the gigabit card. (We're not even close to saturating the quad link now; I'm just talking latencies. Plus, we beat the crap out of our toasters; if the CPU can do less overhead and more data serving, I want it.) Anybody have any experience with the 6509 and NetApp's gigabit cards? Just want to assuage our concerns before placing the PO's. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

3 2

Re: quad ethernet -> gigabit on Cisco switches
by Rick Hulsey 06 Sep '00

06 Sep '00

We use the F-760 in a cluster and Cisco 6509 switches with Gigabit connectivity to Suns and HP-UX boxes. We haven't had any problems with Gig-e or the switches, but we haven't got them spun up to full production usage levels yet. I would say that you need to make sure that you get the Intel NICs for the filer, but if you are order new gear now from Netapp, that should be a given. Rick Hulsey Southwest Airlines 2425 Wyman Mail Stop 4DC Dallas, Tx., 75235 rick.hulsey(a)wnco.com (214) 792-7188 Office (972) 880-6882 Cell (800) 915-3747 Pager >>> "Todd C. Merrill" <tmerrill(a)mathworks.com> 09/06/00 10:14AM >>> We are considering moving our F740 and F760 toasters from quad 100-Mbit ethernet EtherChannel'ed on a Cisco 5500 switch to the gigabit NICs on a new Cisco switch, a 6509. We're doing this 'cause: 1. We need more ports. Period. 2. The 6509 has a higher density of ports and gig ports. 3. The gigabit NICs are supposedly much faster, and you can offload the checksum processing from the main CPU to the gigabit card. (We're not even close to saturating the quad link now; I'm just talking latencies. Plus, we beat the crap out of our toasters; if the CPU can do less overhead and more data serving, I want it.) Anybody have any experience with the 6509 and NetApp's gigabit cards? Just want to assuage our concerns before placing the PO's. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

RE: ESTALE
by Strange, Steve 06 Sep '00

06 Sep '00

Deletion-handling of open files in NFS V2 and V3 (such as it is) is handled at the NFS client. The NFS server isn't aware of which clients have a file open, or how many processes on those clients have a particular file open (I'm assuming no NFS locking here). If a process on NFS client "A" has a file open, then another process on that same client deletes the file, the NFS client sends a "RENAME" to the NFS server, instead of a "REMOVE", so that the file sticks around until that first process closes the file (at least this is the case for NFS clients with which I'm familiar). The file is renamed to ".nfsXXXX", or something of that ilk, but the NFS file handle remains the same, so the first process can continue to read/write/etc. However, if a process on a different NFS client, "B", deletes the file, client "B" has no way of knowing that the file is open by a process on client "A". So client "B" will go ahead and remove the file completely, resulting in ESTALE the next time the process on client "A" attemts an operation on the file. Do you have just one NFS client accessing the file in question? What NFS client are you using? Hope this chatter is of some use. Cheers, Steve > -----Original Message----- > From: Edward Hibbert [mailto:EH@dataconnection.com] > Sent: Wednesday, September 06, 2000 4:39 AM > To: toasters(a)mathworks.com > Subject: ESTALE > > > Does anyone know under precisely what circumstances NetApp > returns ESTALE? > > I have a file open in my application to which I have just > done a write; I > issue another write very shortly thereafter and I get ESTALE back. > > Now, I believed that ESTALE was returned when a file handle > was presented > where the file had really been deleted and the inode for the > file was reused > for a new file. But since my process has the file open, even > if it's been > deleted by some other process (which is possible), I don't > think I should > get ESTALE returned. > > So this means I don't understand what is going on. But > perhaps you do :-). > > > Edward Hibbert. >

1 0

NetApp 9gb FC/AL drives available for sale
by ScottUCE＠aol.com 06 Sep '00

06 Sep '00

A leasing company has SEVEN 9gb FC/AL fiber disk drives (NetApp Model X219F) available; NetApp no longer offers these drives. They are asking $4,500.00 for the seven drives, shelf/power supply and cabling. Please contact me if you have any interest. Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 (612) 935-7282 (612) 935-5056 - FAX www.unioncomputer.com

1 0

ESTALE
by Edward Hibbert 06 Sep '00

06 Sep '00

Does anyone know under precisely what circumstances NetApp returns ESTALE? I have a file open in my application to which I have just done a write; I issue another write very shortly thereafter and I get ESTALE back. Now, I believed that ESTALE was returned when a file handle was presented where the file had really been deleted and the inode for the file was reused for a new file. But since my process has the file open, even if it's been deleted by some other process (which is possible), I don't think I should get ESTALE returned. So this means I don't understand what is going on. But perhaps you do :-). Edward Hibbert.

1 0

RE: Budtool woes
by Clawson, Simon 05 Sep '00

05 Sep '00

Hi! Thanks for the info! Scary stuff this backup! I have just checked the logs to find that the backup ran for 32 hours this weekend! Anyway, How have you achived the spliting of your file system? I think this is going to cause us problems due to the rather unitelligent autoloader we use to drive the backup...any advise on this? Simon -----Original Message----- From: Marion Hakanson [mailto:hakanson@cse.ogi.edu] Sent: 01 September 2000 18:24 To: Clawson, Simon Cc: toasters(a)mathworks.com Subject: Re: Budtool woes > . . . > I am bacing up a single volume filer with nearly 200GB of data - my backup > is constanlty failing due to the process running out of time..anyone seen > this? Is there a way round it? Can I increse the allowable time? Can I split > the backup into several levels? > . . . Simon, I see that you've probably solved your timeout problem, but you've probably got another problem as well. I've just upgraded to bt-4.6.1a, and the Release Notes state that it does not support backups that get split across more than 3 tapes. I'll spare you the details right now, since you can go look at my original posting to "toasters" on this topic: http://teaparty.mathworks.com:1999/toasters/6612.html Apparently a large backup of this type will work fine, but you may not be able to do recoveries from it, under certain mysterious circumstances (which I've not yet experienced, thankfully). The workaround is to break up that single backup into backups of subdirectories of that large volume (you don't have to breakup the volume itself). Solaris ufsdump can do this, but doesn't support incremental (non-full) dumps of subdirectories; Fortunately (by the tests I've done here), NetApp's dump (both console/cmd-line and NDMP) can do both fulls and incrementals of subdirectories. I've since noticed that NetApp themselves recommend against backing up large volumes (>100GB) in a single "dump" run. Here's where: http://now.netapp.com/NOW/knowledge/docs/ontap/rel536r2/html/sag/dump7.htm Luckily for us, our large volume (185GB, currently) is broken up into about ten qtrees & a couple other directories. I think the 10-12 dumps actually complete slightly faster than the previous single large dump. BTW, how's it going in your search for a BudTool replacement? A PDC engineer told me that the new Legato Networker 6.0 NDMP support will only do backups to either a NetApp-attached library, or to another NDMP enabled system (and _not_ to a Networker media server). It doesn't support a split-library configuration at all (which is what we have our BudTool/NetApp setup doing). Because of that, they want to sell me Veritas NetBackup instead. I've got a few other leads in the works, and I'd be happy to compare notes on what you've found so far. Good luck and regards, -- Marion Hakanson <hakanson(a)cse.ogi.edu> CSE Computing Facilities

2 1

RE: Splitting large volumes
by Krause, Oliver 04 Sep '00

04 Sep '00

If you used the "-level 0" option when doing the initial transfer then subsequent incrementals do the expected: If you delete a file on the source and do a incremental it is also gone on the destination. Don't omit "-level 0" for doing the level 0 dump if you want this working that way. Oliver > -----Original Message----- > From: Cliff.Dobbs(a)arm.com [mailto:Cliff.Dobbs@arm.com] > Sent: Montag, 4. September 2000 17:12 > To: toasters(a)mathworks.com > Subject: Re: Splitting large volumes > > > > Folks, > > I can't seem to find any info on what ndmpcopy does when a > file is removed > from the source filer after a level 0 dump. > > Does it remove the said file from the destination filer ( as > per rdist -R) > or do you end up with loads of files which the users thought they had > deleted :-( > > Cheers > > > Cliff Dobbs Systems Administrator ARM Ltd > Tel: +44 1223 400430 Fax: +44 1223 400410 e-mail: Cliff.Dobbs(a)arm.com > > > > > > > The easiest solution, that also demands minimal downtime is > > using ndmpcopy/rsync altogether... > > > > This will work only if you have free volumes on the new machine... > > > > > > 1. Copy a baseline copy of the seperate parts of your current > > volume to the target volumes, using ndmpcopy/rsync/tar/whatever > > (ndmpcopy will be the fastest probably). > > This can be done while users are working, a few hours/days > > before the migration downtime is planned. > > 2. In something like a few hours before the downtime, use > > the utility "rsync" and/or ndmpcopy to copy incrementally > > the changes since the baseline. > > 3. DOWNTIME - while in downtime, just do a final syncing, again > > using ndmpcopy incremental/rsync, and change the > relevant settings: > > NIS maps, filer's /etc/exports, /etc/quotas... > > > > In theory, this is the way to go and is what we ended up > doing when we > copied a volume to a new volume about a couple weeks ago. We > did a level > 0 dump/restore with ndmpcopy while the filer was up and during the > downtime we picked up the changes with rsh filer dump | rsh > filer restore. > We didn't use rsync because we didn't want to lose any CIFS file > attributes. > > Let me warn you about some problems we ran into. We've submitted bug > reports where appropriate. > > 1) We are running 5.3.5R2P2 and there is a known bug in > incremental NDMP > where it fails to dump files that should be dumped because > NDMP dump only > looks at the mtime and not the mtime and the ctime. To work > around the > bug, which is only in NDMP dump, we used "rsh filer dump | rsh filer > restore". We ran into some serious problems where the > restore would stop > working and drop into an infinite loop. This would happen > often, but not > always. I'm talking to netapp about this one. > > 2) We discovered a bug where a level 0 subtree dump skips files dated > before 00:00:00 Jan 1, 1970 GMT, i.e., files with negative timestamps. > Don't ask me how they got there, they are user files and we > had over 500 > of them. This problem does not happen with a full volume dump, just a > subtree. So I suggest either doing a full volume dump or > running a find > to locate all such files and "touch" them to a time after 1970. > > 3) Very minor bug -- one of our users has the unix uid 65535, > which has > the bit pattern 0xffff which is -1 in a 16 bit signed int. After the > restore, this user's files were all owned by root instead of 65535. > Nearby uids both above and below worked correctly. > > 4) Our original filesystem was created under DOT 5.0.2 and > the filer was > upgraded at least twice since. We run a mixed NFS and CIFS > environment. > In some of the older versions of DOT were some bugs in the > WAFL directory > format. One bug allowed two different files to be created in the same > directory with the exact same name. Even though our version of DOT no > longer has this bug, our volume still had three such pairs of > files on it. > The full dump/restore had no problems with these files, but the > incremental restore -r could not cope and failed without restoring > anything. If you can find these file pairs the fix is simple. Just > rename one of the files. You have no control over which one > of the two > the filer picks, but afterward, you can see both files. This is a > particularly insidious problem because any incremental dump > of a volume > with duplicate filenames CANNOT BE RESTORED with "restore > -r". You will > be forced to use "restore -x" which is less than desirable. > Dump does not > issue any errors, either. It's only when you restore that > you discover > the problem. > > You can locate duplicate files like this: > > find dir -print | sort > out1 > sort -u out1 > out2 > diff out1 out2 > > MORAL: Before a big volume copy, do some dry runs to be sure > you won't > run into problems during your downtime. Be sure to test both the full > dump/restore and incremental dump/restore. We discovered > many of these > problems during the two weeks leading up to our downtime. > Even still, we > hit a couple snags during the downtime that cost us at least 2 hours. > > One final tip: Before running restore -r on an incremental dump, > be sure to save a copy of the restore_symboltable file since > restore -r modifies it. If the restore modifies the file and then > fails, you can't rerun the "restore -r" unless you put back the > original file. Even then you may have problems, and will need to > use "restore -x". > > > Steve Losen scl(a)virginia.edu phone: 804-924-0640 > > University of Virginia ITC Unix Support > > >

1 0

Re: Splitting large volumes
by Cliff.Dobbs＠arm.com 04 Sep '00

04 Sep '00

Folks, I can't seem to find any info on what ndmpcopy does when a file is removed from the source filer after a level 0 dump. Does it remove the said file from the destination filer ( as per rdist -R) or do you end up with loads of files which the users thought they had deleted :-( Cheers Cliff Dobbs Systems Administrator ARM Ltd Tel: +44 1223 400430 Fax: +44 1223 400410 e-mail: Cliff.Dobbs(a)arm.com > The easiest solution, that also demands minimal downtime is > using ndmpcopy/rsync altogether... > > This will work only if you have free volumes on the new machine... > > > 1. Copy a baseline copy of the seperate parts of your current > volume to the target volumes, using ndmpcopy/rsync/tar/whatever > (ndmpcopy will be the fastest probably). > This can be done while users are working, a few hours/days > before the migration downtime is planned. > 2. In something like a few hours before the downtime, use > the utility "rsync" and/or ndmpcopy to copy incrementally > the changes since the baseline. > 3. DOWNTIME - while in downtime, just do a final syncing, again > using ndmpcopy incremental/rsync, and change the relevant settings: > NIS maps, filer's /etc/exports, /etc/quotas... > In theory, this is the way to go and is what we ended up doing when we copied a volume to a new volume about a couple weeks ago. We did a level 0 dump/restore with ndmpcopy while the filer was up and during the downtime we picked up the changes with rsh filer dump | rsh filer restore. We didn't use rsync because we didn't want to lose any CIFS file attributes. Let me warn you about some problems we ran into. We've submitted bug reports where appropriate. 1) We are running 5.3.5R2P2 and there is a known bug in incremental NDMP where it fails to dump files that should be dumped because NDMP dump only looks at the mtime and not the mtime and the ctime. To work around the bug, which is only in NDMP dump, we used "rsh filer dump | rsh filer restore". We ran into some serious problems where the restore would stop working and drop into an infinite loop. This would happen often, but not always. I'm talking to netapp about this one. 2) We discovered a bug where a level 0 subtree dump skips files dated before 00:00:00 Jan 1, 1970 GMT, i.e., files with negative timestamps. Don't ask me how they got there, they are user files and we had over 500 of them. This problem does not happen with a full volume dump, just a subtree. So I suggest either doing a full volume dump or running a find to locate all such files and "touch" them to a time after 1970. 3) Very minor bug -- one of our users has the unix uid 65535, which has the bit pattern 0xffff which is -1 in a 16 bit signed int. After the restore, this user's files were all owned by root instead of 65535. Nearby uids both above and below worked correctly. 4) Our original filesystem was created under DOT 5.0.2 and the filer was upgraded at least twice since. We run a mixed NFS and CIFS environment. In some of the older versions of DOT were some bugs in the WAFL directory format. One bug allowed two different files to be created in the same directory with the exact same name. Even though our version of DOT no longer has this bug, our volume still had three such pairs of files on it. The full dump/restore had no problems with these files, but the incremental restore -r could not cope and failed without restoring anything. If you can find these file pairs the fix is simple. Just rename one of the files. You have no control over which one of the two the filer picks, but afterward, you can see both files. This is a particularly insidious problem because any incremental dump of a volume with duplicate filenames CANNOT BE RESTORED with "restore -r". You will be forced to use "restore -x" which is less than desirable. Dump does not issue any errors, either. It's only when you restore that you discover the problem. You can locate duplicate files like this: find dir -print | sort > out1 sort -u out1 > out2 diff out1 out2 MORAL: Before a big volume copy, do some dry runs to be sure you won't run into problems during your downtime. Be sure to test both the full dump/restore and incremental dump/restore. We discovered many of these problems during the two weeks leading up to our downtime. Even still, we hit a couple snags during the downtime that cost us at least 2 hours. One final tip: Before running restore -r on an incremental dump, be sure to save a copy of the restore_symboltable file since restore -r modifies it. If the restore modifies the file and then fails, you can't rerun the "restore -r" unless you put back the original file. Even then you may have problems, and will need to use "restore -x". Steve Losen scl(a)virginia.edu phone: 804-924-0640 University of Virginia ITC Unix Support

1 0

migrating from nfs to cifs
by neil lehrer 01 Sep '00

01 Sep '00

hi, we are migrating from our sun servers to filers by doing an nfs cp -p. our user environment is primarily nt wkstations and we want to eventually convert to cifs access and to an ntfs security model. does anyone have any suggestions on how to automatically create the appropriate acls for both home and shared directories[including group aces]? thanks. -- regards +++++++++++++++++++++++++++++++++++++++++++++++++ + Neil Lehrer + + United States International Broadcasting Bureau + System Development Division + + voice 202 619-2524 + fax 202 619-3576 + nlehrer(a)ibb.gov + + " is this crisis an opportunity or just + another grab the fire extinguisher moment?" + +++++++++++++++++++++++++++++++++++++++++++++++++

1 0

SAN backups of filers
by Garrett Burke 01 Sep '00

01 Sep '00

Hi All, Anyone out there using a SAN to backup their filers to a centralised library? (See NAS Neets SANs http://www.vixel.com/whitepapers/ and http://www.netapp.com/tech_library/3080.html) We are investigating this option and would be interested in hearing about any experiences people have had? Thanks, GB -- Garrett Burke, Operations Manager Eircom Multimedia Infrastructure Internet House 26-34 Temple Bar.

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 September 2000