toasters

toasters@lists.teaparty.net

13523 discussions

Start a nNew thread

Fw: Optimal volume size
by Eli Lopez 20 Sep '00

20 Sep '00

1 0

Re: Optimal volume size
by Eli Lopez 20 Sep '00

20 Sep '00

RE: Optimal volume size Hi guys, Backuping on a qtree level gives one very important advantage in case of disaster recovery: You can restore the qtrees on the failed volume in ORDER of importance to the organization. E.g. restore the mail qtree first and the library archives last. Regards, Eli ----- Original Message ----- From: Clarke, John L. (CIS) To: 'toasters(a)mathworks.com' Sent: Tuesday, September 19, 2000 7:38 PM Subject: RE: Optimal volume size a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-( b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare. c) We have a Gigabit network connection, so the 7MB/sec does seem slow.

1 0

RE: Optimal volume size
by Clarke, John L. (CIS) 20 Sep '00

20 Sep '00

a) Yes, we do backup with finer granularity. However, if a RAID group fails, I have to restore the whole thing, so fine granularity does not help much :-( b) Yes, I am thinking about switching to a 10 disk RAID group, with 2 per volume. That makes for 3 shelves, 2 parity disks, and one hot spare. c) We have a Gigabit network connection, so the 7MB/sec does seem slow. -----Original Message----- From: Louis Brune [mailto:lbrune@sd.us.am.ericsson.se] Sent: Tuesday, September 19, 2000 10:47 AM To: toasters(a)mathworks.com Subject: Re: Optimal volume size Fortunately for me, someone else here takes care of backups, but... We have a similar situation on our F740. We want to keep the volume size small because: a) Restores can take forever as the data size gets bigger. Can you not back up with qtree granularity instead of per volume? b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 disks go bad at one time is much rarer than 2 out of 51 disks. You can beat this by using several raid groups per volume. Of course, you need a parity drive for each raid group. c) If you upgrade disks/shelves in the future, you will likely do it a volume at a time. We did this with a volume with 180GB and the volcopy took 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that should be 2-2.5x longer. Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 MB/second. If this is on 100 MB, it's not all that bad. -- Louis

2 1

upgrading from 5.2.3 to 5.3.6.R2
by jmiddlebrooks＠datalink.com 20 Sep '00

20 Sep '00

Any tricks when upgrading from 5.2.3 to 5.3.6R2 aside from making sure the filer is at the correct firmware revision? Do you loose you qtree information or snapshots? Is there a doc on the NOW site on the steps to take to do this particular upgrade. Hopefully it is as simply as untaring the files to the filer and typing download and reboot. Jason Middlebrooks Systems Engineer Datalink Corp. 888-933-9327 x2970

2 1

ssh without password
by Pravin Nair 20 Sep '00

20 Sep '00

Hi, I am trying to find a way to run commands remotely on the filer using ssh from a nfs administrative host. Since Oracle data is on the filer , My basic intention is to bring oracle in warm backup mode , create a snapshot and bring it back to normal mode .I want to automate this process and run it as cron job. The problem is I don't want to use rsh and netapp tells me there is no way to run ssh on the filer without specifying password. Can anyone suggest a way out! Thanks Pravin

2 1

RE: Optimal volume size
by Clarke, John L. (CIS) 19 Sep '00

19 Sep '00

Jeff, We did a local volcopy, moving data from one volume of 18GB FCAL drives to another volume of 36GB drives. It was all internal to the filer. We only have one FC-AL adapter on our F740. We got some volcopy specs from NetApp and the max write speed was something like 18MB/sec for sequential writes. If you did 180GB in 1hr and 20 min, that is around 33MB/sec. How did you manage that? Thanks John > > c) If you upgrade disks/shelves in the future, you will likely do it a > > volume at a time. We did this with a volume with 180GB and the volcopy took > > 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that > > should be 2-2.5x longer. > > How did you run the volcopy? Over the network or local > inside a single filer? What kind of head(s)? > > We've found volcopy to be extremely fast, especially for upgrading disks > and/or migrating data. In fact, we used volcopy to relocate and replicate > a huge chunk of data when Louis' company and ours split and it was a > life saver. We were using F760's, but it took about 1 hr. 20 minutes to > volcopy ~180GB. That was all in one head that had both a FC-AL adapter and > dual SCSI adapters. >

1 0

RE: Optimal volume size
by Mike Sphar 19 Sep '00

19 Sep '00

Our latest server has been configured such that the paths are *almost* identical for UNIX and Windows clients. Essentially, on Windows the UNC paths are \\servername\path\to\files and on UNIX (using automounter) the paths are /servername/path/to/files. Our build group loves it because they now have their build scripts dynamically adjusting the slashes depending on which client they run on, but the actual paths can be set in master config files without regard to which client will read it. -- Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH, GWP, MCP, MCP+I, MCSE, BFD -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, September 19, 2000 10:36 AM To: Louis Brune Cc: toasters(a)mathworks.com Subject: Re: Optimal volume size Hi Louis!! =) Our biggest volumes are 500GB. That is NetApp's recommendation for largest volume size in DOT 6.0 which supports up to 1.5 TB volumes. The problem is that the smaller the volume, the more administrative overhead. Its nice to have one volume on smaller capacity machines because NFS exports and CIFS shares all point at "/some_data" rather than "/vol/vol0/some_data". This also causes difficulties with naming schemes since we like to see the qtree == cifs share (i.e. /some_project == \\filer\some_project). If you have multiple volumes than which of /vol/vol0/some_project and /vol/vol1/some_project is the one pointed at by CIFS share "\\filer\some_project". This statements are nit-picky on my part, but hey, we like to use the KISS principal and multi-volume is just another thing to think about. More on this stuff... On Tue, Sep 19, 2000 at 07:47:17AM -0700, Louis Brune wrote: > We have a similar situation on our F740. We want to keep the volume size > small because: > a) Restores can take forever as the data size gets bigger. > > Can you not back up with qtree granularity instead of per volume? I agree. Backup per qtree. Per volume will take forever on restores, especially for small sets of data. There are one or two drawbacks to per-qtree backups, but at least one of those is fixed in DOT 6.0. =) > b) 10-14 disks is a good compromise on reliability. Having 2 out of 14 > disks go bad at one time is much rarer than 2 out of 51 disks. > > You can beat this by using several raid groups per volume. Of course, > you need a parity drive for each raid group. Again, Louis is on track here. With DOT 5.0 and above, they support multiple RAID groups per volume. Each RAID group can be n-1 on disks and still run fine which achieves the data protection you're looking for. > c) If you upgrade disks/shelves in the future, you will likely do it a > volume at a time. We did this with a volume with 180GB and the volcopy took > 6-7 hours to complete. It is NOT very fast. With 400GB+ in a volume, that > should be 2-2.5x longer. How did you run the volcopy? Over the network or local inside a single filer? What kind of head(s)? We've found volcopy to be extremely fast, especially for upgrading disks and/or migrating data. In fact, we used volcopy to relocate and replicate a huge chunk of data when Louis' company and ours split and it was a life saver. We were using F760's, but it took about 1 hr. 20 minutes to volcopy ~180GB. That was all in one head that had both a FC-AL adapter and dual SCSI adapters. > Hmm. My data-shuffling tends to be in smaller pieces. Wouldn't it be > nice to have a qtreecopy? 7 hours for 180 GB sounds like about 7 > MB/second. If this is on 100 MB, it's not all that bad. Yes! They do have ndmpcopy which will do filer-to-filer data copying, however, there have been bugs posted to toasters regarding it. Something that performed filer-to-filer, per-qtree data moves would be fantastic! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

1 0

RE: reconnect cifs-share at logon
by Hawley, Rob 19 Sep '00

19 Sep '00

Are you using UNIX type authentication (with clear text passwords)? If so, then you are running afoul of a security fix in Windows. The fix requires that the user manually enter a password to avoid you password being compromised. If you are using domain authentication then this should be working for you. Please contact NetApp customer support and let us help you with this problem. Rob Hawley -----Original Message----- From: Ulrich Neumann [mailto:ulrich.neumann@brose.de] Sent: Tuesday, September 19, 2000 9:53 AM To: toasters(a)mathworks.com Subject: reconnect cifs-share at logon does anybody know why reconnect cifs-share at logon will not work with a toaster? i shared a directory and the users manually connect this and set the "reconnect at logon". but after the next logon the mapping is not restored. home-dirs on the toaster will be mapped and also all the shares included in the logon-script. (theres no line in the script to cut the connection ;-) ) the client work all with nt4-clients. with shares on a normal nt4-box we've no probs. greetings from germany Ulrich Neumann

1 0

reconnect cifs-share at logon
by Ulrich Neumann 19 Sep '00

19 Sep '00

does anybody know why reconnect cifs-share at logon will not work with a toaster? i shared a directory and the users manually connect this and set the "reconnect at logon". but after the next logon the mapping is not restored. home-dirs on the toaster will be mapped and also all the shares included in the logon-script. (theres no line in the script to cut the connection ;-) ) the client work all with nt4-clients. with shares on a normal nt4-box we've no probs. greetings from germany Ulrich Neumann

1 0

RE: NetApp/Budtool - poor backup performance
by Rainchik, Aleksandr (MED, Non GE) 19 Sep '00

19 Sep '00

What is scary, is that both hosts - Netapp(slow) and E450(fast) are on the same subnet and have the same network settings 100/full-duplex. The other thing is E450 is pretty busy all the time, with lots of traffic and CPU load - and you can backup it fast, and NetApp is practically not loaded - and it's so slow to backup. -----Original Message----- From: Juan Torres [mailto:torres@susq.com] Sent: Monday, September 18, 2000 4:37 PM To: Rainchik, Aleksandr (MED, Non GE) Cc: toasters(a)mathworks.com Subject: Re: NetApp/Budtool - poor backup performance this is just one of our requests : SIZE TIME PERF HOST PARTITION L KB HH:MM:SS KB/sec STATUS ------------------------------------------------------------------------ ------ {filer} {volume} 0 100558438 08:45:50 3187.59 Success We have dual F720s with trunked 100mb interfaces on a switched network. Our backup host is an E450 with an L11000 locally attched to it with DLT7000s. Using BudTool we have ndmp requests streamed over the wire. Also, our backup host is multi-homed having one of it's interfaces on the same subnet as the filers. (your answer was already in your message) If the backup host you were using (the slow one) is not on the same subnet as the filers and same interface speed, that's where you're bottleneck is (routing and/or bandwidth). BTW: you're safer going over the wire. we've had some libraries hang the scsi bus of the filer when locally attached. -- ******************************************* ** Juan Torres ** Susquehanna Partners, GP. ******************************************* "Rainchik, Aleksandr (MED, Non GE)" wrote: > > Hello, > > We have F720 NetApp that holds about 100Gb of data and we are backing it > up > trough the network, not with directly connected tape. Why? F720 comes > with > differential port for tape connection and our nice tape library is all > single-ended. > > We are using Budtool to do that and it's all done via NDMP. > > And what we have is 1024 K/sec backup speed. So it takes about a 24 > hours > to finish Level 0 on filer. There is a Sun E450 on the same subnet, > plugged to > the same switch, both at 100 full-duplex, going to the same media > server. > And backups are 3 times faster there. > > Is there something I can tweak on filer? Like change priority of ndmpd > process, > something to speed up backups? > > Can you let me know what is your backup speed in NetApp/Budtool > configuration? > > Thank you. > > P.S. We are thinking about getting differential to single-ended SCSI > converters. > Any experience with such converters?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters