toasters

toasters@lists.teaparty.net

13517 discussions

RE: Estimating Aggregate IOPS
by Suresh Rajagopalan 05 Oct '06

05 Oct '06

I see max drives per FC loop to be 84 on all filer models. Is this the limit you are alluding to? Thanks Suresh -----Original Message----- From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Wednesday, October 04, 2006 3:57 PM To: Suresh Rajagopalan Cc: toasters(a)mathworks.com Subject: RE: Estimating Aggregate IOPS There is a ceiling in performance gain after a certain number of disks - it's well below 112, but I'm pretty sure it's above 56 (though not much above it). At that point, the 'curve' starts to go back down again. However, RAID-DP and RAID-4 (it's poor, homely cousin) are very fast and the filer has always handled the XORs very well for the parity calculations. A better question\way to position this might be what type of workload\performance you expect\require. While the disks are capable of about 120 IOPS for 10k and 180 IOPS for 15K disks, the latencies begin to jump at the end of the scale - if you're workload requires lower latencies, it doesn't much matter what the disk is capable of (Exchange is a very good example of this - 80 IOPS for 10k drives is about the max you'd want to go). Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Suresh Rajagopalan Sent: Wednesday, October 04, 2006 3:56 PM Cc: toasters(a)mathworks.com Subject: RE: Estimating Aggregate IOPS Let's assume 4k IOPS. Disks are currently 10k rpm. Are you saying that NTAP's implementation of RAID4 (or RAID-DP) gives a linear performance increase with spindles, (almost like RAID-0) and no penalty for the RAID4 or RAID-DP? That is, aggregate IOPS is pretty much (N * disk-iops) and no penalty for RAID4 or RAID-DP? Thanks Suresh -----Original Message----- From: Blake Golliher [mailto:thelastman@gmail.com] Sent: Wednesday, October 04, 2006 12:41 PM To: Suresh Rajagopalan Cc: toasters(a)mathworks.com Subject: Re: Estimating Aggregate IOPS How fast are the spindles, and what size is your iop? Generally, you can assume 110 per 10k RPM disk, and 180 for 15k RPM disk. This is also assuming a 10ms latency for each iop. And subtract 2 disks per raid group for raid dp (if doing writes, don't if you are doing pure reads). So with around 50 disks (after you subtract the raid dp overhead) you can expect around 5500 iops from that set of disks (assuming 10k rpm disks). For the 112 aggregate, you an expect 98 spindles and 10780 iops. I'm assuming 4k iops, and 10ms latency. Hope that helps, -Blake On 10/4/06, Suresh Rajagopalan <SRajagopalan(a)williamoneil.com> wrote: > Given a disk IOPS of 100, I'd like to estimate total aggregate IOPS for > the following cases: > > 1) 56 disks, 1 aggregate, RAID-DP size 16 > 2) 112 disks, 1 aggregate, RAID-DP size 16 > > I'm only interested in the total raw disk IOPS available in each case, > not including considering the filer head. For example, we know that > RAID-0 with 56 disks @100 would yield 5600 IOPS. > > I don't know how to do this calculation with Data ONTAP's implementation > of RAID4 or RAID-DP. > > Any assistance would help. > > Thanks > Suresh > > > > >

1 0

RE: Estimating Aggregate IOPS
by Glenn Walker 05 Oct '06

05 Oct '06

That's not just a NetApp thing... that's performance 101! There will ALWAYS be a bottleneck somewhere - if you want to 'fix' a performance problem, find the first bottleneck, and fix it. Then the next, and so on. Keep going until the performance is adequate... I've seen very few cases where the loop itself gets saturated before the head gives up, or the memory runs out... but it can happen. I expect that it will happen even more quickly with the new 6000 series given the sheer amount of memory\nvram\cpu. Then again, 500TB of disks is a LOT of loop too :) Glenn -----Original Message----- From: Brosseau, Paul [mailto:Paul.Brosseau@netapp.com] Sent: Wednesday, October 04, 2006 8:17 PM To: Glenn Walker; Suresh Rajagopalan Cc: toasters(a)mathworks.com Subject: RE: Estimating Aggregate IOPS Good point Glenn on the number of disks. Once the number of IOPS on a loops generates enough throughput to saturate the loop there's not much point in adding more disks. Spreading the load across multiple loops helps. How does the adage go " go wide then go shallow then go deep ". Eventually you saturate something somewhere depending on the filer model . Paulb -----Original Message----- From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Wednesday, October 04, 2006 6:57 PM To: Suresh Rajagopalan Cc: toasters(a)mathworks.com Subject: RE: Estimating Aggregate IOPS There is a ceiling in performance gain after a certain number of disks - it's well below 112, but I'm pretty sure it's above 56 (though not much above it). At that point, the 'curve' starts to go back down again. However, RAID-DP and RAID-4 (it's poor, homely cousin) are very fast and the filer has always handled the XORs very well for the parity calculations. A better question\way to position this might be what type of workload\performance you expect\require. While the disks are capable of about 120 IOPS for 10k and 180 IOPS for 15K disks, the latencies begin to jump at the end of the scale - if you're workload requires lower latencies, it doesn't much matter what the disk is capable of (Exchange is a very good example of this - 80 IOPS for 10k drives is about the max you'd want to go). Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Suresh Rajagopalan Sent: Wednesday, October 04, 2006 3:56 PM Cc: toasters(a)mathworks.com Subject: RE: Estimating Aggregate IOPS Let's assume 4k IOPS. Disks are currently 10k rpm. Are you saying that NTAP's implementation of RAID4 (or RAID-DP) gives a linear performance increase with spindles, (almost like RAID-0) and no penalty for the RAID4 or RAID-DP? That is, aggregate IOPS is pretty much (N * disk-iops) and no penalty for RAID4 or RAID-DP? Thanks Suresh -----Original Message----- From: Blake Golliher [mailto:thelastman@gmail.com] Sent: Wednesday, October 04, 2006 12:41 PM To: Suresh Rajagopalan Cc: toasters(a)mathworks.com Subject: Re: Estimating Aggregate IOPS How fast are the spindles, and what size is your iop? Generally, you can assume 110 per 10k RPM disk, and 180 for 15k RPM disk. This is also assuming a 10ms latency for each iop. And subtract 2 disks per raid group for raid dp (if doing writes, don't if you are doing pure reads). So with around 50 disks (after you subtract the raid dp overhead) you can expect around 5500 iops from that set of disks (assuming 10k rpm disks). For the 112 aggregate, you an expect 98 spindles and 10780 iops. I'm assuming 4k iops, and 10ms latency. Hope that helps, -Blake On 10/4/06, Suresh Rajagopalan <SRajagopalan(a)williamoneil.com> wrote: > Given a disk IOPS of 100, I'd like to estimate total aggregate IOPS for > the following cases: > > 1) 56 disks, 1 aggregate, RAID-DP size 16 > 2) 112 disks, 1 aggregate, RAID-DP size 16 > > I'm only interested in the total raw disk IOPS available in each case, > not including considering the filer head. For example, we know that > RAID-0 with 56 disks @100 would yield 5600 IOPS. > > I don't know how to do this calculation with Data ONTAP's implementation > of RAID4 or RAID-DP. > > Any assistance would help. > > Thanks > Suresh > > > > >

1 0

RE: Estimating Aggregate IOPS
by Brosseau, Paul 05 Oct '06

05 Oct '06

Good point Glenn on the number of disks. Once the number of IOPS on a loops generates enough throughput to saturate the loop there's not much point in adding more disks. Spreading the load across multiple loops helps. How does the adage go " go wide then go shallow then go deep ". Eventually you saturate something somewhere depending on the filer model . Paulb -----Original Message----- From: Glenn Walker [mailto:ggwalker@mindspring.com] Sent: Wednesday, October 04, 2006 6:57 PM To: Suresh Rajagopalan Cc: toasters(a)mathworks.com Subject: RE: Estimating Aggregate IOPS There is a ceiling in performance gain after a certain number of disks - it's well below 112, but I'm pretty sure it's above 56 (though not much above it). At that point, the 'curve' starts to go back down again. However, RAID-DP and RAID-4 (it's poor, homely cousin) are very fast and the filer has always handled the XORs very well for the parity calculations. A better question\way to position this might be what type of workload\performance you expect\require. While the disks are capable of about 120 IOPS for 10k and 180 IOPS for 15K disks, the latencies begin to jump at the end of the scale - if you're workload requires lower latencies, it doesn't much matter what the disk is capable of (Exchange is a very good example of this - 80 IOPS for 10k drives is about the max you'd want to go). Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Suresh Rajagopalan Sent: Wednesday, October 04, 2006 3:56 PM Cc: toasters(a)mathworks.com Subject: RE: Estimating Aggregate IOPS Let's assume 4k IOPS. Disks are currently 10k rpm. Are you saying that NTAP's implementation of RAID4 (or RAID-DP) gives a linear performance increase with spindles, (almost like RAID-0) and no penalty for the RAID4 or RAID-DP? That is, aggregate IOPS is pretty much (N * disk-iops) and no penalty for RAID4 or RAID-DP? Thanks Suresh -----Original Message----- From: Blake Golliher [mailto:thelastman@gmail.com] Sent: Wednesday, October 04, 2006 12:41 PM To: Suresh Rajagopalan Cc: toasters(a)mathworks.com Subject: Re: Estimating Aggregate IOPS How fast are the spindles, and what size is your iop? Generally, you can assume 110 per 10k RPM disk, and 180 for 15k RPM disk. This is also assuming a 10ms latency for each iop. And subtract 2 disks per raid group for raid dp (if doing writes, don't if you are doing pure reads). So with around 50 disks (after you subtract the raid dp overhead) you can expect around 5500 iops from that set of disks (assuming 10k rpm disks). For the 112 aggregate, you an expect 98 spindles and 10780 iops. I'm assuming 4k iops, and 10ms latency. Hope that helps, -Blake On 10/4/06, Suresh Rajagopalan <SRajagopalan(a)williamoneil.com> wrote: > Given a disk IOPS of 100, I'd like to estimate total aggregate IOPS for > the following cases: > > 1) 56 disks, 1 aggregate, RAID-DP size 16 > 2) 112 disks, 1 aggregate, RAID-DP size 16 > > I'm only interested in the total raw disk IOPS available in each case, > not including considering the filer head. For example, we know that > RAID-0 with 56 disks @100 would yield 5600 IOPS. > > I don't know how to do this calculation with Data ONTAP's implementation > of RAID4 or RAID-DP. > > Any assistance would help. > > Thanks > Suresh > > > > >

1 0

Re: Estimating Aggregate IOPS
by Blake Golliher 04 Oct '06

04 Oct '06

Glenn is very much correct here. The application will dictate what your upper limit will be. A highly sequential Oracle workload will different greatly from a 5000 user exchange cluster. That curve in raid groups is around 20 disks in my experience. Eventually you'll run out of head room for the number of disks you've attached. -Blake On 10/4/06, Glenn Walker <ggwalker(a)mindspring.com> wrote: > There is a ceiling in performance gain after a certain number of disks > it's well below 112, but I'm pretty sure it's above 56 (though not much > above it). At that point, the 'curve' starts to go back down again. > > However, RAID-DP and RAID-4 (it's poor, homely cousin) are very fast and > the filer has always handled the XORs very well for the parity > calculations. > > A better question\way to position this might be what type of > workload\performance you expect\require. While the disks are capable of > about 120 IOPS for 10k and 180 IOPS for 15K disks, the latencies begin > to jump at the end of the scale - if you're workload requires lower > latencies, it doesn't much matter what the disk is capable of (Exchange > is a very good example of this - 80 IOPS for 10k drives is about the max > you'd want to go). > > Glenn > > -----Original Message----- > From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] > On Behalf Of Suresh Rajagopalan > Sent: Wednesday, October 04, 2006 3:56 PM > Cc: toasters(a)mathworks.com > Subject: RE: Estimating Aggregate IOPS > > Let's assume 4k IOPS. Disks are currently 10k rpm. > > Are you saying that NTAP's implementation of RAID4 (or RAID-DP) gives a > linear performance increase with spindles, (almost like RAID-0) and no > penalty for the RAID4 or RAID-DP? > > That is, aggregate IOPS is pretty much (N * disk-iops) and no penalty > for RAID4 or RAID-DP? > > Thanks > Suresh > > > > -----Original Message----- > From: Blake Golliher [mailto:thelastman@gmail.com] > Sent: Wednesday, October 04, 2006 12:41 PM > To: Suresh Rajagopalan > Cc: toasters(a)mathworks.com > Subject: Re: Estimating Aggregate IOPS > > How fast are the spindles, and what size is your iop? Generally, you > can assume 110 per 10k RPM disk, and 180 for 15k RPM disk. This is > also assuming a 10ms latency for each iop. And subtract 2 disks per > raid group for raid dp (if doing writes, don't if you are doing pure > reads). So with around 50 disks (after you subtract the raid dp > overhead) you can expect around 5500 iops from that set of disks > (assuming 10k rpm disks). For the 112 aggregate, you an expect 98 > spindles > and 10780 iops. I'm assuming 4k iops, and 10ms latency. > > Hope that helps, > -Blake > > > On 10/4/06, Suresh Rajagopalan <SRajagopalan(a)williamoneil.com> wrote: > > Given a disk IOPS of 100, I'd like to estimate total aggregate IOPS > for > > the following cases: > > > > 1) 56 disks, 1 aggregate, RAID-DP size 16 > > 2) 112 disks, 1 aggregate, RAID-DP size 16 > > > > I'm only interested in the total raw disk IOPS available in each case, > > not including considering the filer head. For example, we know > that > > RAID-0 with 56 disks @100 would yield 5600 IOPS. > > > > I don't know how to do this calculation with Data ONTAP's > implementation > > of RAID4 or RAID-DP. > > > > Any assistance would help. > > > > Thanks > > Suresh > > > > > > > > > > > > >

1 0

RE: Maximum throughput of a FAS270c
by Glenn Walker 04 Oct '06

04 Oct '06

Yup... Pretty capable machine for 500 users or so. Depends on workload, as Blake said, it's OPS\CPU limited. 940 is a beast by comparison - probably about 2-2.5 times as fast. Glenn -----Original Message----- From: Blake Golliher [mailto:thelastman@gmail.com] Sent: Wednesday, October 04, 2006 3:44 PM To: John Stoffel Cc: Grey Friday; Glenn Walker; Brian Pascal; toasters(a)mathworks.com Subject: Re: Maximum throughput of a FAS270c I'd say an F840 (I think that's what Glenn was suggesting). The 270 is an op limited machine. Dual core 650Mhz processor, and a gig of ram (subtract 256 for NVMEM) and you get a pretty limited box in terms of performance. A 940 has a 1.8 ghz proc 4 or so gigs of memory, and a dedicated nvram card. Much better performance box. But a 270 wasn't marketed as a very fast box, but a very small, cheap box for small & remote offices. -Blake On 10/4/06, John Stoffel <john.stoffel(a)taec.toshiba.com> wrote: > >>>>> "Grey" == Grey Friday <grey.friday(a)gmail.com> writes: > > Grey> http://www.spec.org/sfs97r1/results/res2004q2/sfs97r1-20040525-00186.htm l > Grey> On 10/3/06, Glenn Walker <ggwalker(a)mindspring.com> wrote: > Grey> Brian, > >> > >> Those numbers are deemed NetApp Internal Only - though I believe that > >> Sales can share some info with you. > >> > >> However this might help: a FAS270c is equivalent to a NetApp F840 > >> system with respect to throughputhorsepower. Maybe just a tad faster > >> even. > > Glenn, > > Just to be sure, you're talking about an F840 is roughtly equivilent > to an FAS270, right? Not an F940? > > John > PM disk. This is also assuming a 10ms latency for each iop. And subtract 2 disks per raid group for raid dp (if doing writes, don't if you are doing pure reads). So with around 50 disks (after you subtract the raid dp overhead) you can expect around 5500 iops from that set of disks (assuming 10k rpm disks). For the 112 aggregate, you an expect 98 spindles and 10780 iops. I'm assuming 4k iops, and 10ms latency. Hope that helps, -Blake On 10/4/06, Suresh Rajagopalan <SRajagopalan(a)williamoneil.com> wrote: > Given a disk IOPS of 100, I'd like to estimate total aggregate IOPS for > the following cases: > > 1) 56 disks, 1 aggregate, RAID-DP size 16 > 2) 112 disks, 1 aggregate, RAID-DP size 16 > > I'm only interested in the total raw disk IOPS available in each case, > not including considering the filer head. For example, we know that > RAID-0 with 56 disks @100 would yield 5600 IOPS. > > I don't know how to do this calculation with Data ONTAP's implementation > of RAID4 or RAID-DP. > > Any assistance would help. > > Thanks > Suresh > > > > >

1 0

RE: Estimating Aggregate IOPS
by Suresh Rajagopalan 04 Oct '06

04 Oct '06

Let's assume 4k IOPS. Disks are currently 10k rpm. Are you saying that NTAP's implementation of RAID4 (or RAID-DP) gives a linear performance increase with spindles, (almost like RAID-0) and no penalty for the RAID4 or RAID-DP? That is, aggregate IOPS is pretty much (N * disk-iops) and no penalty for RAID4 or RAID-DP? Thanks Suresh -----Original Message----- From: Blake Golliher [mailto:thelastman@gmail.com] Sent: Wednesday, October 04, 2006 12:41 PM To: Suresh Rajagopalan Cc: toasters(a)mathworks.com Subject: Re: Estimating Aggregate IOPS How fast are the spindles, and what size is your iop? Generally, you can assume 110 per 10k RPM disk, and 180 for 15k RPM disk. This is also assuming a 10ms latency for each iop. And subtract 2 disks per raid group for raid dp (if doing writes, don't if you are doing pure reads). So with around 50 disks (after you subtract the raid dp overhead) you can expect around 5500 iops from that set of disks (assuming 10k rpm disks). For the 112 aggregate, you an expect 98 spindles and 10780 iops. I'm assuming 4k iops, and 10ms latency. Hope that helps, -Blake On 10/4/06, Suresh Rajagopalan <SRajagopalan(a)williamoneil.com> wrote: > Given a disk IOPS of 100, I'd like to estimate total aggregate IOPS for > the following cases: > > 1) 56 disks, 1 aggregate, RAID-DP size 16 > 2) 112 disks, 1 aggregate, RAID-DP size 16 > > I'm only interested in the total raw disk IOPS available in each case, > not including considering the filer head. For example, we know that > RAID-0 with 56 disks @100 would yield 5600 IOPS. > > I don't know how to do this calculation with Data ONTAP's implementation > of RAID4 or RAID-DP. > > Any assistance would help. > > Thanks > Suresh > > > > >

1 0

RE: Maximum throughput of a FAS270c
by Glenn Walker 04 Oct '06

04 Oct '06

Brian, Those numbers are deemed NetApp Internal Only - though I believe that Sales can share some info with you. However this might help: a FAS270c is equivalent to a NetApp F840 system with respect to throughput\horsepower. Maybe just a tad faster even. Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Brian Pascal Sent: Tuesday, October 03, 2006 1:37 AM To: toasters(a)mathworks.com Subject: Maximum throughput of a FAS270c Does any one has an idea of what is the maximum throughput of a FAS270c system? (Sustained system bandwidth & IOPS) Thanks, Brian. This Mail Has Been Scanned For Virus By Scanmail For Lotus Notes Enterprise/Kbsl

5 5

Estimating Aggregate IOPS
by Suresh Rajagopalan 04 Oct '06

04 Oct '06

Given a disk IOPS of 100, I'd like to estimate total aggregate IOPS for the following cases: 1) 56 disks, 1 aggregate, RAID-DP size 16 2) 112 disks, 1 aggregate, RAID-DP size 16 I'm only interested in the total raw disk IOPS available in each case, not including considering the filer head. For example, we know that RAID-0 with 56 disks @100 would yield 5600 IOPS. I don't know how to do this calculation with Data ONTAP's implementation of RAID4 or RAID-DP. Any assistance would help. Thanks Suresh

3 2

Maximum throughput of a FAS270c
by Brian Pascal 03 Oct '06

03 Oct '06

Does any one has an idea of what is the maximum throughput of a FAS270c system? (Sustained system bandwidth & IOPS) Thanks, Brian. This Mail Has Been Scanned For Virus By Scanmail For Lotus Notes Enterprise/Kbsl

1 0

RE: Response time measurement
by Willeke, Jochen 29 Sep '06

29 Sep '06

Hi, its me again thinking about measurement of response time. I have a new idea and just wanted to hear from you what you think about it. I am running a dd with a bs of 8k/4k against a fileserver for a couple of minutes and during different daytimes. While the dd is running i do capture the networkstream and create a statistic for NFSv3-ops tetherreal -i eth0 -z rpc,100003,3 This gives me an overview of the RTT's during this run of dd. What do you think about this method? I can use sio as well for generating random IO but the method will remain the same. Best Regards and thanks in advance for any opinions on that Jochen ________________________________ From: Miller, James [mailto:James.Miller@netapp.com] Sent: Friday, September 22, 2006 7:27 PM To: Willeke, Jochen Subject: Re: Response time measurement Isn't it 8.72ms or .00872secs ... Jim Miller sent from blackberry -----Original Message----- From: Willeke, Jochen <Jochen.Willeke(a)wincor-nixdorf.com> To: NetApp Toasters List <toasters(a)mathworks.com> Sent: Fri Sep 22 08:13:05 2006 Subject: Response time measurement Hi folks, i am still thinking about some figures which help me considering different fileservers. After doing some research i think one point is the response time given by the system. I did a lot of testing with sio and but the results i got are some kind of strange. A test with SIO e.g. brings following result: ./sio_ntap_linux 100 0 8k 100m 10 1 /mnt/test15 Version: 3.00 SIO_NTAP: Inputs Read %: 100 Random %: 0 Block Size: 8192 File Size: 104857600 Secs: 10 Threads: 1 File(s): /mnt/test15 Outputs IOPS: 114578 KB/s: 916626 IOs: 1145782 Terminating threads ...Killed First there are the KB/S. Much to fast even for a 1Gbit network. And the second is the response time. I calculated the following: 1s / 114578 (IOPS) = 0,00872 ms (response time) This cannot be true at all :-) Does SIO read the same block all the time (due to 0%random read), or do i have any kind of mistake in my test?!? Perhaps someone can help. Best Regards and a nice weekend Jochen

3 4

RE: Can we use clearcase with FAS6xxx Ontap 7.2?
by Glenn Walker 28 Sep '06

28 Sep '06

SW, if 7.1.x is supported with Clearcase, then I'm sure 7.2 is as well. It just hasn't been officially 'tested'. That said, while 7.2 has some major feature enhancements, ONTAP still functions pretty much the same with respect to client connectivity for all protocols. Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of G SW Sent: Wednesday, September 27, 2006 10:22 PM To: toasters(a)mathworks.com Subject: Can we use clearcase with FAS6xxx Ontap 7.2? Halo.. We are using FAS960 with Clearcase, thinking of upgrading to FAS6xxx series, but get to know that 7.2 is the only version supported on FAS6xxx series, but currently Clearcase supported version is on 7.1.x latest. Appreciate feedback on FAS6xxx with clearcase.. BR SW

1 0

Can we use clearcase with FAS6xxx Ontap 7.2?
by G SW 28 Sep '06

28 Sep '06

Halo.. We are using FAS960 with Clearcase, thinking of upgrading to FAS6xxx series, but get to know that 7.2 is the only version supported on FAS6xxx series, but currently Clearcase supported version is on 7.1.x latest. Appreciate feedback on FAS6xxx with clearcase.. BR SW

1 0

Troubleshooting http access
by JacekN 27 Sep '06

27 Sep '06

I would like to restrict access to files accessed via http. I am using DOT 7.2. First I configured standard http services - everything is running smoothly. My settings: httpd.access legacy httpd.admin.access legacy httpd.admin.enable off httpd.admin.hostsequiv.enable off httpd.admin.max_connections 1023 httpd.admin.ssl.enable on httpd.autoindex.enable off httpd.enable on httpd.log.format common httpd.method.trace.enable off httpd.rootdir /vol/docs httpd.timeout 300 httpd.timewait.enable off /vol/docs is dedicated for http access FlexVol with ntfs access rights filer is configured also for CIFS in workgroup mode). Now I try to limit access to the services - one dedicated user and standard authentication is enough. In accordance to documentation I have prepared the following files: /etc/httpd.passwd psuser:_J9..PYJ.MWfkaOhMiFc /etc/httpd.group psgroup:psuser /etc/httpd.access <Directory /vol/docs/> AuthName Dokumentacja PS <Limit GET> require user psuser </Limit> </Directory> <Directory /vol/docs/telco> AuthName Dokumentacja PS <Limit GET> require user psuser </Limit> </Directory> But it does not work: anyone can access the files without any authentication. What am I missing? How can I troubleshoot http access? (httpd.log file does not contain anything helpful). Best regards, Jacek --- avast! Antivirus: Outbound message clean. Virus Database (VPS): 0638-0, 2006-09-19 Tested on: 2006-09-19 23:18:41 avast! - copyright (c) 1988-2006 ALWIL Software. http://www.avast.com

3 4

RE: Mixed disk sizes within a single aggregate
by Fox, Adam 25 Sep '06

25 Sep '06

The -g option works when an RG already exists and you want to back-fill it. It doesn't create a new RG. To create a new RG, reduce the RG size and add drives, then up it to what you want. -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: George, Andrew [mailto:georgea@anz.com] Sent: Sunday, September 24, 2006 9:02 PM To: Sto RageC ; Brosseau, Paul Cc: Jeff Mery; toasters(a)mathworks.com Subject: RE: Mixed disk sizes within a single aggregate That should work, I'd be more inclined to go aggr add aggr0 -g rg2 -d <disk list> (Then again, I've always been distrustful of adding disks without naming them explicitly) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sto Rage(c) Sent: Saturday, 23 September 2006 2:53 AM To: Brosseau, Paul Cc: Jeff Mery; toasters(a)mathworks.com Subject: Re: Mixed disk sizes within a single aggregate On 9/20/06, Brosseau, Paul <Paul.Brosseau(a)netapp.com> wrote: > > > Mixing disk sizes in an aggregate is not a problem as long as you > create RAID groups for each kind of disk. WAFL creates stripes at the > RAID group level. For best results create complete RAID groups each > time you add disks to an aggregate. > > Paulb Paul and others, Is there way to force an aggregate to start a new RAID group when an existing RAID group is not completely full. Here's a situation FAS270 with 2 shelves with 144GB FC drives. RG size is set to 16 for a single aggregate with 26 disks (2 spares). This resulted in 2 RAID groups, 1 with 16 disks and the other with 10. Now we plan to add a 3rd shelf with 300GB FC drives. If we do the regular "aggr add" it will first add the 2 spare 144GB drives, then add 4 new 300GB drives by right sizing them to match the 144GB ones. In order to maximize the capacity on this aggregate, I'd prefer to add 12 of the new drives to a new RAID group but within the same aggregate. Is something like this possible? Haven't tried this as we don't have the new shelf yet, but can I reduce the raidsize option for the aggregate from 16 to 12, then add the 2 existing spares such that that the 2nd raid-group is now full based on raidsize=12 option. Now add the new shelf and run "aggr add aggr0 12" to add 12 new 300GB drive leaving 2 spares? RAID group /aggr0/plex0/rg0 - 16 disks (144GB each) RAID group /aggr0/plex0/rg1 - 12 disks (144GB each) <-- add the existing 2 spares RAID group /aggr0/plex0/rg2 - 12 disks (300GB each) Spares - two new 300GB drives. I think it would work, any comments? -G "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."

2 1

RE: Mixed disk sizes within a single aggregate
by Glenn Walker 25 Sep '06

25 Sep '06

Been a while since I checked, but I'm pretty sure that aggr add is the command he's looking for. You can set the raidgroup size down to the number of disks you currently have, then add a new RG - but it will be the same size as the current setting. Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of John Stoffel Sent: Friday, September 22, 2006 3:16 PM To: Sto Rage(c) Cc: Brosseau, Paul; Jeff Mery; toasters(a)mathworks.com Subject: Re: Mixed disk sizes within a single aggregate >>>>> "Sto" == Sto Rage(c) <" <netbacker(a)gmail.com>> writes: Sto> Paul and others, Sto> Is there way to force an aggregate to start a new RAID group Sto> when an existing RAID group is not completely full. Certainly, just specify explicity which disks you want in the aggregate: aggr create aggr300gb -d 12@300 See the output of 'aggr create<return>' John

2 1

RE: Mixed disk sizes within a single aggregate
by George, Andrew 25 Sep '06

25 Sep '06

That should work, I'd be more inclined to go aggr add aggr0 -g rg2 -d <disk list> (Then again, I've always been distrustful of adding disks without naming them explicitly) -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Sto Rage(c) Sent: Saturday, 23 September 2006 2:53 AM To: Brosseau, Paul Cc: Jeff Mery; toasters(a)mathworks.com Subject: Re: Mixed disk sizes within a single aggregate On 9/20/06, Brosseau, Paul <Paul.Brosseau(a)netapp.com> wrote: > > > Mixing disk sizes in an aggregate is not a problem as long as you > create RAID groups for each kind of disk. WAFL creates stripes at the > RAID group level. For best results create complete RAID groups each > time you add disks to an aggregate. > > Paulb Paul and others, Is there way to force an aggregate to start a new RAID group when an existing RAID group is not completely full. Here's a situation FAS270 with 2 shelves with 144GB FC drives. RG size is set to 16 for a single aggregate with 26 disks (2 spares). This resulted in 2 RAID groups, 1 with 16 disks and the other with 10. Now we plan to add a 3rd shelf with 300GB FC drives. If we do the regular "aggr add" it will first add the 2 spare 144GB drives, then add 4 new 300GB drives by right sizing them to match the 144GB ones. In order to maximize the capacity on this aggregate, I'd prefer to add 12 of the new drives to a new RAID group but within the same aggregate. Is something like this possible? Haven't tried this as we don't have the new shelf yet, but can I reduce the raidsize option for the aggregate from 16 to 12, then add the 2 existing spares such that that the 2nd raid-group is now full based on raidsize=12 option. Now add the new shelf and run "aggr add aggr0 12" to add 12 new 300GB drive leaving 2 spares? RAID group /aggr0/plex0/rg0 - 16 disks (144GB each) RAID group /aggr0/plex0/rg1 - 12 disks (144GB each) <-- add the existing 2 spares RAID group /aggr0/plex0/rg2 - 12 disks (300GB each) Spares - two new 300GB drives. I think it would work, any comments? -G "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication."

1 0

RE: Mixed disk sizes within a single aggregate
by Brosseau, Paul 22 Sep '06

22 Sep '06

Mixing disk sizes in an aggregate is not a problem as long as you create RAID groups for each kind of disk. WAFL creates stripes at the RAID group level. For best results create complete RAID groups each time you add disks to an aggregate. Paulb ________________________________ From: Jeff Mery [mailto:jeff.mery@ni.com] Sent: Wednesday, September 20, 2006 3:30 PM To: toasters(a)mathworks.com Subject: Mixed disk sizes within a single aggregate Greetings fellow toasters! <Background> We're looking at moving our 2 FAS940 systems from tradtional volumes to flexvols + aggregates. </Background> It would seem to me that the same rules and guidelines for creating traditional volumes now apply directly to the aggregate level (for the most part). By rules and guidelines I mean things like trying not to mix disk sizes, try to avoid volumes (now aggregates?) that span FC adapters, etc. Are any of these things still a concern on modern versions of ONTAP (7+)? Does anyone have any best practices they'd be willing to share in regards to aggregate creation? NOW says "make them as big as possible using as many spindles as possible", but that doesn't really help much. We use our filers for unstructured data only; cifs + nfs but no databases, no snapmirror, no snapvault, etc.. TIA, Jeff Mery - MCSE, MCP National Instruments ------------------------------------------------------------------------ - "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade ------------------------------------------------------------------------ -

5 4

Response time measurement
by Willeke, Jochen 22 Sep '06

22 Sep '06

Hi folks, i am still thinking about some figures which help me considering different fileservers. After doing some research i think one point is the response time given by the system. I did a lot of testing with sio and but the results i got are some kind of strange. A test with SIO e.g. brings following result: ./sio_ntap_linux 100 0 8k 100m 10 1 /mnt/test15 Version: 3.00 SIO_NTAP: Inputs Read %: 100 Random %: 0 Block Size: 8192 File Size: 104857600 Secs: 10 Threads: 1 File(s): /mnt/test15 Outputs IOPS: 114578 KB/s: 916626 IOs: 1145782 Terminating threads ...Killed First there are the KB/S. Much to fast even for a 1Gbit network. And the second is the response time. I calculated the following: 1s / 114578 (IOPS) = 0,00872 ms (response time) This cannot be true at all :-) Does SIO read the same block all the time (due to 0%random read), or do i have any kind of mistake in my test?!? Perhaps someone can help. Best Regards and a nice weekend Jochen

4 3

RE: Mixed disk sizes within a single aggregate
by Fox, Adam 22 Sep '06

22 Sep '06

That works just fine. Just be aware that if you are using RAID-DP you want to start with 3 disks, not two. -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: Sto Rage(c) [mailto:netbacker@gmail.com] Sent: Friday, September 22, 2006 12:53 PM To: Brosseau, Paul Cc: Jeff Mery; toasters(a)mathworks.com Subject: Re: Mixed disk sizes within a single aggregate On 9/20/06, Brosseau, Paul <Paul.Brosseau(a)netapp.com> wrote: > > > Mixing disk sizes in an aggregate is not a problem as long as you > create RAID groups for each kind of disk. WAFL creates stripes at the > RAID group level. For best results create complete RAID groups each > time you add disks to an aggregate. > > Paulb Paul and others, Is there way to force an aggregate to start a new RAID group when an existing RAID group is not completely full. Here's a situation FAS270 with 2 shelves with 144GB FC drives. RG size is set to 16 for a single aggregate with 26 disks (2 spares). This resulted in 2 RAID groups, 1 with 16 disks and the other with 10. Now we plan to add a 3rd shelf with 300GB FC drives. If we do the regular "aggr add" it will first add the 2 spare 144GB drives, then add 4 new 300GB drives by right sizing them to match the 144GB ones. In order to maximize the capacity on this aggregate, I'd prefer to add 12 of the new drives to a new RAID group but within the same aggregate. Is something like this possible? Haven't tried this as we don't have the new shelf yet, but can I reduce the raidsize option for the aggregate from 16 to 12, then add the 2 existing spares such that that the 2nd raid-group is now full based on raidsize=12 option. Now add the new shelf and run "aggr add aggr0 12" to add 12 new 300GB drive leaving 2 spares? RAID group /aggr0/plex0/rg0 - 16 disks (144GB each) RAID group /aggr0/plex0/rg1 - 12 disks (144GB each) <-- add the existing 2 spares RAID group /aggr0/plex0/rg2 - 12 disks (300GB each) Spares - two new 300GB drives. I think it would work, any comments? -G

1 0

RE: Mixed disk sizes within a single aggregate
by Glenn Walker 22 Sep '06

22 Sep '06

Technically, doing any of this (mixing drive speeds in RGs or drive sizes in RGs) will work just fine. The only issue is the potential of performance degradation in the future once\if the system is under stress. The drives spinning slowest will take the longest to have writes flushed to them - thusly forcing the CP to take longer and impacting the entire system. This is true within RGs or across multiple RGs in an aggregate. Heck, this is true even if you have multiple aggregates and one is comprised of slower disks than the others (or is slow due to other reasons such as workload, fragmentation, etc) - a write (CP) is a GLOBAL ENTITY and it is atomic in nature: if you have data in a CP for multiple RGs\TradVols\Aggrs and one takes forever to flush to disk, then the WHOLE CP takes forever. That said, all of this 'chicken little\sky falling' stuff is just conjecture. On a lightly loaded system, you'll never see issues. Only under stress will all of this stuff bubble to the surface. Oh - and FWIW, if you write data in a less-than optimal fashion, then subsequent reads will have the same issues (higher latencies), potentially causing performance problems. Remember - all of this could still take place and you could potentially never see the effects depending on the circumstances and how the applications handles increased latencies. I hope all of that is clearly written? Glenn -----Original Message----- From: maclean(a)cs.mcgill.ca [mailto:maclean@cs.mcgill.ca] Sent: Thursday, September 21, 2006 2:41 PM To: Glenn Walker Cc: toasters(a)mathworks.com Subject: RE: Mixed disk sizes within a single aggregate I always thought you would have problems mixing speeds in a raid group. Specifically you would see 'failing servo motor' autosupport messages. Or are you suggesting raid groups segregated by speed and only mixing speeds within an aggregate made up of the speed based raid groups? -Matthew On Thu, September 21, 2006 11:01 am, Glenn Walker wrote: > Exactly :) > > > Consistency is key: always try to keep same disk sizes speeds in > aggregates. I'd feel more comfortable adding disks with faster speeds > than larger sizes - there will be no future performance degradation from > this. > > Glenn > > > > -----Original Message----- > From: Crawford, Mark (CBC) [mailto:Mark.Crawford@CapBlueCross.COM] > Sent: Thu 9/21/2006 10:53 AM > To: David Knight; Glenn Walker > Cc: Paul.Brosseau(a)netapp.com; jeff.mery(a)ni.com; toasters(a)mathworks.com > Subject: RE: Mixed disk sizes within a single aggregate > > > When the stripes fill the equivalent of the smaller disks, wafl will > start striping only on the larger disks. This will cause performance > degradation due to "hot" disks. > > -----Original Message----- > From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] > On Behalf Of David Knight > Sent: Thursday, September 21, 2006 9:44 AM > To: ggwalker(a)mindspring.com > Cc: Paul.Brosseau(a)netapp.com; jeff.mery(a)ni.com; toasters(a)mathworks.com > Subject: Re: Mixed disk sizes within a single aggregate > > > I think wafl stripes across all disks in an aggregate. > I'm not sure how it respond to having one raid group with larger disks - > likely it will not use part of them. I'm pretty sure netapp recommends all > disks in an aggregate be the same size, or, it will assume they are all > the size of the smallest disk. Of course, I could be wrong . . . > > > David > > >> Remember that WAFL still writes across the entire aggregate. Having a >> > >> slower RAID group in an aggregate of faster raid groups would be akin to >> having a slower disk in a RG of faster disks, would it not? >> >> >> >> Glenn >> >> >> >> >> ________________________________ >> >> >> From: owner-toasters(a)mathworks.com >> [mailto:owner-toasters@mathworks.com] >> On Behalf Of Brosseau, Paul >> Sent: Wednesday, September 20, 2006 8:05 PM >> To: Jeff Mery; toasters(a)mathworks.com >> Subject: RE: Mixed disk sizes within a single aggregate >> >> >> >> >> Mixing disk sizes in an aggregate is not a problem as long as you >> create RAID groups for each kind of disk. WAFL creates stripes at the > >> RAID group level. For best results create complete RAID groups each >> time you add disks to an aggregate. >> >> >> >> Paulb >> >> >> >> >> ________________________________ >> >> >> From: Jeff Mery [mailto:jeff.mery@ni.com] >> Sent: Wednesday, September 20, 2006 3:30 PM >> To: toasters(a)mathworks.com >> Subject: Mixed disk sizes within a single aggregate >> >> >> >> Greetings fellow toasters! >> <Background> >> We're looking at moving our 2 FAS940 systems from tradtional volumes >> to flexvols + aggregates. </Background> >> >> >> It would seem to me that the same rules and guidelines for creating >> traditional volumes now apply directly to the aggregate level (for the > >> most part). By rules and guidelines I mean things like trying not to >> mix disk sizes, try to avoid volumes (now aggregates?) that span FC >> adapters, etc. >> >> Are any of these things still a concern on modern versions of ONTAP >> (7+)? Does anyone have any best practices they'd be willing to share >> in regards to aggregate creation? NOW says "make them as big as possible >> using as many spindles as possible", but that doesn't really > help much. >> We use our filers for unstructured data only; cifs + nfs but no >> databases, no snapmirror, no snapvault, etc.. >> >> TIA, >> Jeff Mery - MCSE, MCP >> National Instruments >> >> >> ---------------------------------------------------------------------- >> -- >> - >> "Allow me to extol the virtues of the Net Fairy, and of all the >> fantastic dorks that make the nice packets go from here to there. Amen." >> TB - Penny Arcade >> ---------------------------------------------------------------------- >> -- >> - >> >> > > > > Confidentiality Notice: > This e-mail is intended only for the personal and confidential use of the > individual to whom it is addressed and may contain information that is > privileged, confidential and protected by law. If you are not the > intended recipient, you are hereby notified that any use or disclosure of > this information is strictly prohibited. If you have received this > message in error, please notify the sender immediately by reply e-mail > and delete the original message. Your compliance is appreciated. > > > >

1 0

RE: Mixed disk sizes within a single aggregate
by Crawford, Mark (CBC) 22 Sep '06

22 Sep '06

When the stripes fill the equivalent of the smaller disks, wafl will start striping only on the larger disks. This will cause performance degradation due to "hot" disks. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of David Knight Sent: Thursday, September 21, 2006 9:44 AM To: ggwalker(a)mindspring.com Cc: Paul.Brosseau(a)netapp.com; jeff.mery(a)ni.com; toasters(a)mathworks.com Subject: Re: Mixed disk sizes within a single aggregate I think wafl stripes across all disks in an aggregate. I'm not sure how it respond to having one raid group with larger disks - likely it will not use part of them. I'm pretty sure netapp recommends all disks in an aggregate be the same size, or, it will assume they are all the size of the smallest disk. Of course, I could be wrong . . . David > Remember that WAFL still writes across the entire aggregate. Having a > slower RAID group in an aggregate of faster raid groups would be akin > to having a slower disk in a RG of faster disks, would it not? > > > > Glenn > > > > ________________________________ > > From: owner-toasters(a)mathworks.com > [mailto:owner-toasters@mathworks.com] > On Behalf Of Brosseau, Paul > Sent: Wednesday, September 20, 2006 8:05 PM > To: Jeff Mery; toasters(a)mathworks.com > Subject: RE: Mixed disk sizes within a single aggregate > > > > Mixing disk sizes in an aggregate is not a problem as long as you > create RAID groups for each kind of disk. WAFL creates stripes at the > RAID group level. For best results create complete RAID groups each > time you add disks to an aggregate. > > > > Paulb > > > > ________________________________ > > From: Jeff Mery [mailto:jeff.mery@ni.com] > Sent: Wednesday, September 20, 2006 3:30 PM > To: toasters(a)mathworks.com > Subject: Mixed disk sizes within a single aggregate > > > Greetings fellow toasters! > <Background> > We're looking at moving our 2 FAS940 systems from tradtional volumes > to flexvols + aggregates. > </Background> > > It would seem to me that the same rules and guidelines for creating > traditional volumes now apply directly to the aggregate level (for the > most part). By rules and guidelines I mean things like trying not to > mix disk sizes, try to avoid volumes (now aggregates?) that span FC > adapters, etc. > > Are any of these things still a concern on modern versions of ONTAP > (7+)? Does anyone have any best practices they'd be willing to share > in regards to aggregate creation? NOW says "make them as big as > possible using as many spindles as possible", but that doesn't really help much. > We use our filers for unstructured data only; cifs + nfs but no > databases, no snapmirror, no snapvault, etc.. > > TIA, > Jeff Mery - MCSE, MCP > National Instruments > > ---------------------------------------------------------------------- > -- > - > "Allow me to extol the virtues of the Net Fairy, and of all the > fantastic dorks that make the nice packets go from here to there. > Amen." > TB - Penny Arcade > ---------------------------------------------------------------------- > -- > - > Confidentiality Notice: This e-mail is intended only for the personal and confidential use of the individual to whom it is addressed and may contain information that is privileged, confidential and protected by law. If you are not the intended recipient, you are hereby notified that any use or disclosure of this information is strictly prohibited. If you have received this message in error, please notify the sender immediately by reply e-mail and delete the original message. Your compliance is appreciated.

5 5

RE: Mixed disk sizes within a single aggregate
by Glenn Walker 22 Sep '06

22 Sep '06

Right. Pretty much all of this very long discussion centers on one concept: the old adage "as strong as the weakest link". Only in this case, it's as fast as the slowest link. Glenn -----Original Message----- From: maclean(a)cs.mcgill.ca [mailto:maclean@cs.mcgill.ca] Sent: Thursday, September 21, 2006 5:00 PM To: Stephen C. Losen Cc: maclean(a)cs.mcgill.ca; Glenn Walker; toasters(a)mathworks.com Subject: Re: Mixed disk sizes within a single aggregate > Actually Netapp told us it's not a problem to replace a slower drive > with a faster one. It's not good if you have a RG of fast drives to > replace one with a slower drive, because that drags down the whole RG. Yeah a read would have to wait for the slower disk to spin around to the proper block while all the faster disks have already provided the data. -Matthew

1 0

RE: Mixed disk sizes within a single aggregate
by Glenn Walker 21 Sep '06

21 Sep '06

More FCAL adapters are better - spread the workload out as much as possible, but as Myles said, you're not going to see a workload go beyond the limit of a single adapter (typically). That said, if you have a large enough workload, you might see the head run out of resources before the FCAL loop does. When not using cluster, MPIO is a great way to go to help spread the load pretty evenly across adapters. Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Myles Uyema Sent: Thursday, September 21, 2006 12:25 PM To: Jeff Mery Cc: David Knight; Glenn Walker; Paul.Brosseau(a)netapp.com; toasters(a)mathworks.com Subject: Re: Mixed disk sizes within a single aggregate Most workloads are not going to reach 2gbit fibrechannel saturation, except with the occasional disk reconstruction. With that in mind, you'll want to spread your raidgroups across as many loops as possible and within budget. Concerning different sized 10k rpm disks, just realize that since 144GB disks are larger than 72GB disks, you will eventually have more data on the 144GB raid group, so generally you will see more I/O toward that set of disks, but the RPM is the same, and the performance characteristics are basically identical. On Thu, 21 Sep 2006, Jeff Mery wrote: Thanks for the responses everyone. Just to confirm... ...WAFL does indeed stripe each flexvol across all disks in the aggregate. If you have a flexvol that's 5% of your total aggregate space, it's safe to conclude that it's using 5% of each disk in your aggregate (assuming aggregate disks are all the same size). This was the impression I got from the documentation and then confirmed by the group. ...We don't have any mixed performance disks in our system (everything is 10K RPM), just mixed sizes. Creating a separate RG for each disk size is a good idea; this prevents wasting any larger disks on parity for smaller ones. Thanks for the suggestion. It seems we still have some confusion around what happens with performance in this mixed-disk scenario as well as the impact of a single aggregate spanning multiple FC adapters. Can anyone from NetApp clarify these for us? Jeff Mery - MCSE, MCP National Instruments ------------------------------------------------------------------------ - "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade ------------------------------------------------------------------------ - David Knight <knight(a)atmos.albany.edu> 09/21/2006 08:43 AM To ggwalker(a)mindspring.com (Glenn Walker) cc Paul.Brosseau(a)netapp.com, jeff.mery(a)ni.com, toasters(a)mathworks.com Subject Re: Mixed disk sizes within a single aggregate I think wafl stripes across all disks in an aggregate. I'm not sure how it respond to having one raid group with larger disks - likely it will not use part of them. I'm pretty sure netapp recommends all disks in an aggregate be the same size, or, it will assume they are all the size of the smallest disk. Of course, I could be wrong . . . David > Remember that WAFL still writes across the entire aggregate. Having a > slower RAID group in an aggregate of faster raid groups would be akin to > having a slower disk in a RG of faster disks, would it not? > > > > Glenn > > > > ________________________________ > > From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] > On Behalf Of Brosseau, Paul > Sent: Wednesday, September 20, 2006 8:05 PM > To: Jeff Mery; toasters(a)mathworks.com > Subject: RE: Mixed disk sizes within a single aggregate > > > > Mixing disk sizes in an aggregate is not a problem as long as you create > RAID groups for each kind of disk. WAFL creates stripes at the RAID > group level. For best results create complete RAID groups each time you > add disks to an aggregate. > > > > Paulb > > > > ________________________________ > > From: Jeff Mery [mailto:jeff.mery@ni.com] > Sent: Wednesday, September 20, 2006 3:30 PM > To: toasters(a)mathworks.com > Subject: Mixed disk sizes within a single aggregate > > > Greetings fellow toasters! > <Background> > We're looking at moving our 2 FAS940 systems from tradtional volumes to > flexvols + aggregates. > </Background> > > It would seem to me that the same rules and guidelines for creating > traditional volumes now apply directly to the aggregate level (for the > most part). By rules and guidelines I mean things like trying not to > mix disk sizes, try to avoid volumes (now aggregates?) that span FC > adapters, etc. > > Are any of these things still a concern on modern versions of ONTAP > (7+)? Does anyone have any best practices they'd be willing to share in > regards to aggregate creation? NOW says "make them as big as possible > using as many spindles as possible", but that doesn't really help much. > We use our filers for unstructured data only; cifs + nfs but no > databases, no snapmirror, no snapvault, etc.. > > TIA, > Jeff Mery - MCSE, MCP > National Instruments > > ------------------------------------------------------------------------ > - > "Allow me to extol the virtues of the Net Fairy, and of all the > fantastic > dorks that make the nice packets go from here to there. Amen." > TB - Penny Arcade > ------------------------------------------------------------------------ > - >

1 0

RE: Mixed disk sizes within a single aggregate
by Glenn Walker 21 Sep '06

21 Sep '06

Remember that WAFL still writes across the entire aggregate. Having a slower RAID group in an aggregate of faster raid groups would be akin to having a slower disk in a RG of faster disks, would it not? Glenn ________________________________ From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Brosseau, Paul Sent: Wednesday, September 20, 2006 8:05 PM To: Jeff Mery; toasters(a)mathworks.com Subject: RE: Mixed disk sizes within a single aggregate Mixing disk sizes in an aggregate is not a problem as long as you create RAID groups for each kind of disk. WAFL creates stripes at the RAID group level. For best results create complete RAID groups each time you add disks to an aggregate. Paulb ________________________________ From: Jeff Mery [mailto:jeff.mery@ni.com] Sent: Wednesday, September 20, 2006 3:30 PM To: toasters(a)mathworks.com Subject: Mixed disk sizes within a single aggregate Greetings fellow toasters! <Background> We're looking at moving our 2 FAS940 systems from tradtional volumes to flexvols + aggregates. </Background> It would seem to me that the same rules and guidelines for creating traditional volumes now apply directly to the aggregate level (for the most part). By rules and guidelines I mean things like trying not to mix disk sizes, try to avoid volumes (now aggregates?) that span FC adapters, etc. Are any of these things still a concern on modern versions of ONTAP (7+)? Does anyone have any best practices they'd be willing to share in regards to aggregate creation? NOW says "make them as big as possible using as many spindles as possible", but that doesn't really help much. We use our filers for unstructured data only; cifs + nfs but no databases, no snapmirror, no snapvault, etc.. TIA, Jeff Mery - MCSE, MCP National Instruments ------------------------------------------------------------------------ - "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade ------------------------------------------------------------------------ -

5 4

Mixed disk sizes within a single aggregate
by Jeff Mery 20 Sep '06

20 Sep '06

Greetings fellow toasters! <Background> We're looking at moving our 2 FAS940 systems from tradtional volumes to flexvols + aggregates. </Background> It would seem to me that the same rules and guidelines for creating traditional volumes now apply directly to the aggregate level (for the most part). By rules and guidelines I mean things like trying not to mix disk sizes, try to avoid volumes (now aggregates?) that span FC adapters, etc. Are any of these things still a concern on modern versions of ONTAP (7+)? Does anyone have any best practices they'd be willing to share in regards to aggregate creation? NOW says "make them as big as possible using as many spindles as possible", but that doesn't really help much. We use our filers for unstructured data only; cifs + nfs but no databases, no snapmirror, no snapvault, etc.. TIA, Jeff Mery - MCSE, MCP National Instruments ------------------------------------------------------------------------- "Allow me to extol the virtues of the Net Fairy, and of all the fantastic dorks that make the nice packets go from here to there. Amen." TB - Penny Arcade -------------------------------------------------------------------------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters