toasters March 2005

toasters@lists.teaparty.net

63 participants
88 discussions

ONTAP 7.0.0.1, aggregates, and flexvols
by Rob Winters 22 Mar '05

22 Mar '05

I'm catching up on the 6-week-old thread on this topic, and wondered where anyone is with deployment, stability, etc. It sounded like everyone in that thread went with my initial instinct of "make the aggregate as big as you can, and stuff it with flexvols". I'm wondering if that's the smart thing to do in a real-world scenario, or if there isn't some "middle way". If three disk fail in any one RAID-DP in the aggregate, or if two disks fail and the operator accidentally yanks out a third disk while trying to yank one of the first two, or (insert nightmare scenario here), then it's tape restore time for *every flexvol in the aggregate*, isn't it? It's an extreme long shot with RAID-DP, but a very bad outcome if you hit that particular lottery. I'm trying to decide how to think about that. Maybe divide up shares into different functional groups, or by space utilization, and do three aggregates instead of one? Still lots of space flexibility, but a bad raid only takes down a third of the Universe instead of the whole thing. Same issue in choosing the "sweet spot" for RAID size. I have 12 shelves in the FAS960, and I'm sure I want to minimize disks from the same RAID sharing shelves. One is ideal, two is tolerable, and three is "right out". Thoughts from smart folks appreciated, especially smart folks with working implementations. ;-) /// Rob

2 1

RE: ONTAP 7.0.0.1, aggregates, and flexvols
by Jeff Mohler 22 Mar '05

22 Mar '05

In the battle to maximize investment (usable disk space) -vs- risk (data loss), try to understand how much downtime you can -afford-. You will have backups, contingencies..etc, but try to math out how much downtime your enterprise can afford (because there will ALWAYS be some form of downtime as time goes on), and design the system to fall within that cost. That is usually easier than trying to understand how much uptime you want to buy, because you always want the MOST uptime, but you soon realize you cant afford it. Once you have that, its pretty simple to size a system to match it. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Battle, Evan (CBC) Sent: Tuesday, March 22, 2005 1:09 PM To: Rob Winters; toasters(a)mathworks.com Subject: RE: ONTAP 7.0.0.1, aggregates, and flexvols If you are worried about this scenario, use smaller raid groups. Evan -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Rob Winters Sent: Tuesday, March 22, 2005 1:45 PM To: toasters(a)mathworks.com Subject: ONTAP 7.0.0.1, aggregates, and flexvols I'm catching up on the 6-week-old thread on this topic, and wondered where anyone is with deployment, stability, etc. It sounded like everyone in that thread went with my initial instinct of "make the aggregate as big as you can, and stuff it with flexvols". I'm wondering if that's the smart thing to do in a real-world scenario, or if there isn't some "middle way". If three disk fail in any one RAID-DP in the aggregate, or if two disks fail and the operator accidentally yanks out a third disk while trying to yank one of the first two, or (insert nightmare scenario here), then it's tape restore time for *every flexvol in the aggregate*, isn't it? It's an extreme long shot with RAID-DP, but a very bad outcome if you hit that particular lottery. I'm trying to decide how to think about that. Maybe divide up shares into different functional groups, or by space utilization, and do three aggregates instead of one? Still lots of space flexibility, but a bad raid only takes down a third of the Universe instead of the whole thing. Same issue in choosing the "sweet spot" for RAID size. I have 12 shelves in the FAS960, and I'm sure I want to minimize disks from the same RAID sharing shelves. One is ideal, two is tolerable, and three is "right out". Thoughts from smart folks appreciated, especially smart folks with working implementations. ;-) /// Rob 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: ONTAP 7.0.0.1, aggregates, and flexvols
by Battle, Evan (CBC) 22 Mar '05

22 Mar '05

If you are worried about this scenario, use smaller raid groups. Evan -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Rob Winters Sent: Tuesday, March 22, 2005 1:45 PM To: toasters(a)mathworks.com Subject: ONTAP 7.0.0.1, aggregates, and flexvols I'm catching up on the 6-week-old thread on this topic, and wondered where anyone is with deployment, stability, etc. It sounded like everyone in that thread went with my initial instinct of "make the aggregate as big as you can, and stuff it with flexvols". I'm wondering if that's the smart thing to do in a real-world scenario, or if there isn't some "middle way". If three disk fail in any one RAID-DP in the aggregate, or if two disks fail and the operator accidentally yanks out a third disk while trying to yank one of the first two, or (insert nightmare scenario here), then it's tape restore time for *every flexvol in the aggregate*, isn't it? It's an extreme long shot with RAID-DP, but a very bad outcome if you hit that particular lottery. I'm trying to decide how to think about that. Maybe divide up shares into different functional groups, or by space utilization, and do three aggregates instead of one? Still lots of space flexibility, but a bad raid only takes down a third of the Universe instead of the whole thing. Same issue in choosing the "sweet spot" for RAID size. I have 12 shelves in the FAS960, and I'm sure I want to minimize disks from the same RAID sharing shelves. One is ideal, two is tolerable, and three is "right out". Thoughts from smart folks appreciated, especially smart folks with working implementations. ;-) /// Rob 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: HSM and NetApp
by Derek Lai 22 Mar '05

22 Mar '05

Check out FLM (File Lifecycle Management) from Nuview. Derek -----Original Message----- From: Holland, William L [mailto:hollandwl@state.gov] Sent: Tuesday, March 22, 2005 9:57 AM To: 'toasters(a)mathworks.com' Subject: HSM and NetApp What would you recommend for an HSM product for use with NetApp? I am interested in a product that will periodically scan my file systems on my filers and then, based on criteria that I establish, move those files to an R200. I would like for it to leave a link in place of the original file so that it can be retrieved should it be needed. I would like to be able to further refine the management such that once a file has been moved to the R200 for some period of time let me know to either archive it to tape/DVD/etc and then delete it from the R200 and remove the links.

1 0

RE: HSM and NetApp
by Alan Biren 22 Mar '05

22 Mar '05

Try NuView's File Lifecycle Manager. I've implemented several times. It does what you are looking for. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Holland, William L Sent: Tuesday, March 22, 2005 12:57 PM To: 'toasters(a)mathworks.com' Subject: HSM and NetApp What would you recommend for an HSM product for use with NetApp? I am interested in a product that will periodically scan my file systems on my filers and then, based on criteria that I establish, move those files to an R200. I would like for it to leave a link in place of the original file so that it can be retrieved should it be needed. I would like to be able to further refine the management such that once a file has been moved to the R200 for some period of time let me know to either archive it to tape/DVD/etc and then delete it from the R200 and remove the links. ***************************************************************************************************** If you have received this email in error please notify the the system manager or the sender immediately and do not disclosed the to anyone or make copies. ** eSafe scanned this email for viruses, vandals or malicious content ** ** To find out eSafe(TM) and other Aladdin Security Products, contact AMC Corporation at (212) 736-0111 *****************************************************************************************************

1 0

Re: HSM and NetApp
by jack＠jlbtechconsulting.com 22 Mar '05

22 Mar '05

Check out CommVault's Qinetix Data Migrator. You're looking for an Information LIfecycle Management tool and they have the best on the market right now. It will do exactly what you're asking to do.

1 0

possible space guarantee "bug" ?
by Charles Bartels 22 Mar '05

22 Mar '05

I've been shuffling around my volumes, migrating to flexible volumes, and noticed an interesting possible bug. I created about a dozen volumes within a large aggregate; using all the space available. All were create with the default space guarantee setting of "volume". As I understand things, this effectively means the space is reserved for each volume (i.e. one volume can't use up space in another volume.) When I rebooted my filer this morning I noticed the warning: [wafl.vol.guarantee.fail:error]: Space for volume vol_test is NOT guaranteed and the space guarantee setting showed up as "volume(disabled)" As soon as I shrunk one of the volumes a bit the following message appeared in the log: [wafl.vol.add.spcGuar:info]: Space for volume vol_test is guaranteed. This seems to imply that one should be very careful whenever you create or increase the size of a flexible volume. You can inadvertently disable the space guarantee on another volume. This *may* be the expected way 7.0 works; I don't know. I'm still in the process of getting the hang of this latest release. But it did seem strange. -C.

1 0

Exchange and iSCSI
by Holland, William L 21 Mar '05

21 Mar '05

Is SnapDrive and SnapManager for Exchange really needed to run Exchange with databases on a filer using iSCSI? Seems to me that it would be possible to use MS's iSCSI initiator then manually create the iSCSI Groups and LUNs where the databases and logs will be stored then use scripts to perform routine maintenance and backups. Anyone out there using Exchange and iSCSI without SnapDrive and SnapManager for Exchange?

3 2

Support Console
by Robert Borowicz 21 Mar '05

21 Mar '05

Does anybody use NetApp's "Support Console" ? Please write me privately if you do. Thanks -Rob

1 0

RE: df size reporting differences in ONTAP 7.0
by Sphar, Mike 21 Mar '05

21 Mar '05

Is it possible that the order the quotas are defined in the quota file are causing this different behavior? -----Original Message----- From: Adam McDougall [mailto:mcdouga9@egr.msu.edu] Sent: Monday, March 21, 2005 11:18 AM To: Charles Bartels Cc: toasters(a)mathworks.com Subject: Re: df size reporting differences in ONTAP 7.0 On Wed, Mar 16, 2005 at 10:51:54AM -0800, Charles Bartels wrote: > I may be confused but it sounds like you are describing the > old behavior, which 6.5.3 exhibits. Yes. But certain configurations of 7.0 do *not* have that problem. I have user quotas under a qtree in a traditional volume that show the "correct" answer when the user runs "df", meaning the user sees their partition sized to their quota. > All in all, I was alerted today that a Bug ID 154530 was created > and will be "fixed" in a future release. I took a look at that bug on the NOW site and it was disappointingly vague. It has a title, and nothing else. -C. It is publicly available now: 154530 Title 'df' reports size based on all quotas (including user/group) over NFS in a qtree Duplicate of Bug Severity 3 - Serious inconvenience Bug Status Not Fixed Product Data ONTAP Bug Type WAFL Description Formatted In releases prior to 7.0, running the 'df' command on an NFS mount of an exported qtree shows the export size as the smaller of the volume size or the qtree quota, if one exists. In 7.0, this behavior was inadvertently changed to return the size as the minimum of the volume size or any applicable quota, including user and group quotas for the user running 'df' in addition to any qtree quota.

4 4

← Newer
1
2
3
4
5
6
7
8
9
Older →

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 March 2005