toasters

toasters@lists.teaparty.net

13531 discussions

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

RE: Performance Indicators
by Glenn Walker 15 Sep '06

15 Sep '06

I believe that this is more along the lines of QoS (though not true QoS and not guaranteed). What Jochen is looking for is a bit difficult: you can't really guarantee performance on the head due to workload differences. Each of the machines Jochen listed is a very capable machine - but selling IOPS to a user is not easy. Each workload is different, each application would require a different amount of IOPS in order to facilitate functionality (hard to define these sometimes), you can't easily segregate workloads and adding workload from one user\system would definitely affect existing workloads. For example: CIFS typically requires about 5 IOPS to open a file as a minimum - if you add some newer functionality from 2k3\XP and MS Office, you could be talking about hundreds of IOPS to open a file (pulling file metadata). Perhaps the best thing to do is to talk to sales to get actual numbers, but simply list the capabilities of the filer and manage how the workload is spread among them. One last point: when you speak of performance, you mentioned IOPS - this is workload, not performance. Performance is more a measure of latency at a particular level of work: ie, how much latency for a given amount of IOPS. If I stated that the R200 was capable of about 12000 IOPS (CIFS) per second, that would be true - but I could also position it as being capable of higher if the latencies of the workload were to increase (still the same amount of work, but response time would decrease). You could speak to the user-base about performance in terms of latency and IOPS. Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Wischer, Sebastian Sent: Friday, September 15, 2006 5:18 AM To: Willeke, Jochen; NetApp Toasters List Subject: RE: Performance Indicators HI Jochen, have you think about FlexCache?? There you give volumes priorities. I know it is not exactly what you are looking for but perhaps with the help of FlexCache you can sell categories to your departments. Here is a small summary from a NetApp slideset regarding FlexCache: FlexShare(tm) is enabled when there are system bottlenecks CPU NVRAM Disk Control of priority by volume Five priority levels Sebastian -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Willeke, Jochen Sent: Friday, September 15, 2006 10:32 AM To: NetApp Toasters List Subject: Performance Indicators Hi Toasters, right now i am thinking about any kind of performance indicator for my fileservice. We do supply storage to other departments of our company. Of course one thing i can sell is space. But there is another indicator which is performance. Has anybody good ideas how to define the performance i can grant to a special service? I was thinking about I/O's per second but do not know what a good number would be. Has anybody ever had to work out those values and can give me something to think about? I am interesting in any experience you had with this topic... I/O's, data-throughput, responsetime....And what are good values which i can grant with netapp systems? We use R200, FAS960 and FAS3050. Thanks in advance Jochen

2 1

Need Advice for changing qtree from Unix to NTFS security style
by Stephen C. Losen 15 Sep '06

15 Sep '06

We have a filer that serves files in a qtree with both NFS and CIFS. The file security style is currently Unix. The qtree has about 7000 files using about 150G. CIFS authentication is done via a Windows DC and we have a Unix passwd NIS map for converting the Windows users to Unix users. There are over 100 folks using this share. Each one owns a directory (not a home directory -- just storage) and each one wants to be able to grant some of the 100 other users access to their folder. Plus they have an admin who needs to be able to manipulate access rights on everything. Obviously Unix security style isn't going to cut it. So we want to switch the qtree to NTFS security style. We switched a test qtree from Unix to NTFS style and discovered that no one (not even a Windows user with admin privs in the domain) has "modify" or "full control" rights on any file or folder that already exists. So it looks like we can't change the ACLs on anything that already exists. If a Windows user creates a new folder or file, then he has the ability to change the ACL. Has anyone else switched a qtree from Unix to NTFS style? Is there anything we can do either before or after we switch the security style to make it possible to set ACLs on files that already exist? I didn't try logging in to CIFS as a local filer user. Is that the secret? I suppose we could create a new empty qtree with NTFS style and copy the files from the old qtree to the new one. But I would really like to avoid that if possible. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

2 2

Re: Need Advice for changing qtree from Unix to NTFS security style
by Stephen C. Losen 15 Sep '06

15 Sep '06

> > We switched a test qtree from Unix to NTFS style and discovered that no > one (not even a Windows user with admin privs in the domain) has "modify" > or "full control" rights on any file or folder that already exists. So > it looks like we can't change the ACLs on anything that already exists. > If a Windows user creates a new folder or file, then he has the ability > to change the ACL. > Ooops. Looks like I was wrong here. The owner of the file or folder does have full control. So I guess I can chown everything to me and then from my Windows account I can set all the ACLs. I'll check and see if the local filer "administrator" user can do it. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

1 0

Performance Indicators
by Willeke, Jochen 15 Sep '06

15 Sep '06

Hi Toasters, right now i am thinking about any kind of performance indicator for my fileservice. We do supply storage to other departments of our company. Of course one thing i can sell is space. But there is another indicator which is performance. Has anybody good ideas how to define the performance i can grant to a special service? I was thinking about I/O's per second but do not know what a good number would be. Has anybody ever had to work out those values and can give me something to think about? I am interesting in any experience you had with this topic... I/O's, data-throughput, responsetime....And what are good values which i can grant with netapp systems? We use R200, FAS960 and FAS3050. Thanks in advance Jochen

2 2

the Toasters list is now restricting posts!
by Kevin Davis 12 Sep '06

12 Sep '06

Folks, Just an FYI to all: we've had to take the measure of restricting posting to the 'toasters' list, meaning that the list will only accept posts from an address which is subscribed. Sorry for taking this measure, but the nature of email today has left us no alternative (not one that will still allow us to get our jobs done, that is!); it's a way to keep the spam to the list to a minimum. And for what it's worth, the spam to the list is almost nil now. (knock wood and cross your fingers). Hopefully, this measure along with the four (yep...four!) separate facilities we have for filtering the gooey pink stuff will be sufficient to make the list a friendlier place again. For most, this will have no effect. But some may be subscribed via list addresses which will be expanded on the destination domain, and for these folks the ability to reply to or start new threads will be foiled, unless the "From:" address matches the address which is subscribed to the list. In other words: Admin1 is one of 4 admins at XYZ Corp. who are all part of the alias 'toasters(a)xyzcorp.com'. The admins at XYZ subscribe 'toasters(a)xyzcorp.com' to 'toasters(a)mathworks.com'. An email to the 'toasters' list goes to XYZ and is expanded to all 4 admins. Admin1 then they won't be able to reply or create new posts because 'admin1(a)xyzcorp.com' is not subscribed to the 'toasters' list. So...sorry for any inconvenience to individuals subscribed in this manner, but you'll have to subscribe individually in order to post to the list. -- *------------------------------------------*-----------------------* | Kevin Davis (UNIX Sysadmin) | Natick, Massachusetts | | 508.647.7660 | 01760-2098 | | mailto:kevin.davis@mathworks.com *-----------------------* | http://www.mathworks.com | | *------------------------------------------*-----------------------*

2 2

RE: Snap status and wafl scan
by Glenn Walker 08 Sep '06

08 Sep '06

You are correct - the reclamation is a new feature - introduced around 7.0 I believe. Unsure what version of ONTAP the issue was being seen on, but there were some bugs related to that feature-set that were fixed in later versions - some bugs were related to its efficiency, while some were related to the timing (when the freed space was showing back up). Glenn -----Original Message----- From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] Sent: Friday, September 08, 2006 12:07 PM To: toasters(a)mathworks.com Cc: Glenn Walker Subject: Re: Snap status and wafl scan ggwalker(a)mindspring.com (Glenn Walker) writes: > Ok - those are other things than what I previously mentioned. > > Active Bitmap rearrangement is normal - I believe it has been around > since 6.5 (pretty sure it wasn't a flexvol thing, that was 'deswizzler' > scan). It's to keep memory 'pretty', if memory serves. > > The container block reclamation is a scanner responsible for ferreting > out blocks that have been freed and marking them as usable to the system > (delayed free scanner\delayed freer working here). This too is normal. Just in case it wasn't clear, I did not mean to suggest that these things were not "normal", or that they had any implications for filing system integrity. It was the performance aspect of the "container block reclamation" scan that originally brought it to my attention: specifically that after our dumps had finished (and the associated snapshots thus deleted) disc I/O remained high and cache age very low for some time. I don't think ONTAP used to behave like that in 6.5. By contrast the "active bitmap rearrangement" scan (which is always running: it just cycles around the block numbers indefinitely) has no bad effect on performance that I have ever noticed. -- Chris Thompson Email: cet1(a)cam.ac.uk

1 0

RE: jumbo frames support
by Fox, Adam 08 Sep '06

08 Sep '06

Yes, Jumbo frames are supported via the ifconfig command. The command allows you to set the mtusize. Although it's probably worth opening a support case and have them run a perfstat on your system while you are experiencing slow performance. If it's really as slow as you say, it's probably not the mtusize. It might be, but there are probably other things you can adjust in your environment first. But NGS has the resources to work with you to figure those out. Just a thought. -- Adam Fox adamfox(a)netapp.com -----Original Message----- From: kunle windapo [mailto:kwindapo@yahoo.com] Sent: Friday, September 08, 2006 11:26 AM To: toasters(a)mathworks.com Subject: jumbo frames support hello, i have a FAS 270 with volumes nfs mounted on a Solaris 9 sparc server. there is a direct connection from the solaris server to ethernet interface on the FAS 270 running at 1Gb/s. problem is i experience very slow performance on the system, (io related) and i'm troubleshooting. i want to know if NetApp supports Jumbo frames on the Network interface. thank you __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

jumbo frames support
by kunle windapo 08 Sep '06

08 Sep '06

hello, i have a FAS 270 with volumes nfs mounted on a Solaris 9 sparc server. there is a direct connection from the solaris server to ethernet interface on the FAS 270 running at 1Gb/s. problem is i experience very slow performance on the system, (io related) and i'm troubleshooting. i want to know if NetApp supports Jumbo frames on the Network interface. thank you __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

RE: Snap status and wafl scan
by Glenn Walker 08 Sep '06

08 Sep '06

Ok - those are other things than what I previously mentioned. Active Bitmap rearrangement is normal - I believe it has been around since 6.5 (pretty sure it wasn't a flexvol thing, that was 'deswizzler' scan). It's to keep memory 'pretty', if memory serves. The container block reclamation is a scanner responsible for ferreting out blocks that have been freed and marking them as usable to the system (delayed free scanner\delayed freer working here). This too is normal. Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Chris Thompson Sent: Thursday, September 07, 2006 4:01 PM To: toasters(a)mathworks.com Cc: ecoli82(a)msn.com; etraitel(a)gmail.com Subject: Re: Snap status and wafl scan Eyal Traitel writes: > Note that snap status is an advanced command so its output shouldn't > necessarily cause you concerns... Well, while we're talking about things wot mere mortals were not meant to wot of... ec0li <ecoli82(a)msn.com> wrote: > When I check snap status, I see next to recent snapshots : (xxxx/xxxx > remaining). > Also, It seems that this is in fact the wafl scan process "snap create > summary update" The effect worrying me is somewhat different. After a snapshot is deleted the above state lasts only seconds, but there is then a much more extended period where "snap status" looks normal but "wafl scan status" shows e.g. carina*> wafl scan status Volume CUS: Scan id Type of scan progress 1 active bitmap rearrangement fbn 3340 of 4461 w/ max_chain_len 3 925 container block reclamation block 382 of 4461 The "container block reclamation" scan lasts several minutes (and this is a volume & aggregate of only a few hundred GB), and while it's going on disc read activity is high and severely impacts the cache - at least, if you trust the "cache age" shown by sysstat, which I am not sure I do. This is with ONTAP 7.1.1P1 (but similar effects observed in earlier 7.x's). -- Chris Thompson Email: cet1(a)cam.ac.uk

2 1

NDMP backups, timeouts
by Scott T. Mikusko 08 Sep '06

08 Sep '06

I'm running into a recurring issue with backing up my NearStore and a long F760 filer. In the procoess of backing some large filesystems (qtrees), it appears that NDMP is basically timing out and fails. I'm running Veritas NetBackup 6.0 (finally upgrading from 4.5 recently). I think the issue has to do with NDMP starting the dump commands on the filer, which then does a three-way backup to another filer with local tape drives. The debug from ndmp logs shows for a manual full backup of a filer: Sep 05 21:05:57 EDT [ndmpd:58]: Log message: DUMP: creating "/vol/vol0/../snapshot_for_backup.370" snapshot. Sep 05 21:06:05 EDT [ndmpd:58]: Log message: DUMP: Using Partial Volume Dump with Exclude Lists Sep 05 21:07:31 EDT [ndmpd:58]: Log message: DUMP: Date of this level 1 dump: Tue Sep 5 21:05:57 2006. Sep 05 21:07:31 EDT [ndmpd:58]: Log message: DUMP: Date of last level 0 dump: Fri Aug 18 19:20:57 2006. Sep 05 21:07:31 EDT [ndmpd:58]: Log message: DUMP: Dumping /vol/vol0/files3.rt to NDMP connection Sep 05 21:07:31 EDT [ndmpd:58]: Log message: DUMP: mapping (Pass I)[regular files] It never completes the mapping of the files in Pass I. It just sits there. The filesystems I'm backing up are between 250-650GB with a LOT of small files (millions) and many subdirs. Tons of mail and html files. My guess is that the amount of files and dirs are getting large that NDMP can't map them fully and is timing out after 8 hours. It shouldn't take that long to map files for the size of data it's doing; I've seem mapping times be much less for larger sets of data. I know that the filesystem topology can cause NDMP backups to be slow, depending on file sizes, data layout, filer load, network etc, but this is happening on moderately busy filers or bone idle NearStores. Anyone run across lengthy DUMP times? Chewing through NOW and Veritas support site hasn't turned up anything obvious. Just curious if others have run into NDMP/dump issues like this. -Scott

4 3

Snap status and wafl scan
by ec0li 07 Sep '06

07 Sep '06

Hello, When I check snap status, I see next to recent snapshots : (xxxx/xxxx remaining). Also, It seems that this is in fact the wafl scan process "snap create summary update" Does anyone knows what is this process, its purpose, what happens if the system reboots during this,... I'm asking this because on one system with lots of snapshots(snapvault) this process seems to never finish. In fact, each time a new snap is transfered the counter restarts from the beginning but has not enough time to finish until a new snapshot is created. Consequence : in snap status I see more and more snapshots with (xxx/xxx remaingint) on the right. Thanks in advance for your answers! -- View this message in context: http://www.nabble.com/Snap-status-and-wafl-scan-tf2232129.html#a6187160 Sent from the Network Appliance - Toasters forum at Nabble.com.

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters