toasters November 2006

toasters@lists.teaparty.net

53 participants
50 discussions

RE: Macintosh users can't see network drive
by Glenn Walker 14 Nov '06

14 Nov '06

You might want to capture a quick packet trace on either the MAC or NetApp side (tcpdump on mac, I believe and 'pktt start all -d <directory>' on the Filer - be sure to perform 'pktt stop all' when done with the test). MAC has a notoriously horrible CIFS client - I assume you're using OSX? Glenn -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Maglinger, Paul Sent: Monday, November 13, 2006 4:31 PM To: NetApps list server Subject: FW: Macintosh users can't see network drive Running Version 6.4.5 on a 740 filer. For some reason this morning our Macintosh users cannot see the "public" CIFS drive on our NetApps filer. Because this is a "public" drive, it should be open all of our users. Everything worked fine until this morning and now they cannot see the filer in their Server folder. We've connected to a Windows server using smb://ip_address/shared_directory, but when we try to connect to the filer in the same manner we never get a logon prompt. No pretending here, I don't know diddily-squat about Mac computers. Can someone give advice on how to even start troubleshooting this? ________________________________ Paul Maglinger, A+, CA, CCA, CET, MCSE Systems Administrator Shoe Carnival Inc. (812)867-4674 pmaglinger(a)scvl.com ________________________________

1 0

FW: Macintosh users can't see network drive
by Maglinger, Paul 13 Nov '06

13 Nov '06

Running Version 6.4.5 on a 740 filer. For some reason this morning our Macintosh users cannot see the "public" CIFS drive on our NetApps filer. Because this is a "public" drive, it should be open all of our users. Everything worked fine until this morning and now they cannot see the filer in their Server folder. We've connected to a Windows server using smb://ip_address/shared_directory, but when we try to connect to the filer in the same manner we never get a logon prompt. No pretending here, I don't know diddily-squat about Mac computers. Can someone give advice on how to even start troubleshooting this? ________________________________ Paul Maglinger, A+, CA, CCA, CET, MCSE Systems Administrator Shoe Carnival Inc. (812)867-4674 pmaglinger(a)scvl.com ________________________________

1 0

ndmpcopy, jndmpcopy and multiple level 1 transfers
by Paul Letta 13 Nov '06

13 Nov '06

I am getting ready to do a big data migration. I am planning on doing an initial level 0, and then multiple level 1's leading up to the big day. I know the that native ndmpcopy in OnTap 7.1 can only do one level 1, and one level 2 for each level 0. But I have read that if you get ndmpcopy or jnmdpcopy from ndmp.org that it supports multiple level 1 dumps based on the same level 0. But I am getting the same errors I got with the native ndmpcopy when I use ndmpcopy and jndmpcopy from a unix host. I just grabbed the latest copies for ndmp.org yesterday. > java jndmpcopy.JNdmpcopy -version java version "1.4.2" gcj (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) So I did a level 0, and then one level 1 that both worked just fine. Then I re-ran the level 1 with the same command, and get the errors below. This is the same error I get if I try this with the native ndmpcopy command on the filer itself. I am moving about 1TB of data (about 16M files) off of 1 traditional volume onto multiple new flex vols on the same filer. If what I'm doing is flat out wrong, what would others suggest ? tar wouldn't give me the incrementals and rsync would take a long time with this number of files. Suggestions ? Thanks, Paul > java jndmpcopy.JNdmpcopy filer:/vol/vol0/source filer:/vol/destination -sa xxxxxxx -da xxxxxxx -level 1 Nov 09 03:53:25 [ndmpd:0]: Now waiting for source and destination to finish. SrcFiler: Nov 09 03:53:25 [ndmpd:0]: DUMP: creating "/vol/vol0/../snapshot_for_backup.153" snapshot. SrcFiler: Nov 09 03:53:26 [ndmpd:0]: DUMP: Using subtree dump SrcFiler: Nov 09 03:53:42 [ndmpd:0]: DUMP: Date of this level 1 dump: Thu Nov 9 15:53:25 2006. SrcFiler: Nov 09 03:53:42 [ndmpd:0]: DUMP: Date of last level 0 dump: Thu Nov 9 15:48:10 2006. SrcFiler: Nov 09 03:53:42 [ndmpd:0]: DUMP: Dumping /vol/vol0/source to NDMP connection SrcFiler: Nov 09 03:53:42 [ndmpd:0]: DUMP: mapping (Pass I)[regular files] SrcFiler: Nov 09 03:53:43 [ndmpd:0]: DUMP: mapping (Pass II)[directories] SrcFiler: Nov 09 03:54:09 [ndmpd:0]: DUMP: estimated 18 KB. SrcFiler: Nov 09 03:54:09 [ndmpd:0]: DUMP: dumping (Pass III) [directories] DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: Thu Nov 9 15:54:13 2006: Begin incremental restore DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: This incremental dump does not follow the previous dump that you have restored. DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: This dump is based on Thu Nov 9 15:48:10 2006. DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: It should be based on Thu Nov 9 15:50:28 2006. DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: Could not use tape. DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: RESTORE IS ABORTED Nov 09 03:54:13 [ndmpd:0]: DstFiler just halted. Nov 09 03:54:13 [ndmpd:0]: Reason: ndmp_data_halted_internal_error : Dump aborted. SrcFiler: Nov 09 03:54:13 [ndmpd:0]: DUMP: dumping (Pass IV) [regular files] SrcFiler: Nov 09 03:54:17 [ndmpd:0]: DUMP: Network communication error SrcFiler: Nov 09 03:54:17 [ndmpd:0]: DUMP: DUMP IS ABORTED SrcFiler: Nov 09 03:54:18 [ndmpd:0]: DUMP: Deleting "/vol/vol0/../snapshot_for_backup.153" snapshot. Nov 09 03:54:19 [ndmpd:0]: SrcFiler just halted. Nov 09 03:54:19 [ndmpd:0]: Reason: ndmp_data_halted_internal_error : Dump aborted. Nov 09 03:54:19 [ndmpd:0]: jndmpcopy finished -- Paul Letta Thomas Jefferson National Accelerator Facility Computer Center Unix System Administrator EMail: letta(a)jlab.org Phone: (757)269-5106

4 3

Re: ndmpcopy, jndmpcopy and multiple level 1 transfers
by Jerry 13 Nov '06

13 Nov '06

Never underestimate the power of rsync. Here is what I did to move about 70mil files (lots of tiny files). With lots of tiny files, NDMCOPY spends a lot of time before it really transmits anything. In some cases of 10+ mil files on a busy filer I was waiting 4+ hours for files to begin copying (actual data, not just writing out sparse files for inodes). I found that if I ran a level 0 ndmpcopy on the weekend or during your off hours you can let it beat up the filer a little bit (and it will beat up both CPU and Disk util). Then, during the week run rsync's with --delete to keep things nicely in sync. This is something ndmpcopy can't do (I think).... if you do a level 0 + level 1 you won't get deletes. Doing the "catchup rsync's" gives you a good judge of timing on how long it will take you when you schedule your real outage. I recommend using rsync 2.6.6 or higher as it has significant memory efficiency compared to older versions. I used a 4 CPU Sun V440 to move a lot of data with rsync. Running a single process with a 16 million file list consumes as much as 8GB ram. I almost never found myself CPU bound and I found that CPU on the filer was much lighter than if I was doing an ndmpcopy. All of this depends on your rate of change for files, but overall I think rsync was faster for me after that initial copy. Since rsync wasn't using all my CPU, I broke it into an rsync for each top level directory, as many as 70 rsync processes in some of my migrations at the same time. This allowed me to sync up 16 million files in < 20 minutes in some cases. I suspect the level 1 ndmpcopy would be slower than that, but I'm not 100% sure. At the time of cutover, change the export to be read-only to block people from making change. This doesn't work if you have a subdirectory that is hitting a different export line. In this case I would do a second rsync and see what files were still changing and hunt down apps writing to that volume still. I'd be curious to know which method you end up going with and how it wo Original Message ---- From: Darren Dunham <ddunham(a)taos.com> To: toasters(a)mathworks.com Sent: Friday, November 10, 2006 12:37:19 PM Subject: Re: ndmpcopy, jndmpcopy and multiple level 1 transfers > > I am getting ready to do a big data migration. I am planning on doing > > an initial level 0, and then multiple level 1's leading up to the big day. > > > > It doesn't make sense to me why you would do multiple level 1 copies > because a level 1 does not copy files that have changed since the > previous level 1. To do this you must use a level 2 copy. I agree with the spirt, but I would rephrase it. :-) A level 1 *does* copy all the files that have changed since the previous level 1. It's just that they are a subset of files modified since the level 0 which are copied as well. So running a level 1 on the last day should take about the same amount of time whether any other level 1 copies had been run previously or not. Agreed on the rest about 0/1/2 ndmpcopy, but for flexibility I do like rsync as an alternative. It's just how much power you can toss at it and how long you can wait for the file list when you've got millions of files. Remember you don't have to move everything in one rsync command. Espcially if you have multiple clients, it may may sense to split it up into a few separate subtrees. -- Darren Dunham ddunham(a)taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index

3 2

RE: ndmpcopy, jndmpcopy and multiple level 1 transfers
by George, Andrew 11 Nov '06

11 Nov '06

I wound up doing something similar for one of mine...doing a base level 0 ndmp and then runinning regular robocopies with the /mir flag set to keep both filesystems in synch while I was battling the change-monkeys for a window to actually move the puppy. -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Jerry Sent: Saturday, 11 November 2006 1:34 PM To: Darren Dunham; toasters(a)mathworks.com Subject: Re: ndmpcopy, jndmpcopy and multiple level 1 transfers Never underestimate the power of rsync. Here is what I did to move about 70mil files (lots of tiny files). With lots of tiny files, NDMCOPY spends a lot of time before it really transmits anything. In some cases of 10+ mil files on a busy filer I was waiting 4+ hours for files to begin copying (actual data, not just writing out sparse files for inodes). I found that if I ran a level 0 ndmpcopy on the weekend or during your off hours you can let it beat up the filer a little bit (and it will beat up both CPU and Disk util). Then, during the week run rsync's with --delete to keep things nicely in sync. This is something ndmpcopy can't do (I think).... if you do a level 0 + level 1 you won't get deletes. Doing the "catchup rsync's" gives you a good judge of timing on how long it will take you when you schedule your real outage. I recommend using rsync 2.6.6 or higher as it has significant memory efficiency compared to older versions. I used a 4 CPU Sun V440 to move a lot of data with rsync. Running a single process with a 16 million file list consumes as much as 8GB ram. I almost never found myself CPU bound and I found that CPU on the filer was much lighter than if I was doing an ndmpcopy. All of this depends on your rate of change for files, but overall I think rsync was faster for me after that initial copy. Since rsync wasn't using all my CPU, I broke it into an rsync for each top level directory, as many as 70 rsync processes in some of my migrations at the same time. This allowed me to sync up 16 million files in < 20 minutes in some cases. I suspect the level 1 ndmpcopy would be slower than that, but I'm not 100% sure. At the time of cutover, change the export to be read-only to block people from making change. This doesn't work if you have a subdirectory that is hitting a different export line. In this case I would do a second rsync and see what files were still changing and hunt down apps writing to that volume still. I'd be curious to know which method you end up going with and how it wo Original Message ---- From: Darren Dunham <ddunham(a)taos.com> To: toasters(a)mathworks.com Sent: Friday, November 10, 2006 12:37:19 PM Subject: Re: ndmpcopy, jndmpcopy and multiple level 1 transfers > > I am getting ready to do a big data migration. I am planning on > > doing an initial level 0, and then multiple level 1's leading up to the big day. > > > > It doesn't make sense to me why you would do multiple level 1 copies > because a level 1 does not copy files that have changed since the > previous level 1. To do this you must use a level 2 copy. I agree with the spirt, but I would rephrase it. :-) A level 1 *does* copy all the files that have changed since the previous level 1. It's just that they are a subset of files modified since the level 0 which are copied as well. So running a level 1 on the last day should take about the same amount of time whether any other level 1 copies had been run previously or not. Agreed on the rest about 0/1/2 ndmpcopy, but for flexibility I do like rsync as an alternative. It's just how much power you can toss at it and how long you can wait for the file list when you've got millions of files. Remember you don't have to move everything in one rsync command. Espcially if you have multiple clients, it may may sense to split it up into a few separate subtrees. -- Darren Dunham ddunham(a)taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > ________________________________________________________________________ ____________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index "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: ndmpcopy, jndmpcopy and multiple level 1 transfers
by Sphar, Mike 10 Nov '06

10 Nov '06

Is the source data in qtrees at least? If you haven't already, you might see if Netapp would give you a temporary SnapMirror license. We're doing some migrations also and they gave us some 30day licenses to do the migrations with. -- Michael W. Sphar - IS&T - Lead Systems Administrator SMBU Engineering Support Services, BMC Software -----Original Message----- From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Paul Letta Sent: Friday, November 10, 2006 7:22 AM To: toasters(a)mathworks.com Subject: ndmpcopy, jndmpcopy and multiple level 1 transfers I am getting ready to do a big data migration. I am planning on doing an initial level 0, and then multiple level 1's leading up to the big day. I know the that native ndmpcopy in OnTap 7.1 can only do one level 1, and one level 2 for each level 0. But I have read that if you get ndmpcopy or jnmdpcopy from ndmp.org that it supports multiple level 1 dumps based on the same level 0. But I am getting the same errors I got with the native ndmpcopy when I use ndmpcopy and jndmpcopy from a unix host. I just grabbed the latest copies for ndmp.org yesterday. > java jndmpcopy.JNdmpcopy -version java version "1.4.2" gcj (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3) So I did a level 0, and then one level 1 that both worked just fine. Then I re-ran the level 1 with the same command, and get the errors below. This is the same error I get if I try this with the native ndmpcopy command on the filer itself. I am moving about 1TB of data (about 16M files) off of 1 traditional volume onto multiple new flex vols on the same filer. If what I'm doing is flat out wrong, what would others suggest ? tar wouldn't give me the incrementals and rsync would take a long time with this number of files. Suggestions ? Thanks, Paul > java jndmpcopy.JNdmpcopy filer:/vol/vol0/source filer:/vol/destination -sa xxxxxxx -da xxxxxxx -level 1 Nov 09 03:53:25 [ndmpd:0]: Now waiting for source and destination to finish. SrcFiler: Nov 09 03:53:25 [ndmpd:0]: DUMP: creating "/vol/vol0/../snapshot_for_backup.153" snapshot. SrcFiler: Nov 09 03:53:26 [ndmpd:0]: DUMP: Using subtree dump SrcFiler: Nov 09 03:53:42 [ndmpd:0]: DUMP: Date of this level 1 dump: Thu Nov 9 15:53:25 2006. SrcFiler: Nov 09 03:53:42 [ndmpd:0]: DUMP: Date of last level 0 dump: Thu Nov 9 15:48:10 2006. SrcFiler: Nov 09 03:53:42 [ndmpd:0]: DUMP: Dumping /vol/vol0/source to NDMP connection SrcFiler: Nov 09 03:53:42 [ndmpd:0]: DUMP: mapping (Pass I)[regular files] SrcFiler: Nov 09 03:53:43 [ndmpd:0]: DUMP: mapping (Pass II)[directories] SrcFiler: Nov 09 03:54:09 [ndmpd:0]: DUMP: estimated 18 KB. SrcFiler: Nov 09 03:54:09 [ndmpd:0]: DUMP: dumping (Pass III) [directories] DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: Thu Nov 9 15:54:13 2006: Begin incremental restore DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: This incremental dump does not follow the previous dump that you have restored. DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: This dump is based on Thu Nov 9 15:48:10 2006. DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: It should be based on Thu Nov 9 15:50:28 2006. DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: Could not use tape. DstFiler: Nov 09 03:54:13 [ndmpd:0]: RESTORE: RESTORE IS ABORTED Nov 09 03:54:13 [ndmpd:0]: DstFiler just halted. Nov 09 03:54:13 [ndmpd:0]: Reason: ndmp_data_halted_internal_error : Dump aborted. SrcFiler: Nov 09 03:54:13 [ndmpd:0]: DUMP: dumping (Pass IV) [regular files] SrcFiler: Nov 09 03:54:17 [ndmpd:0]: DUMP: Network communication error SrcFiler: Nov 09 03:54:17 [ndmpd:0]: DUMP: DUMP IS ABORTED SrcFiler: Nov 09 03:54:18 [ndmpd:0]: DUMP: Deleting "/vol/vol0/../snapshot_for_backup.153" snapshot. Nov 09 03:54:19 [ndmpd:0]: SrcFiler just halted. Nov 09 03:54:19 [ndmpd:0]: Reason: ndmp_data_halted_internal_error : Dump aborted. Nov 09 03:54:19 [ndmpd:0]: jndmpcopy finished -- Paul Letta Thomas Jefferson National Accelerator Facility Computer Center Unix System Administrator EMail: letta(a)jlab.org Phone: (757)269-5106

1 0

RE: ssh config on DOT 7
by Creek, Toby 09 Nov '06

09 Nov '06

Vmware's client doesn't have 3des-cbc in its list of available ciphers, although it is compiled in. Add "3des-cbc" to the end of the Ciphers line in the /etc/ssh.conf and it'll work fine. That's the only cipher the NetApp implements. Toby > -----Original Message----- > From: Glenn Dekhayser [mailto:gdekhayser@voyantinc.com] > Sent: Wednesday, November 08, 2006 3:20 PM > To: Darren Dunham; toasters(a)mathworks.com > Subject: RE: ssh config on DOT 7 > > Well, we had the problem when trying to get SSH scripting > working with VMWare ESX 3 and the Netapp, and we did in fact > need authorized_keys2 on both the VMWare and the Netapp box > in order to get RSA/SSHv2 working. > We tried for a long time to get that working, perhaps we were > missing something. When we mentioned this to Netapp they > confirmed that our assessment was correct and they edited the docs. > > > > Be CAREFUL here: the filename is "authorized_keys2" for the SSH > > version2 file, the docs didn't say that, I actually told > netapp about > > that Doc bug. Authorized_keys is for version 1, which you shouldn't > be > > using anymore. Netapp's SSH client is based on OpenSSH so you can > > follow any docs on that to see how it really works. > > Then that would be a difference from the standard OpenSSH releases. > OpenSSH does not require the use of "authorized_keys2" (or > hasn't for years). Both v1 and v2 keys happily live together > in the default location of ".ssh/authorized_keys". > > I haven't used this feature in OnTAP, so I don't know if it > is required for setup there. > > -- > Darren Dunham > ddunham(a)taos.com > Senior Technical Consultant TAOS > http://www.taos.com/ > Got some Dr Pepper? San Francisco, > CA bay area > < This line left intentionally blank to confuse you. > > >

1 0

RE: ssh config on DOT 7
by Potakamuri, Sreenivasa 08 Nov '06

08 Nov '06

All public keys should simply be put into the "authorized_keys" file for both SSH protocols 1 and 2 for public key authentication. This is true for all versions of ONTAP. "authorized_keys2" file was an alternative location for SSH2 protocol, and its use has been deprecated in NetApp's SSH implementation. For backward compatibility, NetApp's SSH implementation still looks for keys in "authorized_keys2" file. Regards, Sreenivasa Potakamuri Network Appliance !-----Original Message----- !From: Glenn Dekhayser [mailto:gdekhayser@voyantinc.com] !Sent: Wednesday, November 08, 2006 8:48 AM !To: toasters(a)mathworks.com !Subject: RE: ssh config on DOT 7 ! ! !Be CAREFUL here: the filename is "authorized_keys2" for the SSH !version2 file, the docs didn't say that, I actually told netapp about !that Doc bug. Authorized_keys is for version 1, which you shouldn't be !using anymore. Netapp's SSH client is based on OpenSSH so you can !follow any docs on that to see how it really works. ! !Glenn (the other one) ! !-----Original Message----- ! !> Hello all, !> !> So I finally got DOT 7 put into production so I can now use ssh !> without an addition license. My question is where do I put my !> authorized_keys file so I can use key based authentication on the !> netapp? (i.e. where is or where should I create the .ssh directory) !> !> Thanks for any help, !> ! !

1 0

ssh config on DOT 7
by Sheldon Mustard 08 Nov '06

08 Nov '06

Hello all, So I finally got DOT 7 put into production so I can now use ssh without an addition license. My question is where do I put my authorized_keys file so I can use key based authentication on the netapp? (i.e. where is or where should I create the .ssh directory) Thanks for any help, SJM -- Sheldon Mustard smustard(a)gmail.com "There will be no order, only chaos." - Pi (1998) --

6 8

Re: 7.2 stability
by Grey Friday 08 Nov '06

08 Nov '06

We are running 7.2P2 as well for bug 213380 The components in Filer View applets are disabled when SSL is enabled on the filer But only on non important things. I was hoping that this was a decent rel. but apparently not. I would like to make use of CIFS being in it's own domain but maybe not till later eh... I don't have the link off the top of my head but I think 7.0.5 is the only GD rel currently. Some one correct me if I'm wrong. If anyone else knows anything CIFS related please share it. We have more CIFS than anything in this environment. Thanks, Grey- On 11/7/06, Willeke, Jochen <Jochen.Willeke(a)wincor-nixdorf.com> wrote: Hi Grey, > > we have already deployed 7.2P2 and it has a Bug in WAFL which makes the > filer reboot for some kind of reason. > Sadly we where hit by this error just 5 hours after installing > 7.2P2...Luckily never again :D > > Netapp provided a patch 7.2P2D2 espacially for this problem which will > be installed this weekend on our systems. > > I think you should wait until it is GD. BTW there was a link on NOW > where i could see all releases and which ones are GD but i do not find > it anymore. Do you know where it can be found on NOW? > > Regards > > Jochen > > -----Original Message----- > From: owner-toasters(a)mathworks.com [mailto:owner-toasters@mathworks.com] > On Behalf Of Grey Friday > Sent: Tuesday, November 07, 2006 5:43 PM > To: toasters(a)mathworks.com > Subject: 7.2 stability > > So what's the word on 7.2 ready for install or still hold off? >

1 1

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 November 2006