toasters March 2005

toasters@lists.teaparty.net

63 participants
88 discussions

RE: reuse old NetApp shelf
by Iain Barnetson 26 Mar '05

26 Mar '05

I've tired low level formatting two of the disks using the Qlogic card bios facility which suceeded with no error messages. I then came back into windows and still couldn't do anything with the disks. I've tried creating a partition using both diskpart and gdisk32 but still no joy. Gdisk32 creates a partition but still windows wants to initialize the disks but can't. diskpart sits there using cpu cycles, so far for 3 hours, and doesn't seem to be doing very much. Any ideas how I can get these drives in a usuable state? ________________________________ From: Fox, Adam [mailto:Adam.Fox@netapp.com] Sent: 25 March 2005 17:14 To: Iain Barnetson Subject: RE: reuse old NetApp shelf You'll probably have to low-level format the drives to use 512 byte blocks. I'm guessing Windows isn't thrilled with the 520-byte blocks that NTAP uses. -- Adam Fox adamfox(a)netapp.com ________________________________ From: Iain Barnetson [mailto:Iain.Barnetson@Halliburton.com] Sent: Friday, March 25, 2005 11:50 AM To: toasters(a)mathworks.com Subject: Re: reuse old NetApp shelf I've got a couple of NetApp DS14 fibre disk shelves from our "old" filers that I'd like to reuse. I attached one of the shelves to a server using a Qlogic 2200 card and although Windows detected the drives correctly I couldn't partition them or anything - no specific error message just saying that it couldn't. What I'm wondering is: Should I use the Qlogic card facility to low level format them? Will that make them usable in Windows? Any suggestions on how I can implement RAID with these disks other than Windows software RAID? Regards, Iain

1 0

Netapp trunking - no performance gain
by Chris Moll 25 Mar '05

25 Mar '05

Has anyone gotten any performance gains from network interface trunking with a netapp? So far I haven't.... my suspicion is that I don't have the switch setup right. ----- More details: I'm trying to setup trunking on a netapp connected to a Cisco 3550 gigabit switch (OS vers.12 on the switch). The odd thing is that when I setup two gigabit lines trunked together from the netapp to the switch I saw no improvement in thoughtput compared to a single gigabit line. As a test I set up four 100Mbit interfaces trunked together from the netapp to the switch. Again, I see the same throughput as with a single 100Mbit interface alone - there was no gain in throughput from adding three more interfaces. (Measured by connecting a Sun to the switch with a gigabit interface). The trunking worked even before I set anything on the switch. The only thing I knew to do on the switch was put the interfaces in a channel group: switch> interface range GigabitEthernet1/0/17 - 18 switch> channel-group 1 mode on switch> end ...but still no change in throughput (this worked with sun trunking, and there I did see a gain in throughput). netapp> vif create multi romvif0 -b rr e4a e4b e4c e4d netstat and vif status both show roughly equal numbers of packets on all four interfaces; all four are definitely being used. -Chris Moll Lawrence Berkeley National Laboratory

2 1

FW: reuse old NetApp shelf
by Iain Barnetson 25 Mar '05

25 Mar '05

Thanks for the replies guys. Any ideas on a hardware RAID card controller for them? ________________________________ From: owner-toasters(a)mathworks.com on behalf of Iain Barnetson Sent: Fri 25/03/2005 16:50 To: toasters(a)mathworks.com Subject: Re: reuse old NetApp shelf I've got a couple of NetApp DS14 fibre disk shelves from our "old" filers that I'd like to reuse. I attached one of the shelves to a server using a Qlogic 2200 card and although Windows detected the drives correctly I couldn't partition them or anything - no specific error message just saying that it couldn't. What I'm wondering is: Should I use the Qlogic card facility to low level format them? Will that make them usable in Windows? Any suggestions on how I can implement RAID with these disks other than Windows software RAID? Regards, Iain

1 0

Re: reuse old NetApp shelf
by Iain Barnetson 25 Mar '05

25 Mar '05

I've got a couple of NetApp DS14 fibre disk shelves from our "old" filers that I'd like to reuse. I attached one of the shelves to a server using a Qlogic 2200 card and although Windows detected the drives correctly I couldn't partition them or anything - no specific error message just saying that it couldn't. What I'm wondering is: Should I use the Qlogic card facility to low level format them? Will that make them usable in Windows? Any suggestions on how I can implement RAID with these disks other than Windows software RAID? Regards, Iain

2 1

RE: converting root volume to flexvol
by Palmer, Jason (EMEA) 24 Mar '05

24 Mar '05

Hi - For info, I generally set my root volumes to 15Gb overall with a 20% Snap reserve (12Gb FS and 3Gb snap) I heavily restrict access to the chosen few and exclude the 'noddy' administrators often found in Domain Admin groups :o) The remainder of the AGGR aggregate I set up as an 'admin' volume where I store install and other misc data away from the user data. From Johns comments, I think what had happened is I had rebooted the filer on the newroot flex vol and issued the command which succeeded because it had already set AGGR aggregate as root. I have another cluster pair I will be playing with and upgrading this weekend. I will check out my theories (we do not have the luxury of a test filer here) That aside, has anyone seen any problems with SID based quotas after upgrading ? It seems that some explicit entries in our /etc/quotas. file which are recognised when the volume is bought online seem to revert to the standard default quota over time. A minor problem (just off/on quotas every now and then to workaround), would be nice to see if anyone else experiences this and if there is a fix available / or in the pipeline ? ~Jason -----Original Message----- From: John Stoffel [mailto:john.stoffel@taec.toshiba.com] Sent: 24 March 2005 17:50 To: Charles Bartels Cc: Palmer, Jason (EMEA); Adam McDougall; toasters(a)mathworks.com Subject: RE: converting root volume to flexvol Charles> A small comment on the plan below. The command to set the root Charles> aggregate (step 4) gives an error: Filer1> aggr options aggr1 root Charles> aggr options: option 'root' can be modified only in maintenance mode Charles> This isn't a problem though since you just need to set the Charles> root volume. The root aggregate will change automatically Charles> upon reboot. Just to clarify things here, since we're looking to goto OnTap 7.0 in the near future... you can just skip step 4 below, since upon reboot the aggregate with the root volume will automatically get the 'root' flag set properly? So you just need to the: vol options root newroot and reboot? Charles> And just a generally comment on the Netapp size Charles> "recommendation" for a flexible root vol. I've seen three Charles> different docs that discuss the size of the root vol. One Charles> suggested 30GB, two others said you should use something Charles> around 90GB. All those suggestions are patently insane. I assume they want to leave room for upgrades and log files. But sure, I think 30gb is way to damm big as well... Charles> I keep 3 months works of root vol snapshots; the total size Charles> is somewhere around 300MB. A few gigs should easily be Charles> enough to handle most situations. I don't understand what Charles> the people who wrote the docs were thinking. Charles> -----Original Message----- Charles> From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] Charles> On Behalf Of Palmer, Jason (EMEA) Charles> Sent: Wednesday, March 02, 2005 5:49 AM Charles> To: 'Adam McDougall'; toasters(a)mathworks.com Charles> Subject: RE: converting root volume to flexvol Charles> Hi Adam, Charles> I successfully moved to a root volume on a flexible volume within an Charles> aggregate last week without any problems... Charles> I used ndmpcopy from the command line of the filer and followed the Charles> steps below - Charles> 1. Create the Aggregate (In our case a 3 disk root aggregate called Charles> AGGR) Charles> 2. Create new flexible root volume within that aggregate (I called Charles> this rootnew as we already have a root volume) Charles> 3. NDMPCOPY -l 0 -f <filer>:/vol/root/etc <filer>:/vol/newroot/etc Charles> 4. aggr options aggr root <-- To set the aggr aggregate to Charles> the root aggregate Charles> 5. vol options newroot root <-- To set the rootnew volume to Charles> the root volume Charles> 6. Reboot the filer and verify everything comes back up OK (If not Charles> you can boot in maintenance mode to reset the root volume) Charles> 7. Check that newroot in aggr is the root volume using vol status Charles> 8. If this is the case, rename root volume to rootold and rootnew Charles> to root Charles> 9. Use vol offline rootold to ofline the old root volume and if Charles> 100% happy use the vol destroy Charles> Worked fine for us - I only used the NetApp KB as a guideline. Charles> I have another 5 machines to convert in the same way - I was lucky, as Charles> the first system I did was not storing production data so there were Charles> plenty of disks and no pressure of system downtime to consider. Charles> I hope this helps, Charles> Jason Palmer Charles> Storage Architecture Charles> MCI EMEA

2 1

RE: converting root volume to flexvol
by Charles Bartels 24 Mar '05

24 Mar '05

A small comment on the plan below. The command to set the root aggregate (step 4) gives an error: Filer1> aggr options aggr1 root aggr options: option 'root' can be modified only in maintenance mode This isn't a problem though since you just need to set the root volume. The root aggregate will change automatically upon reboot. And just a generally comment on the Netapp size "recommendation" for a flexible root vol. I've seen three different docs that discuss the size of the root vol. One suggested 30GB, two others said you should use something around 90GB. All those suggestions are patently insane. I keep 3 months works of root vol snapshots; the total size is somewhere around 300MB. A few gigs should easily be enough to handle most situations. I don't understand what the people who wrote the docs were thinking. -C. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Palmer, Jason (EMEA) Sent: Wednesday, March 02, 2005 5:49 AM To: 'Adam McDougall'; toasters(a)mathworks.com Subject: RE: converting root volume to flexvol Hi Adam, I successfully moved to a root volume on a flexible volume within an aggregate last week without any problems... I used ndmpcopy from the command line of the filer and followed the steps below - 1. Create the Aggregate (In our case a 3 disk root aggregate called AGGR) 2. Create new flexible root volume within that aggregate (I called this rootnew as we already have a root volume) 3. NDMPCOPY -l 0 -f <filer>:/vol/root/etc <filer>:/vol/newroot/etc 4. aggr options aggr root <-- To set the aggr aggregate to the root aggregate 5. vol options newroot root <-- To set the rootnew volume to the root volume 6. Reboot the filer and verify everything comes back up OK (If not you can boot in maintenance mode to reset the root volume) 7. Check that newroot in aggr is the root volume using vol status 8. If this is the case, rename root volume to rootold and rootnew to root 9. Use vol offline rootold to ofline the old root volume and if 100% happy use the vol destroy Worked fine for us - I only used the NetApp KB as a guideline. I have another 5 machines to convert in the same way - I was lucky, as the first system I did was not storing production data so there were plenty of disks and no pressure of system downtime to consider. I hope this helps, Jason Palmer Storage Architecture MCI EMEA -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com]On Behalf Of Adam McDougall Sent: 02 March 2005 12:37 To: toasters(a)mathworks.com Subject: converting root volume to flexvol I am asking the list because documentation on this process seems to be inconsistant or light in nature on the NOW website. Background: When we setup our Filer, vol0 spanned 24 data disks and contained "etc". The original filer, an F820, booted from this. We've since upgraded to FAS940 and Data ONTAP 7.0 and I want to migrate root to a flexvol. We also have a new disk shelf, so I set it up as aggr0 and already have some production flexvols running from it for data. I created a flexvol named root on aggr0. I want to move the root from vol0 to this new flexvol so I can destroy vol0 (which is larger now and has no remaining production qtrees) and create a second aggregate with the 3 disk shelves that would be freed. Problem: Several articles, such as Solution ID: kb5856 make it sound like you need to copy etc into /aggr0/newvol instead of /vol/newvol. It also demonstrates that the newly created /vol/newvol appears empty after this. Why would you do it that way? Is it an ndmpcopy/rootvol thing that you would want to do this? I have successfully migrated normal data from traditional volumes to flex volumes using various combinations of ndmpcopy, tar, and rsync. Copies that complete successfully work fine. Other articles such as Solution ID: kb5634 make the procedure sound simpler yet more vague: "1. From an Admin host that has access to both traditional vol0 and the new root volume copy the entire /etc directory over to the new volume. " This I can easily handle, but I want to be fairly certain that it will actually boot from the new root vol after doing "vol options root root". I also want to put boot files on the new aggr/root disks so I can boot from that shelf incase I need to replace my compactflash card. Would 'download' do the right thing and place the boot files on the new disk shelf as long as I have set "vol options root root"? Has anyone done something similar, and how large did you make your new root volume? NetApp webpages have widely varying examples varying from 14g to recommendations of 30g or 90g. Our /etc is only 0.25 gigs and I wouldn't expect coredumps to consume more disk space than the filer has memory, and if my filer decides to start coredumping frequently then I will be thinking about the disk space and expanding it, since I can.

2 1

Re: HSM and Netapp
by Louis Elias 24 Mar '05

24 Mar '05

Mike, this is indeed a potential issue. One option might be to use last modified dates in the beginning rather than access dates. Then you can look at the reports to see what the trend is and adjust the policies as necessary. Louis -----Original Message----- From: Sphar, Mike <Mike_Sphar(a)bmc.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Wed Mar 23 19:24:59 2005 Subject: RE: HSM and Netapp Something I'm not clear on for products like these. How do they tell the difference between a user really trying to read a file, and other system level activities that might access the file, such as backups? Whenever we've tried to look into ways of archiving data that isn't being used any more, we always run up against not being able to really tell what isn't being used any more. -----Original Message----- From: Louis Elias [mailto:louis.elias@gmail.com] Sent: Wednesday, March 23, 2005 6:43 PM To: toasters(a)mathworks.com Subject: RE: HSM and Netapp I would like to set the record straight for posterity. NuView has 2 products that can be used to build an ILM strategy. 1.) Virtual File Manager (VFM) is software that can virtualize an enterprise namespace by taking advantage of either MS DFS which is built into the CIFS protocol or NFS. DFS is not an in band solution but rather acts much like DNS by supplying referals to user requests. VFM automates the management of all of the DFS roots through several different policies. One of those policies is a Data Archival Migration policy that will find folders that contain files with attributes you are looking for. So I can say find all of the folders that contain files, 95% of which have not been accessed in 180 days, for instance, and move them to more cost effective storage. If done in conjunction with DFS this move will be transparent to users and applications. It is not HSM but actually moves the files. VFM uses an SQL database (MSDE or SQL server). If it goes down the DFS roots are still available to the users so their is no impact. This is only one small part of what VFM can be used for. 2.) File Lifecycle Manager (FLM) is more like traditional HSM in that it moves files from a filer leaving a stub (not shortcut) behind. When opened the file is pulled back from the nearline storage and opened. This is possible for CIFS and soon NFS (awaiting DOT 7.0.1) data. FLM has other features such as the ability to prevent users from putting or creating files of certain types like .mp3 files on the filer. It is extremely robust and easy to implement. If you have filers whose volumes are filling this is a quick way to alleviate the problem. So depending on your particular need or environment, either of these products can present a lot of possibilities for HSM or ILM. Louis For CIFS data, Microsoft's DFS might also be a usable solution for what the poster had in mind, being able to move data around a bit. *** Are people seeing good results with NuView? I'd heard it runs on the "mini-SQL" database that vendors now ship with products (a subset of Microsoft SQL) and it's not clusterable or configurable in any highly available manner. I understand that if you lose the server running NuView, you lose access to all the migrated data? I'm not trying to lay flamebait, I just want to hear some "5000 mile reports" from people running NuView in the field. JKB

1 0

Re: HSM and Netapp
by Louis Elias 24 Mar '05

24 Mar '05

You can also specify that specific user accounts, machine names, or IP addresses do not cause restores. This is the most common practice for things such as CIFS based backups or virus scanners. Louis -----Original Message----- From: Sto Rage© <netbacker(a)gmail.com> To: Sphar, Mike <Mike_Sphar(a)bmc.com> CC: toasters(a)mathworks.com <toasters(a)mathworks.com> Sent: Wed Mar 23 21:18:58 2005 Subject: Re: HSM and Netapp I have heard that FLM actually has a throttle setting. If it sees a flood of read requests it will disable the recall. On Wed, 23 Mar 2005 19:24:59 -0600, Sphar, Mike <Mike_Sphar(a)bmc.com> wrote: > Something I'm not clear on for products like these. How do they tell the > difference between a user really trying to read a file, and other system > level activities that might access the file, such as backups? > > Whenever we've tried to look into ways of archiving data that isn't being > used any more, we always run up against not being able to really tell what > isn't being used any more. > > -----Original Message----- > From: Louis Elias [mailto:louis.elias@gmail.com] > Sent: Wednesday, March 23, 2005 6:43 PM > To: toasters(a)mathworks.com > Subject: RE: HSM and Netapp > > I would like to set the record straight for posterity. > > NuView has 2 products that can be used to build an ILM strategy. > 1.) Virtual File Manager (VFM) is software that can virtualize an > enterprise namespace by taking advantage of either MS DFS which is > built into the CIFS protocol or NFS. > > DFS is not an in band solution but rather acts much like DNS by > supplying referals to user requests. VFM automates the management of > all of the DFS roots through several different policies. One of those > policies is a Data Archival Migration policy that will find folders > that contain files with attributes you are looking for. So I can say > find all of the folders that contain files, 95% of which have not been > accessed in 180 days, for instance, and move them to more cost > effective storage. If done in conjunction with DFS this move will be > transparent to users and applications. It is not HSM but actually > moves the files. > > VFM uses an SQL database (MSDE or > SQL server). If it goes down the DFS roots are still available to the > users so their is no impact. > > This is only one small part of what VFM can be used for. > > 2.) File Lifecycle Manager (FLM) is more like traditional HSM in that > it moves files from a filer leaving a stub (not shortcut) behind. When > opened the file is pulled back from the nearline storage and opened. > This is possible for CIFS and soon NFS (awaiting DOT 7.0.1) data. > > FLM has other features such as the ability to prevent users from > putting or creating files of certain types like .mp3 files on the > filer. > > It is extremely robust and easy to implement. If you have filers whose > volumes are filling this is a quick way to alleviate the problem. > > So depending on your particular need or environment, either of these > products can present a lot of possibilities for HSM or ILM. > > Louis > > For CIFS data, Microsoft's DFS might also be a usable solution for what > the poster had in mind, being able to move data around a bit. > > *** > > Are people seeing good results with NuView? > > I'd heard it runs on the "mini-SQL" database that vendors now ship with > products (a subset of Microsoft SQL) and it's not clusterable or > configurable in any highly available manner. > > I understand that if you lose the server running NuView, you lose access > to all the migrated data? > > I'm not trying to lay flamebait, I just want to hear some "5000 mile > reports" from people running NuView in the field. > > JKB >

1 0

RE: possible space guarantee "bug" ?
by Stephenson, Burke T. GD 24 Mar '05

24 Mar '05

Did you change/consider the snapshots on your volumes? I would like to know if this is a bug/problem because I am going to 7.x soon. -----Original Message----- From: Charles Bartels [mailto:Charles.Bartels@tradebeam.com] Sent: Tuesday, March 22, 2005 4:50 PM To: toasters(a)mathworks.com Subject: possible space guarantee "bug" ? 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

RE: HSM and Netapp
by Sphar, Mike 24 Mar '05

24 Mar '05

Something I'm not clear on for products like these. How do they tell the difference between a user really trying to read a file, and other system level activities that might access the file, such as backups? Whenever we've tried to look into ways of archiving data that isn't being used any more, we always run up against not being able to really tell what isn't being used any more. -----Original Message----- From: Louis Elias [mailto:louis.elias@gmail.com] Sent: Wednesday, March 23, 2005 6:43 PM To: toasters(a)mathworks.com Subject: RE: HSM and Netapp I would like to set the record straight for posterity. NuView has 2 products that can be used to build an ILM strategy. 1.) Virtual File Manager (VFM) is software that can virtualize an enterprise namespace by taking advantage of either MS DFS which is built into the CIFS protocol or NFS. DFS is not an in band solution but rather acts much like DNS by supplying referals to user requests. VFM automates the management of all of the DFS roots through several different policies. One of those policies is a Data Archival Migration policy that will find folders that contain files with attributes you are looking for. So I can say find all of the folders that contain files, 95% of which have not been accessed in 180 days, for instance, and move them to more cost effective storage. If done in conjunction with DFS this move will be transparent to users and applications. It is not HSM but actually moves the files. VFM uses an SQL database (MSDE or SQL server). If it goes down the DFS roots are still available to the users so their is no impact. This is only one small part of what VFM can be used for. 2.) File Lifecycle Manager (FLM) is more like traditional HSM in that it moves files from a filer leaving a stub (not shortcut) behind. When opened the file is pulled back from the nearline storage and opened. This is possible for CIFS and soon NFS (awaiting DOT 7.0.1) data. FLM has other features such as the ability to prevent users from putting or creating files of certain types like .mp3 files on the filer. It is extremely robust and easy to implement. If you have filers whose volumes are filling this is a quick way to alleviate the problem. So depending on your particular need or environment, either of these products can present a lot of possibilities for HSM or ILM. Louis For CIFS data, Microsoft's DFS might also be a usable solution for what the poster had in mind, being able to move data around a bit. *** Are people seeing good results with NuView? I'd heard it runs on the "mini-SQL" database that vendors now ship with products (a subset of Microsoft SQL) and it's not clusterable or configurable in any highly available manner. I understand that if you lose the server running NuView, you lose access to all the migrated data? I'm not trying to lay flamebait, I just want to hear some "5000 mile reports" from people running NuView in the field. JKB

2 1

← 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