toasters

toasters@lists.teaparty.net

13531 discussions

vol0 question
by Jeff Kennedy 05 Feb '02

05 Feb '02

Now that the R100 has come out I was wondering what people think of the seperate vol0 concept? In the old days it wasn't quite so bad; ok, so you wasted a 4gb drive or maybe even an 18gb drive. But now we're looking at tossing a 136gb drive for what? Squat really. So what's the new thought on this? Do you not waste the disk on a seperate vol0 and just keep tight reigns on qtrees? Or is there still an argument for vol0 on it's own? Thanks. -- ===================== Jeff Kennedy Unix Administrator AMCC jlkennedy(a)amcc.com

4 6

RE: Slow write performance
by Mike Ball 05 Feb '02

05 Feb '02

Edward, Telnet to the netapp and type "sysstat 1". Let it run for about 20 seconds and send us the output. Also, type "ifconfig -a" and send us the output. Mike -----Original Message----- From: Edward Hibbert [mailto:EH@dataconnection.com] Sent: Tuesday, February 05, 2002 2:24 PM To: toasters Subject: Slow write performance We're seeing some performance problems on an F720 which you guys might be able to help with (even though it's not exactly top of the range nowadays). What we see is: - We're driving it over NFS v3. - We get about 1500 ops/sec out of it, of which one third are writes and two thirds are reads. There aren't many file open/close operations. - The operations are to random locations in large (10GB) files. - The CPU is running about 75%, and the network input and output below the throughput of the link we have to it. We've seen both CPU and network go higher if we do simple copy tests. - Looking it it via pktt trace, something approaching 15% of WRITE operations take long enough for the clients to time out and retransmit (so at least 1 second). None of the READ operations do. - The retransmissions appear to come in bunches. For example we'll see a few seconds where the filer doesn't respond, during which time the retransmissions will come in, then it will wake up and send some responses back. - The rest of the time, the WRITES are very fast (sub-ms). This appears to have worsened recently. We tried a couple of things: - We thought that this might be because the disk had got full and fragmented, so we zapped a bunch of data. - We rebooted. Neither of these seemed to help much. sysstat consistently shows a cache age of 1. This, and the bursty nature of the delays, suggest to me that I'm just hitting it too hard, and there's some kind of periodic cache-flushing operation going on, but do any of you folk have any other suggestions? Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh(a)dataconnection.com Web: http://www.dataconnection.com

1 0

Slow write performance
by Edward Hibbert 05 Feb '02

05 Feb '02

We're seeing some performance problems on an F720 which you guys might be able to help with (even though it's not exactly top of the range nowadays). What we see is: - We're driving it over NFS v3. - We get about 1500 ops/sec out of it, of which one third are writes and two thirds are reads. There aren't many file open/close operations. - The operations are to random locations in large (10GB) files. - The CPU is running about 75%, and the network input and output below the throughput of the link we have to it. We've seen both CPU and network go higher if we do simple copy tests. - Looking it it via pktt trace, something approaching 15% of WRITE operations take long enough for the clients to time out and retransmit (so at least 1 second). None of the READ operations do. - The retransmissions appear to come in bunches. For example we'll see a few seconds where the filer doesn't respond, during which time the retransmissions will come in, then it will wake up and send some responses back. - The rest of the time, the WRITES are very fast (sub-ms). This appears to have worsened recently. We tried a couple of things: - We thought that this might be because the disk had got full and fragmented, so we zapped a bunch of data. - We rebooted. Neither of these seemed to help much. sysstat consistently shows a cache age of 1. This, and the bursty nature of the delays, suggest to me that I'm just hitting it too hard, and there's some kind of periodic cache-flushing operation going on, but do any of you folk have any other suggestions? Edward Hibbert Internet Applications Group Data Connection Ltd Tel: +44 131 662 1212 Fax: +44 131 662 1345 Email: eh(a)dataconnection.com Web: http://www.dataconnection.com

1 0

6.2, R100, Where?
by Ambrose_Earle＠shamrockfoods.com 05 Feb '02

05 Feb '02

Where can I find information about the features scheduled for DataONTAP 6.2? and the R100? and other new things?

1 0

Using spare disk shelves
by William Liu 05 Feb '02

05 Feb '02

Question: Suppose I have an additional disk shelf that has data on it, can I just easily add it to the daisy chain of disk shelves on the netapp? So when I do a "sysconfig -r" it will show as spares? Keep in mind that these drives aren't empty. I don't see why not since the source file/directory structure comes from the already configured disk shelves. Can someone shed some light on this? Thanks.

2 1

new bug 60490 cifs and symlinks
by neil lehrer 04 Feb '02

04 Feb '02

has anyone seen this issue? i am going to be using 1 symlink per user for homedirs because our homedir struct is not flat - h/a/aboy, h/b/balbert with dirs a - z. the homedir option will point to the homelinks dir which contains all the symlinks. Description Prolonged heavy access by CIFS clients that involve or cause lookup of Unix absolute symbolic links can affect filer performance. Because the resolution of absolute symlinks depends on Unix mount point information which is not available to CIFS clients, a table of translations is kept on the filer (/etc/symlink.translations). The entries in this file are order dependent and are searched sequentially. If a CIFS client is doing symlink lookups frequently, and if the entry to resolve the symlink is near the end of the file, and if the file is large, there can be a great deal of CPU utilization. This can slow operations for other users. For example, a user may be changing files in a directory that contains dozens of absolutes symbolic links. The /etc/symlink.translations file may have 1000s of entries. The user is accessing the files with Windows Explorer. After the target file is updated, the filer notifies Explorer of the file change. This is because Explorer will have posted a "change notify" request with the filer, so that it is alerted when changes occur and can update/redraw its display window. Explorer will touch each file including each of the symbolic links. The access of the symlinks will cause the filer to attempt to resolve them by scanning the /etc/symlink.translations entries. If there are many symlinks, many entries,multiple users with Explorer windows affected by change-notify updates, and if the entries needed to resolve the symlinks are missing or at the end of the /etc/symlink.translations file then filer performance can be affected. Workaround Use the filer's cifs homedir feature (options cifs.home_dir) instead of using a symlink per user when implementing CIFS home directories if there are many users. -- 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?" + +++++++++++++++++++++++++++++++++++++++++++++++++

4 7

RE: adding cifs users homedirs and setting ownership
by jwitham＠takedapharm.com 02 Feb '02

02 Feb '02

We did the migration from an NT fileserver about a year ago. Granted, we didn't go from NFS to CIFS, but maybe our experience will help a little. The way we define the user's homedir is by throwing the UNC in the Home Directory field in User Mangler, then do a 'net use H: /home' in the logon script. When we migrated, we had our webmaster take 5 seconds out of his busy day to write a quick ADSI script that tore through the SAM of the DCs and simply changed \\NTfileserver\username$ to \\filer\username. Then we used robocopy (NT Res kit) to move everything and their permissions to the new filer. If you're going from NFS to NTFS, you'll probably have to script something. For quotas, we use this line in /etc/quotas: * user@/vol/volX/users 3G (Yeah, I know, 3G for every user is huge.) I think this feature requires ONTAP 6.1, so buyer beware. If you have multiple NT domains, you might want to look at caveats of using the CIFS HOMEDIR option. It's nice not to have 1500 separate shares, but may be prohibitive if you have the same username for different users in multiple domains. Good luck! -john John Witham Sr. Data Networking Engineer Takeda Pharmaceuticals North America, Inc. A computer lets you make more mistakes faster than any invention in human history, with the possible exceptions of handguns and tequila. -Mitch Ratcliffe -----Original Message----- From: neil lehrer [mailto:nlehrer@yahoo.com] Sent: Friday, February 01, 2002 11:30 PM To: toasters(a)mathworks.com Subject: adding cifs users homedirs and setting ownership hi, we are going from nfs, unix on solaris to cifs, ntfs on filer. how do folks do the normal creation of new users homedir[we currently map our h: drive from the login script, we don't set the homedir in the users domain account]. from nt gui, from cmdline, using script? and, for quota purposes, how do you set the new users's homedir ownership and acl, in ntfs? na_chown and some other util? i need to set this up for our user support folks and am looking for best ways. thanks ===== neil lehrer ******************************************** * is this crisis an opportunity for growth * or just another fire extinguisher moment? ******************************************** __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com This message is for the designated recipient only and may contain privileged or confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

1 0

adding cifs users homedirs and setting ownership
by neil lehrer 02 Feb '02

02 Feb '02

hi, we are going from nfs, unix on solaris to cifs, ntfs on filer. how do folks do the normal creation of new users homedir[we currently map our h: drive from the login script, we don't set the homedir in the users domain account]. from nt gui, from cmdline, using script? and, for quota purposes, how do you set the new users's homedir ownership and acl, in ntfs? na_chown and some other util? i need to set this up for our user support folks and am looking for best ways. thanks ===== neil lehrer ******************************************** * is this crisis an opportunity for growth * or just another fire extinguisher moment? ******************************************** __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com

1 0

samba smb.conf sample
by neil lehrer 01 Feb '02

01 Feb '02

hi, i loaded samba 2.2 on my solaris wkstation so i could see whether smbcacls might be useful for unix to ntfs on filer migration. but smbcacls won't run without the smb.conf file. the man page would be helpful if i knew what i was doing, but i don't. can someone send me a basic smb.conf that i can modify for my environment? i didn't see any examples at samba.org. thanks. --

1 0

RE: Whos got that file?
by Drew O'Donnell 01 Feb '02

01 Feb '02

Netwatch.exe, It comes with the NT 4.0 Resource kit. Works great. Drew -----Original Message----- From: Knight, Jason [mailto:Jason.Knight@citadelgroup.com] Sent: Friday, February 01, 2002 8:23 AM To: 'Sam Schorr'; Clawson, Simon; toasters(a)mathworks.com Subject: RE: Whos got that file? Two tools that I use are: 1. Winfile.exe (remember Windows 3.1?) 2. Hyena - this tool used by many NT admins works great on filers for managing files/shares. http://www.adkins-resource.com Hyena might save you from writing a perl script or two (if you have 100's of users with 1000's of files open). Jason Knight Citadel Investment Group L.L.C. -----Original Message----- From: Sam Schorr [mailto:sschorr@homestead-inc.com] Sent: Friday, January 25, 2002 9:41 AM To: Clawson, Simon; toasters(a)mathworks.com Subject: RE: Whos got that file? Yes. The command "CIFS sessions" returns the list of clients and the number of files they have open. The command "CIFS sessions clientname" returns the full file path on the filer that clientname has open and the kind of open. --sam -----Original Message----- From: Clawson, Simon [mailto:simon_clawson@mentorg.com] Sent: Friday, January 25, 2002 6:35 AM To: 'toasters(a)mathworks.com' Subject: Whos got that file? Hi! With CIFS Sessions I can see who's got a CIFS seesion open, but is there a way of seeing what file or path they are using? Simon Simon Clawson HDS Team Systems Administrator Mentor Graphics Uk Rivergate London Road Newbury Berkshire RG14 2QB <<Clawson, Simon.vcf>>

1 0

RE: Whos got that file?
by Knight, Jason 01 Feb '02

01 Feb '02

Two tools that I use are: 1. Winfile.exe (remember Windows 3.1?) 2. Hyena - this tool used by many NT admins works great on filers for managing files/shares. http://www.adkins-resource.com Hyena might save you from writing a perl script or two (if you have 100's of users with 1000's of files open). Jason Knight Citadel Investment Group L.L.C. -----Original Message----- From: Sam Schorr [mailto:sschorr@homestead-inc.com] Sent: Friday, January 25, 2002 9:41 AM To: Clawson, Simon; toasters(a)mathworks.com Subject: RE: Whos got that file? Yes. The command "CIFS sessions" returns the list of clients and the number of files they have open. The command "CIFS sessions clientname" returns the full file path on the filer that clientname has open and the kind of open. --sam -----Original Message----- From: Clawson, Simon [mailto:simon_clawson@mentorg.com] Sent: Friday, January 25, 2002 6:35 AM To: 'toasters(a)mathworks.com' Subject: Whos got that file? Hi! With CIFS Sessions I can see who's got a CIFS seesion open, but is there a way of seeing what file or path they are using? Simon Simon Clawson HDS Team Systems Administrator Mentor Graphics Uk Rivergate London Road Newbury Berkshire RG14 2QB <<Clawson, Simon.vcf>>

1 0

RE: CIFS Performance.
by Geert Jackers 01 Feb '02

01 Feb '02

For all those who responded to my problem with CIFS performance... Thanks, problom solved. We installed the oplocks patch on one system, but no result.The same with disabling the oplocks on the filer. We also have several interfaces on the box but we couldn't find a fault there too. So like some of you mentioned about 'streamlining' traffic, we looked into the networking aspect of this. We found that users on one system didn't have problems because they were connected at 10 Mbit Half Duplex, uplinked to a switch with 100Mbit full duplex and them together with several other 100 Mbit FD links uplinked to the backbone via 1 Gbit . The filer was connected to it via 1 Gbit. The ones experiencing problems didn't have a 1Gbit uplink to the backbone (only 100Mbit FD, but only very low traffic on this link), we changed to a half duplex link and the users to 10Mbit half duplex.....and everything flies. Now we get more than twice as fast as using a normal NT server. Which were fast with the old network config. IMHO these filers are very fast, but you need to have a network adapted to it. So thanks again Geert Geert Jackers Siemens Business Services Belgium

1 0

cifs performance
by Peter D. Gray 01 Feb '02

01 Feb '02

Greetings all, a quick question. We use our netapps for pretty much everything here at least on the UNIX side. We are happy to do this because we know that NFS performance is good. Our head of unit has asked me about using the filers for our NT storage. I really like the the idea of this but I have no feeling for how the NT boxes using CIFS rather than local disk will perform. I know some people are doing this. If you have experience with using CIFS for NT storage (databases etc) could you pls mail me with your experiences? Does anybody have information on CIFS performance in general they wish to share? Regards, pdg -- See mail headers for contact information.

1 0

NDMP restore issues resolved
by Matt Musgrove 31 Jan '02

31 Jan '02

Hi, Thanks to all the people who replied to my questions about NDMP restores from NetApp using Networker 6.1.1 on Solaris. Our issues were resolved (by NetApp) and the following findings made: DAR (Direct Access Restore) =========================== DAR is limited to 1024 files. If you try and recover more than 1024 files the restore will complete without error but only 1024 files will be recovered. This is in my opinion a Networker bug. Could also find no documentation about this1024 files limit. DAR is best used for recovering a few files from a large save set. When trying to recover hundreds of files the recover rate is very slow. In order to use nwrecover for recovering many files you must take out the line "DIRECT=y" in client setup. The restore will parse the whole saveset. Once finished, remember to put DIRECT=y back again. Recovering files past the browse policy ======================================= Our browse policy is set to 3 months but the media database is retained for 15 years. In order to recover files over 3 months old run the following command to get the save set information. % mminfo -aV -c netapp (where netapp is the client name) NetApp1Full.001 netapp 29 GB full /vol/unix 1351792385 1011913207 01/24/02 11:00:07 PM 04/27/02 01/24/17 0 30445916163 3 0 1351780097 30445916164 cbN Load the tape manually and fast forward to the right place on the tape. In the example above the command would be mt -f nrst1a fsf 3 (where nrst1a is the device name) View the contents of the backup with % restore tbf 60 nrst1a To restore to a specific location use the following (rewind and fsf if you ran a restore tbf first) % restore xbfD 60 nrst1a /vol/destination /vol/unix/file_to_recover If you don't specify a restore location it will go to /vol/vol0. Note, 60 is the block size which Networker defaults to. best regards Matt Musgrove Thales

1 0

RE: F720 & HP HVD LTO & NetVault
by graeme_taylor＠agilent.com 31 Jan '02

31 Jan '02

Hi, I'd be interested to know if you get anywhere with the HP LTO drives. We've just purchased a F820, I've had discussions with a few of the folk at NetApp and they've all said that the HP LTO drive isn't supported, something to do with the way HP do their compression. We've now moved onto looking at a StorageTek library with either the IBM or Seagate LTO drives. Regards, Graeme. Graeme Taylor Telecom Systems Division Agilent Technologies, Inc. 0131 331 6473 Tel 0131 331 7987 Fax -----Original Message----- From: Levent Kaptanoglu [mailto:lkaptan@pro-link.net] Sent: 31 January 2002 09:43 To: toasters(a)mathworks.com Subject: RE: F720 & HP HVD LTO & NetVault And I am also interested in using netVault with netapp. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Uros Lampret Sent: Monday, January 28, 2002 3:55 PM To: toasters(a)mathworks.com Subject: F720 & HP HVD LTO & NetVault Hi! I intend to use F720 with HP ShureStore HVD LTO and NetVault over NDMP. Has any body any comments or recomendations? Best Regards, Uros _____________________________ Uros Lampret Our Space Appliances d.o.o. Tbilisijska 59 1000 Ljubljana - Slovenia tel. +386 1 2425 372 fax +386 1 2425 382 email: uros.lampret(a)ourspace.si <mailto:uros.lampret@ourspace.si> internet: www.ourspace.si <http://www.ourspace.si> _____________________________

1 0

F720 & HP HVD LTO & NetVault
by Uros Lampret 31 Jan '02

31 Jan '02

Hi! I intend to use F720 with HP ShureStore HVD LTO and NetVault over NDMP. Has any body any comments or recomendations? Best Regards, Uros _____________________________ Uros Lampret Our Space Appliances d.o.o. Tbilisijska 59 1000 Ljubljana - Slovenia tel. +386 1 2425 372 fax +386 1 2425 382 email: uros.lampret(a)ourspace.si internet: www.ourspace.si _____________________________

2 1

nt inheritance
by neil lehrer 30 Jan '02

30 Jan '02

ontap 6.1.1r2 can anyone tell me a good way to tell if a dir or qtree has autoinheritance blocked? the different tools i have are giving me different results. -- 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

RE: CIFS Performance.
by Haber, David J. 30 Jan '02

30 Jan '02

We had similar problems, especially when copying files and with Microsoft Office products. We solved these problems by making two changes in our configuration. We have a 4-port 10/100 VIF with channeling on our Cisco switch. The default gateway was set for the VIF subnet on the switch. We also had ("had" is the key word here!) the e0 interface set up on a different subnet than the VIF. There was a problem with the switch determining the proper gateway for the e0 interface since the filer can only have one default gateway. Once we disabled the e0 interface performance improved for clients who were on remote (T1 linked) subnets. We still had a problem for some users when they tried to copy files from the filer. We found that these users were on 10/100 ports that were set to full duplex, 100Mb port speed. We changed the setting to half duplex, 100Mb port speed and that solved the problem for these users. We currently have over 2000 user home directories and group shares on the filer with excellent performance at our primary sites and at our 40 T1-linked sites. Maybe this will help with some of your problems. -----Original Message----- From: Geert Jackers [mailto:gj@pandora.be] Sent: Wednesday, January 30, 2002 1:33 PM To: toasters(a)mathworks.com Subject: CIFS Performance. Hi, we have F740 and F820 running only CIFS. We hear everywhere that the performance is great of these boxes. We installed the latest 6.1.1R2 (I think) which would solve some problems with virusscanning (trendmicro) on the boxes and clients. When we read a file (doc file) it is somewhat fast, but when we save it it takes twice as long as on a NT box. When we do the same with a RTF file....or TXT it is much faster. Not to say when opening or working with outlook and .pst files on that share, it takes forever.....almost. We see that when we open a file on the box a ~file is created on the same directory too, can this have an influence ? A copy from a file to and from the box....also slow. We have a 100 Mbit switched network and 1 Gbit links to the filers....other traffic on the network is fast etc. We disabled viruschecking on the filer and the pc's...no difference. Do we need to tune or set special parameters on the filer ? Somebody has had the same experience....? Please any info is appreciated. Geert Geert Jackers Siemens Business Services Belgium

1 0

RE: CIFS Performance.
by Andrew Yee 30 Jan '02

30 Jan '02

FYI, we also played with the oplocks configuration and even tried an undocumented oplocks feature that didn't help during our investigation/trouble-shooting phase. We still have oplocks enabled. I will probably call NetApp and review one of my closed cases with a TSE about disabling oplocks. However, we sorta want oplocks enabled... >>> "Drew O'Donnell" <drew(a)cooperneff.com> Wednesday, January 30, 2002 11:12:50 AM >>> We had a similar problem and it ended up being oplocks. It also seemed to manifest itself in office files only, not txt files. Turn oplocks off on one of the qtrees which was having the issue and see if you get the same problem. The command to turn oplocks off is "qtree oplocks qtreename disable" If this fixes the issue I would call support because this should have been fixed in 6.1.1Rx. Later Drew -----Original Message----- From: Geert Jackers [mailto:gj@pandora.be] Sent: Wednesday, January 30, 2002 1:33 PM To: toasters(a)mathworks.com Subject: CIFS Performance. Hi, we have F740 and F820 running only CIFS. We hear everywhere that the performance is great of these boxes. We installed the latest 6.1.1R2 (I think) which would solve some problems with virusscanning (trendmicro) on the boxes and clients. When we read a file (doc file) it is somewhat fast, but when we save it it takes twice as long as on a NT box. When we do the same with a RTF file....or TXT it is much faster. Not to say when opening or working with outlook and .pst files on that share, it takes forever.....almost. We see that when we open a file on the box a ~file is created on the same directory too, can this have an influence ? A copy from a file to and from the box....also slow. We have a 100 Mbit switched network and 1 Gbit links to the filers....other traffic on the network is fast etc. We disabled viruschecking on the filer and the pc's...no difference. Do we need to tune or set special parameters on the filer ? Somebody has had the same experience....? Please any info is appreciated. Geert Geert Jackers Siemens Business Services Belgium

1 0

Re: CIFS Performance.
by Andrew Yee 30 Jan '02

30 Jan '02

We've encountered issues like that in our environment. Obviously, we bought the FILER for its redundancy as well as speed in serving data. I had opened several cases on the NOW site about the apparent slowness. Our FILER was setup with a 100-base-t connection directly to our 3Com CoreBuilder 9000, which has a Gigabit backbone. We found that it would take 75 seconds to open a 250 KB Excel Spreadsheet and 110 seconds to save it to the FILER. Sometimes, it wouldn't save and would give "delayed-write" errors. However, our NT 4 Server that the FILER was replacing also had similar delays BUT these spreadsheets would eventually save OK. NetApp had us do a lot of pktt'ing and other configuration testing. For our specific environment, it turned out the culprit was the fact that users were connecting to a 3Com 10-base-t hub that was connected to a 3Com SuperStack Switch. We also found hubs interconnected to each other and then connected to the switch. According to their analysis of the pktt traces, it appeared that the FILER was handling data fine, but there were some sort of network bottlenecks on our side. Kudos for NetApp TSE's willingness to help us trouble-shoot some of our non-FILER-related network investigation. Reconfiguring users to connect to the switch at 100/Full-Duplex fixed access speed issues. (The users also felt that somehow, we had sped up all of their computers.) We found it a bit odd that the FILER seemed to desire high-speed network connections vs. being able to handle pokey slow network connections. Of course, this may specifically be due to our network setup and all of the 20 year-old CAT-3 wiring everywhere, plus mice chewing up cables. We recently purchased the McAfee NetShield 4.5 for NetApp but have yet to implement it. As the FILER's virus scan feature is somewhat immature, I do not look forward to setting this us. >>> Geert Jackers <gj(a)pandora.be> Wednesday, January 30, 2002 10:32:39 AM >>> Hi, we have F740 and F820 running only CIFS. We hear everywhere that the performance is great of these boxes. We installed the latest 6.1.1R2 (I think) which would solve some problems with virusscanning (trendmicro) on the boxes and clients. When we read a file (doc file) it is somewhat fast, but when we save it it takes twice as long as on a NT box. When we do the same with a RTF file....or TXT it is much faster. Not to say when opening or working with outlook and .pst files on that share, it takes forever.....almost. We see that when we open a file on the box a ~file is created on the same directory too, can this have an influence ? A copy from a file to and from the box....also slow. We have a 100 Mbit switched network and 1 Gbit links to the filers....other traffic on the network is fast etc. We disabled viruschecking on the filer and the pc's...no difference. Do we need to tune or set special parameters on the filer ? Somebody has had the same experience....? Please any info is appreciated. Geert Geert Jackers Siemens Business Services Belgium

1 0

RE: CIFS Performance.
by Drew O'Donnell 30 Jan '02

30 Jan '02

We had a similar problem and it ended up being oplocks. It also seemed to manifest itself in office files only, not txt files. Turn oplocks off on one of the qtrees which was having the issue and see if you get the same problem. The command to turn oplocks off is "qtree oplocks qtreename disable" If this fixes the issue I would call support because this should have been fixed in 6.1.1Rx. Later Drew -----Original Message----- From: Geert Jackers [mailto:gj@pandora.be] Sent: Wednesday, January 30, 2002 1:33 PM To: toasters(a)mathworks.com Subject: CIFS Performance. Hi, we have F740 and F820 running only CIFS. We hear everywhere that the performance is great of these boxes. We installed the latest 6.1.1R2 (I think) which would solve some problems with virusscanning (trendmicro) on the boxes and clients. When we read a file (doc file) it is somewhat fast, but when we save it it takes twice as long as on a NT box. When we do the same with a RTF file....or TXT it is much faster. Not to say when opening or working with outlook and .pst files on that share, it takes forever.....almost. We see that when we open a file on the box a ~file is created on the same directory too, can this have an influence ? A copy from a file to and from the box....also slow. We have a 100 Mbit switched network and 1 Gbit links to the filers....other traffic on the network is fast etc. We disabled viruschecking on the filer and the pc's...no difference. Do we need to tune or set special parameters on the filer ? Somebody has had the same experience....? Please any info is appreciated. Geert Geert Jackers Siemens Business Services Belgium

1 0

RE: IP 4700 vs Netapp
by Sam Schorr 30 Jan '02

30 Jan '02

Yeah, I pretty much missed the mark on this. Thanks for correcting my faulty recollections. Besides getting the underlying file system acronym wrong (should be UxFS), the Datamovers on the Celerra do not run Samba. Sorry for this folks. --sam -----Original Message----- From: Joe Luchtenberg [mailto:joe.luchtenberg@data-line.com] Sent: Wednesday, January 30, 2002 10:37 AM To: Sam Schorr; Mr. G. D. Geen; toasters Subject: RE: IP 4700 vs Netapp Celerra is most certainly not the forerunner of the IP4700 (although it did precede the "Chameliion"). Celerra is a network attached front end EMC offers to Symmetrix customers to provide a NAS interface to the SYM. The IP4700 is a purely NAS device built on a h/w platform from the DG acquisition married to a NAS OS developed from the CrosStor acquisition. Both NAS products are current EMC offerings. As to Mr. Geen's points: - the 50K ops/sec if I understand correctly is a measure of the memory to network mapping performance (remember the BlueArc threads of several months ago); you will find this performance statistic in EMC literature; I believe EMC did in fact improve *system* performance, and if memory serves me they went from roughly 5000 ops/sec in v1.0 to now 11,000 in v2.0 (for comparisons bear in mind the IP4700 is a two-node cluster); similarly for MB/sec statistic. - disk management is also a point of comparison; IP4700 RAID sets can only be 5- or 9-disks in size; since it is RAID 5, dynamic volume expansion is problematic (as you know) when compared to RAID 4. - snapshot manageability is poor on the IP4700; I believe the snap reserve space is hard-reserved, and in order to change this setting you must first delete all existing snapshots. - the write-cache-to-disk on power outage is a nice feature. Regarding performance Mark Bentley did some independent testing on an IP4700 vs. F840 that he discussed on Toasters last fall. The thread starts here: http://teaparty.mathworks.com:1999/toasters/9889.html ...and I believe he posted results later in the thread. BTW, on a filer if you start with a RAID set consisting of 4x 36GB disks (3 data/1 parity) and add 4x 72 GB disks the resulting RAID set goes something like this: - first 72GB disk added becomes new parity disk; 36GB disk previously used for parity becomes a 36GB data disk - next 72GB disk is only used to 36GB capacity (34GB, actually -- same as the other 36GB disks) - any additional 72GB disks added after that (in this case two more) are used to their full capacity - net result in this case is 4x36GB data disks; 1x72(36)GB parity; 1x72(36)GB data; 2x72GB data Generally, I recommend to create a new RAID set for the 72GB drives. Granted, this will result in two parity disks. However, you gain the following advantages (among many others): - greater reliability, due to smaller RAID sets reducing risk of double-disk failure - simplicity - equivalent capacity to adding the 72GB drives in a single mixed-capacity disk RAID set (net result of half-capacity data disk described above) - less expensive than adding more 36GB disks Joe Joe Luchtenberg Dataline, Inc. Email: joe.luchtenberg(a)data-line.com Phone: 757-457-0504 (direct line) 757-858-0600 (front desk) 757-285-1223 (mobile) Fax: 757-858-0606 Please visit us at www.data-line.com > -----Original Message----- > From: Sam Schorr [mailto:sschorr@homestead-inc.com] > Sent: Wednesday, January 30, 2002 12:42 PM > To: Mr. G. D. Geen; toasters > Subject: RE: IP 4700 vs Netapp > > > G.D. > > Are you sure about the statement that the EMC does not allow NFS and > CIFS on the same volume? When we evaluated the Celerra product (which > I'm guessing is the forerunner of the IP4700), it certainly allowed > for this. If I recall correctly, the underlying file system was UFSx, > and the CIFS was layered on through a version of Samba running on SCO > UNIX (the Celerra controllers). > > --sam > > > -----Original Message----- > From: Mr. G. D. Geen [mailto:geen@ti.com] > Sent: Wednesday, January 30, 2002 9:03 AM > To: toasters > Subject: Re: IP 4700 vs Netapp > > > Good day all, > > I would like to respond to this topic. Though we have no EMC in our > design environment, EMC has made several trips to Texas Instruments to > inform us on their product line. Back in June of 2001, EMC reported > to us on the capabilities of the EMC IP4700 and please let me > know if they > have made updates to the sales pitch since then. > > The IP4700 is said to perform 50K NFS ops/sec. Now this is > good but one > must note that this is using four channels which computes to 12.5K NFS > ops/sec per channel. That is less performance per channel > than a single > F720 NetApp filer. Along the same lines, EMC rated throughput as > 340MB/sec. Again this is using all four channels. > > As for scallability the new NetApp F840 scales just as well -- 12TB > today and 18TB in a new DOT release due this year. This is roughly > equal to that of the IP4700 as stated in June of 2001. > > The IP4700 supports RAID 0, 1, 0+1, and 5 whereas the NetApp is RAID4 > and WAFL file system. I will let you make the call there but I am > happy with the performance of the WAFL system and RAID 4 of the > NetApp. > > The storage processor of the IP4700 consisted of two PIII Celerons. > This may be upgraded by now. > > As for disk usage, I found this to be an interesting concept > but I will > let you decide which is better. On the EMC all disks in a RAID group > must be the same size, no different from NetApp. Upon disk failure, > however, the EMC grabs the first available disk. Now if you have > multiple size disks in your system, the spare disk *must* be of the > largest size you have on your system. On the NetApp, the filer will > grab the smallest spare disk of equal or larger size of the one that > failed. Thus, if you have 36GB and 72GB drives on your NetApp and a > 36GB drive fails, the NetApp will try to find a 36GB spare. If one is > not found then a larger spare will be resized and used as a spare. > > Another interesting point is EMC's spare disk designation. > On an EMC a > spare disk is always a spare disk. If a disk failure were to > occur, the > RAID group will rebuild using a spare disk. Once the failed disk is > replaced, the RAID group is once again rebuilds on to the > replaced disk. > For each disk failure there are two rebuilds of the data. During this > time a filer is most vulnerable to a second disk failure. > There is also > performance degradation during rebuilds. On the NetApp, there is only > one rebuild of the data on to the spare disk. When the faild disk is > replaced, it becomes the spare. > > Some other features of the EMC are mirror root disk, battery > backup, and > write cache mirrored to disk on power outage. The battery > backup of the > EMC is not meant to keep the filer running indefinitely, just long > enough to move the write cashe on to disk and shut down the filer > gracefully. NetApp is using "motor cycle" battaries in F800 series > filers to maintain the NVRAM. Though I have never run in to a problem > where I lost the NVRAM contents due to dead battery, there is > the remote > possibility. > > One other issue, if you are running in a mixed environment, > EMC does not > allow for both NFS and CIFS to be running on the same volume. Both, > though, may be running on the same filer. NetApp does allow > you to run > both NFS and CIFS file systems on the same volume. > > Just some thoughts. > > -gdg > > Rahul Kumar wrote: > > > Hi > > I am also interested in knowing for the same.... > > EMC was recently at our place and they claimed to be faster than > > netapp's like ops /sec etc etc. Their demo box is yet to come. > > If anyone has tested IP4700 let us know > > Thanks > > Rahul > > > > -----Original Message----- > > From: Mike Ball [mailto:MBall@datalink.com] > > Sent: Tuesday, January 29, 2002 8:06 PM > > To: toasters > > Subject: IP 4700 vs Netapp > > > > Has anyone tested a EMC IP 4700 in the last 6 months? EMC > claims they > > have greatly improved the box in the last six months, but I > have not > > been able to > > get any specifics as to what they have done. > > Thank you, > > Mike >

1 0

RE: IP 4700 vs Netapp
by Joe Luchtenberg 30 Jan '02

30 Jan '02

Actually, Mark Bentley's results were not in that thread I linked to earlier. Here's his later post with the results: http://teaparty.mathworks.com:1999/toasters/9944.html Joe > -----Original Message----- > From: Joe Luchtenberg > Sent: Wednesday, January 30, 2002 1:37 PM > To: 'Sam Schorr'; Mr. G. D. Geen; toasters > Subject: RE: IP 4700 vs Netapp > > > Celerra is most certainly not the forerunner of the IP4700 > (although it did precede the "Chameliion"). Celerra is a > network attached front end EMC offers to Symmetrix customers > to provide a NAS interface to the SYM. The IP4700 is a > purely NAS device built on a h/w platform from the DG > acquisition married to a NAS OS developed from the CrosStor > acquisition. Both NAS products are current EMC offerings. > > As to Mr. Geen's points: > - the 50K ops/sec if I understand correctly is a measure of > the memory to network mapping performance (remember the > BlueArc threads of several months ago); you will find this > performance statistic in EMC literature; I believe EMC did in > fact improve *system* performance, and if memory serves me > they went from roughly 5000 ops/sec in v1.0 to now 11,000 in > v2.0 (for comparisons bear in mind the IP4700 is a two-node > cluster); similarly for MB/sec statistic. > - disk management is also a point of comparison; IP4700 RAID > sets can only be 5- or 9-disks in size; since it is RAID 5, > dynamic volume expansion is problematic (as you know) when > compared to RAID 4. > - snapshot manageability is poor on the IP4700; I believe the > snap reserve space is hard-reserved, and in order to change > this setting you must first delete all existing snapshots. > - the write-cache-to-disk on power outage is a nice feature. > > Regarding performance Mark Bentley did some independent > testing on an IP4700 vs. F840 that he discussed on Toasters > last fall. The thread starts here: > http://teaparty.mathworks.com:1999/toasters/9889.html > ...and I believe he posted results later in the thread. > > BTW, on a filer if you start with a RAID set consisting of 4x > 36GB disks (3 data/1 parity) and add 4x 72 GB disks the > resulting RAID set goes something like this: > - first 72GB disk added becomes new parity disk; 36GB disk > previously used for parity becomes a 36GB data disk > - next 72GB disk is only used to 36GB capacity (34GB, > actually -- same as the other 36GB disks) > - any additional 72GB disks added after that (in this case > two more) are used to their full capacity > - net result in this case is 4x36GB data disks; 1x72(36)GB > parity; 1x72(36)GB data; 2x72GB data > > Generally, I recommend to create a new RAID set for the 72GB > drives. Granted, this will result in two parity disks. > However, you gain the following advantages (among many others): > - greater reliability, due to smaller RAID sets reducing risk > of double-disk failure > - simplicity > - equivalent capacity to adding the 72GB drives in a single > mixed-capacity disk RAID set (net result of half-capacity > data disk described above) > - less expensive than adding more 36GB disks > > Joe > > > Joe Luchtenberg > Dataline, Inc. > > Email: joe.luchtenberg(a)data-line.com > Phone: 757-457-0504 (direct line) > 757-858-0600 (front desk) > 757-285-1223 (mobile) > Fax: 757-858-0606 > > Please visit us at www.data-line.com > > > > -----Original Message----- > > From: Sam Schorr [mailto:sschorr@homestead-inc.com] > > Sent: Wednesday, January 30, 2002 12:42 PM > > To: Mr. G. D. Geen; toasters > > Subject: RE: IP 4700 vs Netapp > > > > > > G.D. > > > > Are you sure about the statement that the EMC does not allow NFS and > > CIFS on the same volume? When we evaluated the Celerra > product (which > > I'm guessing is the forerunner of the IP4700), it certainly > > allowed for > > this. If I recall correctly, the underlying file system > was UFSx, and > > the CIFS was layered on through a version of Samba running > on SCO UNIX > > (the Celerra controllers). > > > > --sam > > > > > > -----Original Message----- > > From: Mr. G. D. Geen [mailto:geen@ti.com] > > Sent: Wednesday, January 30, 2002 9:03 AM > > To: toasters > > Subject: Re: IP 4700 vs Netapp > > > > > > Good day all, > > > > I would like to respond to this topic. Though we have no EMC in our > > design environment, EMC has made several trips to Texas > Instruments to > > inform us on their product line. Back in June of 2001, EMC > > reported to > > us on the capabilities of the EMC IP4700 and please let me > > know if they > > have made updates to the sales pitch since then. > > > > The IP4700 is said to perform 50K NFS ops/sec. Now this is > > good but one > > must note that this is using four channels which computes > to 12.5K NFS > > ops/sec per channel. That is less performance per channel > > than a single > > F720 NetApp filer. Along the same lines, EMC rated throughput as > > 340MB/sec. Again this is using all four channels. > > > > As for scallability the new NetApp F840 scales just as well -- 12TB > > today and 18TB in a new DOT release due this year. This is roughly > > equal to that of the IP4700 as stated in June of 2001. > > > > The IP4700 supports RAID 0, 1, 0+1, and 5 whereas the > NetApp is RAID4 > > and WAFL file system. I will let you make the call there but > > I am happy > > with the performance of the WAFL system and RAID 4 of the NetApp. > > > > The storage processor of the IP4700 consisted of two PIII Celerons. > > This may be upgraded by now. > > > > As for disk usage, I found this to be an interesting concept > > but I will > > let you decide which is better. On the EMC all disks in a RAID group > > must be the same size, no different from NetApp. Upon disk failure, > > however, the EMC grabs the first available disk. Now if you have > > multiple size disks in your system, the spare disk *must* be of the > > largest size you have on your system. On the NetApp, the filer will > > grab the smallest spare disk of equal or larger size of the one that > > failed. Thus, if you have 36GB and 72GB drives on your NetApp and a > > 36GB drive fails, the NetApp will try to find a 36GB spare. > If one is > > not found then a larger spare will be resized and used as a spare. > > > > Another interesting point is EMC's spare disk designation. > > On an EMC a > > spare disk is always a spare disk. If a disk failure were to > > occur, the > > RAID group will rebuild using a spare disk. Once the failed disk is > > replaced, the RAID group is once again rebuilds on to the > > replaced disk. > > For each disk failure there are two rebuilds of the data. > During this > > time a filer is most vulnerable to a second disk failure. > > There is also > > performance degradation during rebuilds. On the NetApp, > there is only > > one rebuild of the data on to the spare disk. When the > faild disk is > > replaced, it becomes the spare. > > > > Some other features of the EMC are mirror root disk, battery > > backup, and > > write cache mirrored to disk on power outage. The battery > > backup of the > > EMC is not meant to keep the filer running indefinitely, just long > > enough to move the write cashe on to disk and shut down the filer > > gracefully. NetApp is using "motor cycle" battaries in F800 series > > filers to maintain the NVRAM. Though I have never run in > to a problem > > where I lost the NVRAM contents due to dead battery, there is > > the remote > > possibility. > > > > One other issue, if you are running in a mixed environment, > > EMC does not > > allow for both NFS and CIFS to be running on the same volume. Both, > > though, may be running on the same filer. NetApp does allow > > you to run > > both NFS and CIFS file systems on the same volume. > > > > Just some thoughts. > > > > -gdg > > > > Rahul Kumar wrote: > > > > > Hi > > > I am also interested in knowing for the same.... > > > EMC was recently at our place and they claimed to be faster than > > > netapp's like ops /sec etc etc. Their demo box is yet to come. > > > If anyone has tested IP4700 let us know > > > Thanks > > > Rahul > > > > > > -----Original Message----- > > > From: Mike Ball [mailto:MBall@datalink.com] > > > Sent: Tuesday, January 29, 2002 8:06 PM > > > To: toasters > > > Subject: IP 4700 vs Netapp > > > > > > Has anyone tested a EMC IP 4700 in the last 6 months? EMC > > claims they > > > have greatly improved the box in the last six months, but I > > have not > > > been able to > > > get any specifics as to what they have done. > > > Thank you, > > > Mike > > >

1 0

RE: IP 4700 vs Netapp
by Joe Luchtenberg 30 Jan '02

30 Jan '02

Celerra is most certainly not the forerunner of the IP4700 (although it did precede the "Chameliion"). Celerra is a network attached front end EMC offers to Symmetrix customers to provide a NAS interface to the SYM. The IP4700 is a purely NAS device built on a h/w platform from the DG acquisition married to a NAS OS developed from the CrosStor acquisition. Both NAS products are current EMC offerings. As to Mr. Geen's points: - the 50K ops/sec if I understand correctly is a measure of the memory to network mapping performance (remember the BlueArc threads of several months ago); you will find this performance statistic in EMC literature; I believe EMC did in fact improve *system* performance, and if memory serves me they went from roughly 5000 ops/sec in v1.0 to now 11,000 in v2.0 (for comparisons bear in mind the IP4700 is a two-node cluster); similarly for MB/sec statistic. - disk management is also a point of comparison; IP4700 RAID sets can only be 5- or 9-disks in size; since it is RAID 5, dynamic volume expansion is problematic (as you know) when compared to RAID 4. - snapshot manageability is poor on the IP4700; I believe the snap reserve space is hard-reserved, and in order to change this setting you must first delete all existing snapshots. - the write-cache-to-disk on power outage is a nice feature. Regarding performance Mark Bentley did some independent testing on an IP4700 vs. F840 that he discussed on Toasters last fall. The thread starts here: http://teaparty.mathworks.com:1999/toasters/9889.html ...and I believe he posted results later in the thread. BTW, on a filer if you start with a RAID set consisting of 4x 36GB disks (3 data/1 parity) and add 4x 72 GB disks the resulting RAID set goes something like this: - first 72GB disk added becomes new parity disk; 36GB disk previously used for parity becomes a 36GB data disk - next 72GB disk is only used to 36GB capacity (34GB, actually -- same as the other 36GB disks) - any additional 72GB disks added after that (in this case two more) are used to their full capacity - net result in this case is 4x36GB data disks; 1x72(36)GB parity; 1x72(36)GB data; 2x72GB data Generally, I recommend to create a new RAID set for the 72GB drives. Granted, this will result in two parity disks. However, you gain the following advantages (among many others): - greater reliability, due to smaller RAID sets reducing risk of double-disk failure - simplicity - equivalent capacity to adding the 72GB drives in a single mixed-capacity disk RAID set (net result of half-capacity data disk described above) - less expensive than adding more 36GB disks Joe Joe Luchtenberg Dataline, Inc. Email: joe.luchtenberg(a)data-line.com Phone: 757-457-0504 (direct line) 757-858-0600 (front desk) 757-285-1223 (mobile) Fax: 757-858-0606 Please visit us at www.data-line.com > -----Original Message----- > From: Sam Schorr [mailto:sschorr@homestead-inc.com] > Sent: Wednesday, January 30, 2002 12:42 PM > To: Mr. G. D. Geen; toasters > Subject: RE: IP 4700 vs Netapp > > > G.D. > > Are you sure about the statement that the EMC does not allow NFS and > CIFS on the same volume? When we evaluated the Celerra product (which > I'm guessing is the forerunner of the IP4700), it certainly > allowed for > this. If I recall correctly, the underlying file system was UFSx, and > the CIFS was layered on through a version of Samba running on SCO UNIX > (the Celerra controllers). > > --sam > > > -----Original Message----- > From: Mr. G. D. Geen [mailto:geen@ti.com] > Sent: Wednesday, January 30, 2002 9:03 AM > To: toasters > Subject: Re: IP 4700 vs Netapp > > > Good day all, > > I would like to respond to this topic. Though we have no EMC in our > design environment, EMC has made several trips to Texas Instruments to > inform us on their product line. Back in June of 2001, EMC > reported to > us on the capabilities of the EMC IP4700 and please let me > know if they > have made updates to the sales pitch since then. > > The IP4700 is said to perform 50K NFS ops/sec. Now this is > good but one > must note that this is using four channels which computes to 12.5K NFS > ops/sec per channel. That is less performance per channel > than a single > F720 NetApp filer. Along the same lines, EMC rated throughput as > 340MB/sec. Again this is using all four channels. > > As for scallability the new NetApp F840 scales just as well -- 12TB > today and 18TB in a new DOT release due this year. This is roughly > equal to that of the IP4700 as stated in June of 2001. > > The IP4700 supports RAID 0, 1, 0+1, and 5 whereas the NetApp is RAID4 > and WAFL file system. I will let you make the call there but > I am happy > with the performance of the WAFL system and RAID 4 of the NetApp. > > The storage processor of the IP4700 consisted of two PIII Celerons. > This may be upgraded by now. > > As for disk usage, I found this to be an interesting concept > but I will > let you decide which is better. On the EMC all disks in a RAID group > must be the same size, no different from NetApp. Upon disk failure, > however, the EMC grabs the first available disk. Now if you have > multiple size disks in your system, the spare disk *must* be of the > largest size you have on your system. On the NetApp, the filer will > grab the smallest spare disk of equal or larger size of the one that > failed. Thus, if you have 36GB and 72GB drives on your NetApp and a > 36GB drive fails, the NetApp will try to find a 36GB spare. If one is > not found then a larger spare will be resized and used as a spare. > > Another interesting point is EMC's spare disk designation. > On an EMC a > spare disk is always a spare disk. If a disk failure were to > occur, the > RAID group will rebuild using a spare disk. Once the failed disk is > replaced, the RAID group is once again rebuilds on to the > replaced disk. > For each disk failure there are two rebuilds of the data. During this > time a filer is most vulnerable to a second disk failure. > There is also > performance degradation during rebuilds. On the NetApp, there is only > one rebuild of the data on to the spare disk. When the faild disk is > replaced, it becomes the spare. > > Some other features of the EMC are mirror root disk, battery > backup, and > write cache mirrored to disk on power outage. The battery > backup of the > EMC is not meant to keep the filer running indefinitely, just long > enough to move the write cashe on to disk and shut down the filer > gracefully. NetApp is using "motor cycle" battaries in F800 series > filers to maintain the NVRAM. Though I have never run in to a problem > where I lost the NVRAM contents due to dead battery, there is > the remote > possibility. > > One other issue, if you are running in a mixed environment, > EMC does not > allow for both NFS and CIFS to be running on the same volume. Both, > though, may be running on the same filer. NetApp does allow > you to run > both NFS and CIFS file systems on the same volume. > > Just some thoughts. > > -gdg > > Rahul Kumar wrote: > > > Hi > > I am also interested in knowing for the same.... > > EMC was recently at our place and they claimed to be faster than > > netapp's like ops /sec etc etc. Their demo box is yet to come. > > If anyone has tested IP4700 let us know > > Thanks > > Rahul > > > > -----Original Message----- > > From: Mike Ball [mailto:MBall@datalink.com] > > Sent: Tuesday, January 29, 2002 8:06 PM > > To: toasters > > Subject: IP 4700 vs Netapp > > > > Has anyone tested a EMC IP 4700 in the last 6 months? EMC > claims they > > have greatly improved the box in the last six months, but I > have not > > been able to > > get any specifics as to what they have done. > > Thank you, > > Mike >

1 0

CIFS Performance.
by Geert Jackers 30 Jan '02

30 Jan '02

Hi, we have F740 and F820 running only CIFS. We hear everywhere that the performance is great of these boxes. We installed the latest 6.1.1R2 (I think) which would solve some problems with virusscanning (trendmicro) on the boxes and clients. When we read a file (doc file) it is somewhat fast, but when we save it it takes twice as long as on a NT box. When we do the same with a RTF file....or TXT it is much faster. Not to say when opening or working with outlook and .pst files on that share, it takes forever.....almost. We see that when we open a file on the box a ~file is created on the same directory too, can this have an influence ? A copy from a file to and from the box....also slow. We have a 100 Mbit switched network and 1 Gbit links to the filers....other traffic on the network is fast etc. We disabled viruschecking on the filer and the pc's...no difference. Do we need to tune or set special parameters on the filer ? Somebody has had the same experience....? Please any info is appreciated. Geert Geert Jackers Siemens Business Services Belgium

1 0

Jump to page:

2026

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