toasters

toasters@lists.teaparty.net

13515 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

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

01 Sep '00

Found that one. I've changed it, fingers crossed now for the weekend. Thanks Simon -----Original Message----- From: Paul Lupa (ra5507) [mailto:paul.lupa@motorola.com] Sent: 01 September 2000 12:09 To: Clawson, Simon Cc: toasters(a)mathworks.com Subject: Re: Budtool woes Simon, Please look at the file $BTHOME/bud/goserver.end.filter and look for the string BT_REQ_CMDTIMEOUT Changing it to the number of seconds that you need will solve your problem. Paul Lupa "Clawson, Simon" wrote: > > > Hi! > > We have Budtool 4.6.1, and are currently looking for a replacement. > However... > > 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? > > HELP! > > Simon > > Simon Clawson > Renoir Group Systems Administrator > Mentor Graphics Uk > Rivergate > London Road > Newbury > Berkshire > RG14 2QB > <<Clawson, Simon.vcf>>

1 0

accessing mixed-case files on Netapp
by Eric Seidman 31 Aug '00

31 Aug '00

I was directed to this mailing list as a good source of knowledge about accessing files on Netapp. I hope this question is appropriate; if not, I apologize. I am working in an environment in which a Netapp filer containing files with mixed-case names is being accessed using both CIFS and NFS. It is important that I be able to access the files using NFS in a case-insensitive manner. Unfortunately, converting all of the filenames to a consistent case is not an option. The NFS access is being done from a RedHat Linux server running Apache. I have considered writing an Apache module to parse the directory structure to determine the actual case of the filename, although this option seems too inefficient. Any suggestions would be greatly appreciated. Thank you very much for your time, eric seidman eseidman(a)cs.stanford.edu

6 5

RE: netapp console to terminal server?
by Lyons, Jim 31 Aug '00

31 Aug '00

Here is the shell config that finally worked for me with a straight through cable: RJ45 COLOR DB9 1 RTS----BLUE-------\ | 2 DTR----ORANGE--\ | | | 3 TXD----BLACK---|--|-----------2 RXD | | 4 GND----RED-----|--|----\ | | >-----5 GND 5 GND----GREEN---|--|----/ | | 6 RXD----YELLOW--|--|-----------3 TXD | | 7 DSR----BROWN---/ | | 8 CTS----WHITE------/ Thanks to all who offered their suggestions. rgds, Jim -----Original Message----- From: Lyons, Jim Sent: Thursday, August 17, 2000 5:16 PM To: toasters(a)mathworks.com Subject: netapp console to terminal server? We are trying to attach our netapp db9 console ports to a cisco as2509-rj async rj45 lines, but are having no luck. The cisco h/w configuration documentation has a diagram for the db9 to rj45 pinout, but it does not work. Has anyone done this? Thanks, Jim

1 0

Cold calls
by chris_good＠webtop.com 31 Aug '00

31 Aug '00

Looks like Spektralogik are doing the rounds cold calling people off the list. I've just had a call and they couldn't give me a satisfactory exmplanation of how they got my number. Please feel free to give them a good slapping when they call... Chris -- Chris Good WebTop.com http://www.webtop.com Tel: +44 (0) 1223 715000 Fax: +44 (0) 1223 715001

1 0

RE: default unix file modes for CIFS users
by Muhlestein, Mark 31 Aug '00

31 Aug '00

Files created by CIFS clients in UNIX qtrees inherit permissions from the parent directory. What permissions do you need? Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Ethan Torretta [mailto:ejt@tellme.com] Sent: Wednesday, August 30, 2000 4:36 PM To: toasters(a)mathworks.com Subject: default unix file modes for CIFS users How can one set the default file mode for files created by CIFS users in a unix qtree? The files here are being created with the mode 0755, which annoys the CVS admin because he has to fix them all in the server. The SecureShare Access utility is pretty neat, but it doesn't change the default, and it won't be possible to make all the Windows users change every file they create. The only filer option that seems similar is the PCNFS umask, but of course it's not for CIFS. ejt

1 0

default unix file modes for CIFS users
by Ethan Torretta 30 Aug '00

30 Aug '00

How can one set the default file mode for files created by CIFS users in a unix qtree? The files here are being created with the mode 0755, which annoys the CVS admin because he has to fix them all in the server. The SecureShare Access utility is pretty neat, but it doesn't change the default, and it won't be possible to make all the Windows users change every file they create. The only filer option that seems similar is the PCNFS umask, but of course it's not for CIFS. ejt

1 0

Workaround for Burt 23129?
by TTSG 30 Aug '00

30 Aug '00

Hi, Has anyone heard/seen a work around for Burt 23149 : If an NFS over UDP request is received on a filer's interface and therequest is for the interface's secondary/aliased IP address, the filerwill always respond using the interface's primary (real) address.This can cause NFS mounts to hang if the aliased address is on adifferent subnet than the primary address. Tuc/TTSG

1 0

Recommendations/Opinions on the NetApp F720 filer
by lgkloft＠usgs.gov 30 Aug '00

30 Aug '00

I have a fairly small office (approximately 45 people) and perform GIS (geographic information system - ESRI ArcInfo) work, environmental modeling/database, reports writing, and other administrative tasks (email and web surfing). I am looking at the F720 fileserver (7-36GB drives, NFS, CIFS) to consolidate the $HOME and $PROJECT areas on my computer systems, and perhaps eventually the databases. The majority of my office is UNIX, but the number of PCs (as clients) is steadily growing. I am able to backup the UNIX boxes (servers) quite easily (~25GB), but the PCs are going to complicate matters. I realize this isn't much information to go on, but for those of you who are currently using the F720 - overall, are you happy with the performance and is your operation similar to mine (or larger)? How does your F720 respond to network traffic over the onboard 100-Base-T connection - is it a bottleneck? Do you utilize the QFE option (four 100-Base-T board) and did you designate certain protocols (NFS/CIFS) or servers to a particular IP address (pipes)? Do you now use the 1000Base-T connection - and how does/did this compare to the QFE option described above (if it was replaced)? Do you have any experiences/recommendations to provide on interfacing the filer into the LAN? How do your PC users (with local 10,000RPM disk drives) find the access speeds to their files on the file server - are they content or do they receive better performance having their data local on their drive? I have pulled numerous documents from NetApps WWW server (haven't read them all yet). Any closing comments/experiences (things to look out for, or plan for, etc.) positive or negative on the F720 would be greatly appreciated? Thanks, Loren

1 0

anybody using cluster with ATM and LANE?
by neil lehrer 30 Aug '00

30 Aug '00

hi, i'm looking for references to talk to about netapp filers. in particular cluster, with ATM using LANE, and NFS and CIFS. we are considering buying a pair of f760's and would like to hear about comparable experiences. our environment is solaris servers, nt workstations, fore atm switches. thanks. -- regards

1 0

Snapshots and the block allocation map [was: Alot minus alot equals some?]
by Chris Thompson 30 Aug '00

30 Aug '00

I wrote: > [...] the block allocation map (4 bytes per 4K block on the data discs) [...] > The former, in particular, does not have its blocks deallocated just because > they have reverted to being all-zero. It occurs to me that one thing that causes the allocation map to expand to its maximum size rapidly in a new volume is taking a snapshot. And *that* reminds me about one of the promises about ONTAP 6.0 in Field Alert #66: | * Enhanced Snapshot functionality to provide near instantaneous | snapshot creation/deletion and increased snapshot count from 20 | to 31 per volume The main reason taking a snapshot is not "nearly instantantaneous" at the moment is that the block allocation map gets completely rewritten. (And as a result, there's a space overhead of the size of the map times the number of snapshots less one.) It would be interesting to know how NetApp have reworked the internal structures to get round this. But maybe it's Confidential Information and we'll have our lips stapled together if we start speculating... :-) The maximum of 31 snapshots suggests that the basic style of a 32-bit word of allocation information per block still persists. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

2 1

Re: Splitting large volumes
by Eyal Traitel 30 Aug '00

30 Aug '00

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... Eyal. ===== Yours, Eyal Traitel eTraitel(a)yahoo.com, Home: 972-3-5290415 (Tel Aviv) *** eTraitel - it's the new eBuzzword ! *** __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/

5 5

Alot minus alot equals some?
by Tuc 30 Aug '00

30 Aug '00

Hi, Brand new filer, 11x18G disks in the RAID-5 group. I started copying content to it, but told it to follow links by accident. I had gotten about 3G of content on when I stopped it. I then just did a "rm -rf /mnt/*". However : 216.231.105.197:/vol/vol1 125186456 177408 125009048 1% /mnt # ls -lR /mnt /mnt: total 0 # Whats taking 177K? Tuc/TTSG

2 1

RE: Alot minus alot equals some?
by Tuc 30 Aug '00

30 Aug '00

> Hi, > > Brand new filer, 11x18G disks in the RAID group. > > I started copying content to it, but told it to follow links by > accident. > > I had gotten about 3G of content on when I stopped it. I then > just did a "rm -rf /mnt/*". However : > > 216.231.105.197:/vol/vol1 > 125186456 177408 125009048 1% /mnt > > # ls -lR /mnt > /mnt: > total 0 > # > > Whats taking 177K? > I just did it again.... Copied about 3G before I realized AGAIN that the Sun "cp" is different than my BSDI cp. Now : # df -k /mnt Filesystem kbytes used avail capacity Mounted on 216.231.105.197:/vol/vol1 125186456 182592 125003864 1% /mnt # du -s /mnt 80 /mnt # ls -lR /mnt /mnt: total 0 Am I hitting something I should report? Tuc/TTSG

2 1

references
by neil lehrer 29 Aug '00

29 Aug '00

1 0

RE: IIS 5 - pass through authentication
by Benn, Paul 29 Aug '00

29 Aug '00

Mathew, In the IIS5 testing I did late last year, it didn't work. I have yet to confirm the rumor but have heard that it does work with IIS5 if clear text passwords are enabled and the user name and password fields are left blank when setting up the UNC path. Once I confirm it working I'll update the tech report with my findings (will probably be a few weeks out). Best Regards, Paul "the guy who wrote that paper" Benn Network Appliance -----Original Message----- From: Mathew Anderson [mailto:mathew@nm.net] Sent: Tuesday, August 29, 2000 1:51 PM To: toasters(a)mathworks.com Subject: IIS 5 - pass thtough authentication I was wondering if, with IIS 5, the "Pass Through Authentication" problem was solved. This is in reguards to http://www.netapp.com/tech_library/3078.html (Integrating a NetApp Filer with Microsoft IIS 4.0) Thanks! -Mathew Mathew Anderson Systems Administration NM Technet Oso Grande Technologies, Inc. mathew(a)nm.net mathew(a)osogrande.net

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