toasters

toasters@lists.teaparty.net

13514 discussions

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

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

30 Jan '02

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

2 1

RE: IP 4700 vs Netapp
by Rahul Kumar 30 Jan '02

30 Jan '02

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

5 4

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