toasters

toasters@lists.teaparty.net

13531 discussions

RE: boot volume with no data
by Mike Sphar 14 Aug '01

14 Aug '01

I agree that using 9Gb drives is *better* than using larger drives for a separate root volume, but even then you're still using 27Gb of disk space for what is generally an under 100Mb set of data, and it reduces the max capacity of the filer by (what I feel is) a significant amount. Like others have mentioned, I think I great future enhancement to the product line would be a separate set of media for the root volume, whether that's flash disks, microdrives, whatever. -----Original Message----- From: Marchand, Paul [mailto:Paul.Marchand@netapp.com] Sent: Tuesday, August 14, 2001 10:26 AM To: Fox, Adam; 'neil lehrer'; toasters Subject: RE: boot volume with no data I agree with Adam except I do like a separate root volume as it makes life much easier for all the reasons he mentioned. It is a huge waste of space unless you can convince the customer to purchase 3 9 gig drives, 2 for root 1 for parity in addition to their other storage requirements. You don't waste as much space that way and just maybe the customer may buy an extra shelf with only 3 bays occupied which could accommodate 4 more drives at a future point in time. -Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul E. Marchand Network Appliance ~ Systems Engineer fast simple reliable marchand(a)netapp.com 408.822.3213 415.793.8881(cell) -----Original Message----- From: Fox, Adam [mailto:Adam.Fox@netapp.com] Sent: Tuesday, August 14, 2001 9:54 AM To: 'neil lehrer'; toasters Subject: RE: boot volume with no data Okay, I've heard lots of debates on this, here's my opinion and I'm sure others will disagree. I'm not a big fan of root-only volumes. I think that overall they are a big waste of space for very little gain. However, there are some good reasons to do it depending on your scenario. 1. SnapMirror. If you are SnapMirroring all of your data then it is a good idea to have your root volume on a separate volume. This allows you to offline your data volumes at will which is good for initial transfers or resynching back to a source. 2. SnapRestore. If your application or dataset makes regular use of SnapRestore..yes I've seen this in a case where customers like to snapshot a known good dataset, have their users mess with it, then SnapRestore back to the known good dataset afterwards. If this is your scenario, then yes, a root volume is a good idea. 3. Lots of vol copy'ing. If you do lots of vol copy commands in your dataset, then for the same reason as SnapMirror, the offline ability is a good one. There may be others out there in the world, but these are the most common. But in my opinion, for the 50-60MB that /etc typically takes up, is it worth dedicating 2 36GB or 72GB drives? Maybe so, but most of my customers don't think so. Just one geek's opinion. There isn't really a single right or wrong answer on this one. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: neil lehrer [mailto:nlehrer@ibb.gov] > Sent: Tuesday, August 14, 2001 11:56 AM > To: toasters > Subject: boot volume with no data > > > are there any particular advantages or disadvantages to just > having ontap on > vol0 and data on other volumes? > -- > > > regards >

2 1

RE: boot volume with no data
by Honeycutt, Michael 14 Aug '01

14 Aug '01

Here's a good one for keeping the data seperate. Not long after my first data migration to the filer, I accidentally added a disk to the root volume. Luckly you can copy the /etc to another volume and change the target root volume. If I would have had that 100GB of data on the root volume as well, it wouldnt had been so much fun to fix. Can anyone say oops? -----Original Message----- From: Mike Sphar [mailto:mikey@Remedy.COM] Sent: Tuesday, August 14, 2001 1:58 PM To: toasters Subject: RE: boot volume with no data I agree that using 9Gb drives is *better* than using larger drives for a separate root volume, but even then you're still using 27Gb of disk space for what is generally an under 100Mb set of data, and it reduces the max capacity of the filer by (what I feel is) a significant amount. Like others have mentioned, I think I great future enhancement to the product line would be a separate set of media for the root volume, whether that's flash disks, microdrives, whatever. -----Original Message----- From: Marchand, Paul [mailto:Paul.Marchand@netapp.com] Sent: Tuesday, August 14, 2001 10:26 AM To: Fox, Adam; 'neil lehrer'; toasters Subject: RE: boot volume with no data I agree with Adam except I do like a separate root volume as it makes life much easier for all the reasons he mentioned. It is a huge waste of space unless you can convince the customer to purchase 3 9 gig drives, 2 for root 1 for parity in addition to their other storage requirements. You don't waste as much space that way and just maybe the customer may buy an extra shelf with only 3 bays occupied which could accommodate 4 more drives at a future point in time. -Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul E. Marchand Network Appliance ~ Systems Engineer fast simple reliable marchand(a)netapp.com 408.822.3213 415.793.8881(cell) -----Original Message----- From: Fox, Adam [mailto:Adam.Fox@netapp.com] Sent: Tuesday, August 14, 2001 9:54 AM To: 'neil lehrer'; toasters Subject: RE: boot volume with no data Okay, I've heard lots of debates on this, here's my opinion and I'm sure others will disagree. I'm not a big fan of root-only volumes. I think that overall they are a big waste of space for very little gain. However, there are some good reasons to do it depending on your scenario. 1. SnapMirror. If you are SnapMirroring all of your data then it is a good idea to have your root volume on a separate volume. This allows you to offline your data volumes at will which is good for initial transfers or resynching back to a source. 2. SnapRestore. If your application or dataset makes regular use of SnapRestore..yes I've seen this in a case where customers like to snapshot a known good dataset, have their users mess with it, then SnapRestore back to the known good dataset afterwards. If this is your scenario, then yes, a root volume is a good idea. 3. Lots of vol copy'ing. If you do lots of vol copy commands in your dataset, then for the same reason as SnapMirror, the offline ability is a good one. There may be others out there in the world, but these are the most common. But in my opinion, for the 50-60MB that /etc typically takes up, is it worth dedicating 2 36GB or 72GB drives? Maybe so, but most of my customers don't think so. Just one geek's opinion. There isn't really a single right or wrong answer on this one. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: neil lehrer [mailto:nlehrer@ibb.gov] > Sent: Tuesday, August 14, 2001 11:56 AM > To: toasters > Subject: boot volume with no data > > > are there any particular advantages or disadvantages to just > having ontap on > vol0 and data on other volumes? > -- > > > regards >

1 0

What does Z for CP-type in sysstat -u output mean?
by Chris Thompson 14 Aug '01

14 Aug '01

I have just seen a "Z" in the "CP ty(pe)" column of some "sysstat -u" output (with ONTAP 6.1.1). Anyone know what this one means? It's not listed in the na_sysstat(1) man page. It occurred shortly before a scheduled snapshot that gave the expected "S". Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

1 0

RE: boot volume with no data
by Marchand, Paul 14 Aug '01

14 Aug '01

I agree with Adam except I do like a separate root volume as it makes life much easier for all the reasons he mentioned. It is a huge waste of space unless you can convince the customer to purchase 3 9 gig drives, 2 for root 1 for parity in addition to their other storage requirements. You don't waste as much space that way and just maybe the customer may buy an extra shelf with only 3 bays occupied which could accommodate 4 more drives at a future point in time. -Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Paul E. Marchand Network Appliance ~ Systems Engineer fast simple reliable marchand(a)netapp.com 408.822.3213 415.793.8881(cell) -----Original Message----- From: Fox, Adam [mailto:Adam.Fox@netapp.com] Sent: Tuesday, August 14, 2001 9:54 AM To: 'neil lehrer'; toasters Subject: RE: boot volume with no data Okay, I've heard lots of debates on this, here's my opinion and I'm sure others will disagree. I'm not a big fan of root-only volumes. I think that overall they are a big waste of space for very little gain. However, there are some good reasons to do it depending on your scenario. 1. SnapMirror. If you are SnapMirroring all of your data then it is a good idea to have your root volume on a separate volume. This allows you to offline your data volumes at will which is good for initial transfers or resynching back to a source. 2. SnapRestore. If your application or dataset makes regular use of SnapRestore..yes I've seen this in a case where customers like to snapshot a known good dataset, have their users mess with it, then SnapRestore back to the known good dataset afterwards. If this is your scenario, then yes, a root volume is a good idea. 3. Lots of vol copy'ing. If you do lots of vol copy commands in your dataset, then for the same reason as SnapMirror, the offline ability is a good one. There may be others out there in the world, but these are the most common. But in my opinion, for the 50-60MB that /etc typically takes up, is it worth dedicating 2 36GB or 72GB drives? Maybe so, but most of my customers don't think so. Just one geek's opinion. There isn't really a single right or wrong answer on this one. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com > -----Original Message----- > From: neil lehrer [mailto:nlehrer@ibb.gov] > Sent: Tuesday, August 14, 2001 11:56 AM > To: toasters > Subject: boot volume with no data > > > are there any particular advantages or disadvantages to just > having ontap on > vol0 and data on other volumes? > -- > > > regards >

1 0

RE: boot volume with no data
by Collins, Jim 14 Aug '01

14 Aug '01

On the negative side I assume you would still need a parity just for Vol0. This might be a waste if you are tight on storage. The plus side is you may have more flexibility moving (physically) volumes from one filer to the next in the event of a head crash. I am considering doing the same thing with vol0. I guess something like this should be considered if you have more than one filer and they are not clustered. In my case we have a F740 & F760. It would be nice if they could be clustered but I don't think they can. My thinking is that if the head crashed on either filer the volume/shelf could be moved to the other filer and would be recognized as a forerun volume. -----Original Message----- From: neil lehrer [mailto:nlehrer@ibb.gov] Sent: Tuesday, August 14, 2001 10:56 AM To: toasters Subject: boot volume with no data are there any particular advantages or disadvantages to just having ontap on vol0 and data on other volumes? -- regards

1 0

RE: boot volume with no data
by Noll, Kevin 14 Aug '01

14 Aug '01

When using SnapMirror, you would not SnapMirror your root volume. -----Original Message----- From: neil lehrer [mailto:nlehrer@ibb.gov] Sent: 14 August 2001 16:56 To: toasters Subject: boot volume with no data are there any particular advantages or disadvantages to just having ontap on vol0 and data on other volumes? -- regards ******************************************************************************************** " This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message ". ********************************************************************************************

1 0

Re: NetApps and commodity drives
by Daniel Feenberg 11 Aug '01

11 Aug '01

Numerous persons have told me that 3rd party drives are forbidden in the NetApp support contract. But we want a lot of storage...and NetApp charges three times as much... and both drives are Seagate...and here is the text of the support contract at http://now.netapp.com/NOW/products/agreement/agree_2000.shtml: >2.8 Exclusions. >Our warranties and maintenance agreements do not apply to, nor do prices >include maintenance of, the repair or diagnosis of damage, malfunctions >or product failures caused by: (a) you or any third party; (b) accident, >misuse or abuse; (c) the installation, repair or alteration of our >product (including modification of software) by anyone other than us or a >NetApp Service Provider; (d) products not sold by NetApp that are >attached to or used with our products, even if those products are sold by >one of our authorized resellers... Which I take to mean that that they fix only the NetApp supplied part of the device, if something breaks. This same clause appears to regulate 3rd party drives and tape backup units, which are of course, very widespread. I also note that a large number of Seagate drives are listed as compatible in http://now.netapp.com/NOW/download/tools/diskfw/, although the model numbers use a slightly different format than the Seagate site uses. There is also the NOW page about disk qualification (http://now.netapp.com/NOW/download/tools/diskqual/) which includes the following text: >The Disk Qualification Requirement text file adds information about >second-source disk drives to the device qualification matrix in your >filer. The only 72 gigabyte FC Seagate that I can find has a slightly different part number from the one mentioned in the NetApp support documents, but I had been hoping the difference wasn't significant. Looks like it is, though. I suspect the difference is that NetApp wants to use 520 byte sectors, and Seagate defaults to 512, and I don't know how to switch. So I am surprised that everyone thinks that 3rd party drives are forbidden by the support agreement. I agree that they aren't supported, but that isn't the same thing as geing forbidden. Daniel Feenberg feenberg(a)nber.org

3 3

Re: Number of qtrees on a volume?
by Chris Thompson 10 Aug '01

10 Aug '01

I wrote: [...] > It does indeed, but I don't think I believe it: the limit should be > 254 per *volume*. I've confirmed this by creating 254 qtrees in a /vol/test when there are plenty in other volumes as well. On attempting to "qtree create" the 255th, you get the error qtree: cannot create more than 254 qtrees. Chris Thompson University of Cambridge Computing Service, Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, Phone: +44 1223 334715 United Kingdom.

1 0

RE: Number of qtrees on a volume?
by Bond, Andrew 10 Aug '01

10 Aug '01

This is correct. I just tested it to be sure. 254 per volume. Regards, Andrew PS. Chris, I think we both need to get a life - I'm off to do that now! :) > -----Original Message----- > From: Chris Thompson [mailto:cet1@cus.cam.ac.uk] > Sent: 10 August 2001 21:58 > To: nlehrer(a)ibb.gov > Cc: drechsau(a)tiny.net; toasters(a)mathworks.com > Subject: Re: Number of qtrees on a volume? > > > nlehrer(a)ibb.gov (neil lehrer) writes [top'n'tail'd]: > > > > Mike Horwath wrote: > > > > > > Anyone give me an ideas as to the maximum? > > > > > > > man page for 6.x says 254 per filer. > > It does indeed, but I don't think I believe it: the limit should be > 254 per *volume*. The TID values for qtrees in different volumes are > not disjoint. > > Chris Thompson University of Cambridge > Computing Service, > Email: cet1(a)ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QG, > Phone: +44 1223 334715 United Kingdom. >

1 0

Number of qtrees on a volume?
by Mike Horwath 10 Aug '01

10 Aug '01

Anyone give me an ideas as to the maximum? -- Mike Horwath Admin & Manager @ VISI.com WORK: drechsau(a)visi.com IRC: Drechsau http://www.visi.com/ HOME: drechsau(a)geeks.org The only Minnesota ISP with public statistics: http://noc.visi.com/ Garbage In -- Gospel Out. - berkeley fortune(6)

3 3

RE: Number of qtrees on a volume?
by McCarthy, Tim 10 Aug '01

10 Aug '01

256 per volume -----Original Message----- From: Mike Horwath [mailto:drechsau@tiny.net] Sent: Friday, August 10, 2001 3:35 PM To: toasters(a)mathworks.com Subject: Number of qtrees on a volume? Anyone give me an ideas as to the maximum? -- Mike Horwath Admin & Manager @ VISI.com WORK: drechsau(a)visi.com IRC: Drechsau http://www.visi.com/ HOME: drechsau(a)geeks.org The only Minnesota ISP with public statistics: http://noc.visi.com/ Garbage In -- Gospel Out. - berkeley fortune(6)

2 1

qtrees
by Deena Matarazzo 10 Aug '01

10 Aug '01

I have a qtree on a directory and would also like to set some limits on subdirectories within that directory. Is there anyway to do this?

2 1

RE: Direct attaching SCSI tape drives to 760's
by Parsons, Steve 10 Aug '01

10 Aug '01

Andrew, Network Appliance recommends against hot-plugging of SCSI tape and library devices. The 68-pin connector is not defined as a hot-plug connector and does not provide electrical safety for either the adapter or the device. Most of the time, a hot-plug won't hurt anything, but on occasion you'll blow a transceiver. The SCA connector used on disk drives is designed to assure a square connection with ground mating occurring first. The 68-pin connector on tape drives is not so designed. Steve -----Original Message----- From: Andrew Toon [mailto:andrew.toon@tracegroup.com] Sent: Thursday, August 09, 2001 3:58 AM To: 'Paul Letta' Cc: 'toasters(a)mathworks.com' Subject: RE: Direct attaching SCSI tape drives to 760's I have had to remove a d6irectly attached tape drive a few time on my F740. It hasn't caused any problems. However when I attach a new drive it will only recognise it if I do a reboot. I don't know if there's something similar to the Solaris "drvconfig" command but if not it would be a great feature to have. Andrew Toon Technical Services Manager Trace Computers Plc -----Original Message----- From: Paul Letta [ mailto:letta@jlab.org <mailto:letta@jlab.org> ] Sent: 07 August 2001 17:18 To: toasters(a)mathworks.com Subject: Direct attaching SCSI tape drives to 760's Does anybody have any comments in regard to direct attaching SCSI drives 760's ? My concern is what happens when the drives fail ? I seem to have a drive failure rate of 3 or 4 a year. Currently I do not direct attach, so replacing them is no problem. But what happens to the filers when you remove a SCSI tape device hot ? Can you reattach a new one without rebooting the filer ? I do not think my environment would stand for a filer reboot each time a tape drive fails, but I really do not want to live with the 4MB/Sec I get for backups over the network now. Any thoughts? Thanks, Paul Disclaimer This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Trace Computers PLC. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this mail is strictly prohibited

1 0

jumbo frames
by Zekeriya Eskiocak 10 Aug '01

10 Aug '01

Hi All, Anybody has experience with using Jumbo Frames in Netapp F740-Oracle8.0&IBM AIX environment? Any recommendation is appreciated. Thanks Zekeriya Eskiocak System Engineer Prolink Services Kayisdagi Cad. No 105 Kucukbakkalkoy 81120 Istanbul-TURKIYE- Work:+90 216 573 73 00 (Ext.107) Mobile:+90 532 761 80 69

1 0

Re: vif's and failover
by mds＠gbnet.net 09 Aug '01

09 Aug '01

Sun's Cluster and the non-clustered IPMP use simple ICMP echo between the active and back-up interfaces to evaluate their health and decide when it's appropriate to fail over. In fact I believe they send an ICMP echo to the appropriate network broadcast address, so that, as long as the switch, a router or a client machine responds failover doesn't take place, and as soon as the network goes suspiciously quiet a failover is undertaken whether the ethernet link is still detected or not. As has been said, it's a fairly basic precaution in a clustered environment to trust as little as possible and to examine the actual service you care about as closely as possible. I also don't believe this is patented, or rocket science. On Thu 9 Aug, 2001, Sam Cramer <cramer(a)netapp.com> wrote: > > Does anyone have any experience with this? Can someone confirm or deny > > the failover in the event of loss of dataflow, but not loss of link? > > The vif code detects the loss of link status, not the loss of dataflow. > Only the loss of link status will cause a failover. > > Sam > >-- End of excerpt from Sam Cramer -- -Mark ... an Englishman in London ...

1 0

Re: vif's and failover
by Sam Cramer 09 Aug '01

09 Aug '01

> Does anyone have any experience with this? Can someone confirm or deny > the failover in the event of loss of dataflow, but not loss of link? The vif code detects the loss of link status, not the loss of dataflow. Only the loss of link status will cause a failover. Sam

2 1

vif's and failover
by Jordan Share 09 Aug '01

09 Aug '01

So, we had a switch fail today. It failed in such a way that link was maintained on the ports, it just didn't pass any packets. When this happened, the vif that I had created on our filer did not switch over to the backup link (on another switch). I initially thought it was because I hadn't set it to check to make sure that traffic was actually flowing out the interfaces. However, then I couldn't find anywhere to actually do that. What's the deal here? Did I totally miss something? How exactly does failover work, anyway? Thanks, Jordan

2 3

Networker backup using cifs
by David C Baumgardner 09 Aug '01

09 Aug '01

I have been using legato Networker 6.0.1 running on a Windows NT box to back up my NetApp 720. The tape drive is a DLT8000 attached to the NT box. I mapped the c$ share on the Filer and put it in the Networker client as "\\oineap01\c$". oineap01 being the name of the filer. Full backup was taking 4 hours for 40 gb of data. Now that has changed to 12 hours with the following error messages; 08/09/01 08:35:33 nsrexecd: failed to write NUL handshake on 232: errno 154, Connection reset by peer 08/09/01 08:35:55 savegrp: oipc4190.owens-ill.com:\\oineap01\c$ abandoned. 08/09/01 08:35:55 savegrp: oipc4190.owens-ill.com:\\oineap01\c$ will retry 0 more time(s) 08/09/01 08:38:31 nsrd: savegroup alert: Default completed, 1 client(s) (oipc4190.owens-ill.com Failed) * oipc4190.owens-ill.com:\\oineap01\c$ has been inactive for 35 minutes since Thu Aug 09 08:00:33 2001. * oipc4190.owens-ill.com:\\oineap01\c$ is being abandoned by nsrexec. 08/09/01 08:38:32 nsrd: runq: NSR group Default exited with return code 1. It still goes on and completes the backup and I can recover files from that backup with no problem. Has anyone ran into this and /or know what is going on? David Baumgardner CAD/CAM Administrator Container Engineering 419.247.8274

1 0

RE: Direct attaching SCSI tape drives to 760's
by Andrew Toon 09 Aug '01

09 Aug '01

I have had to remove a d6irectly attached tape drive a few time on my F740. It hasn't caused any problems. However when I attach a new drive it will only recognise it if I do a reboot. I don't know if there's something similar to the Solaris "drvconfig" command but if not it would be a great feature to have. Andrew Toon Technical Services Manager Trace Computers Plc -----Original Message----- From: Paul Letta [mailto:letta@jlab.org] Sent: 07 August 2001 17:18 To: toasters(a)mathworks.com Subject: Direct attaching SCSI tape drives to 760's Does anybody have any comments in regard to direct attaching SCSI drives 760's ? My concern is what happens when the drives fail ? I seem to have a drive failure rate of 3 or 4 a year. Currently I do not direct attach, so replacing them is no problem. But what happens to the filers when you remove a SCSI tape device hot ? Can you reattach a new one without rebooting the filer ? I do not think my environment would stand for a filer reboot each time a tape drive fails, but I really do not want to live with the 4MB/Sec I get for backups over the network now. Any thoughts? Thanks, Paul Disclaimer This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Trace Computers PLC. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this mail is strictly prohibited

1 0

Configuring Veritas Business Server with NDMP option on a HP9000/ J6000 part II
by Schepers, Jan 09 Aug '01

09 Aug '01

Hello all, Of course my description is not complete witnessing the fact that I received a number of questions wrt the configuration. I have problems configuring 0 Veritas Netbackup Business Server 3.4GA with an 0 NDMP option running on a 0 HP9000/J6000 (HPUX 11.00) as management server to backup a 0 F850 running Ontap 6.0.1 that has a 0 HP C7145-8000 DLT8K library connected to it. When I try to do a "robot inventory", I get the error message "robot inventory failed: Unable to open robotic path (201)" At the same time the filer console shows the following messages: Wed Aug 8 18:20:09 CES [Java Thread:warning]: Ndmpd25: Top level IOException Wed Aug 8 18:20:09 CES [Java Thread:warning]: Ndmpd25: IO exception: Socket closed. What simple thing did I do wrong ? regards, YS Output of some commands: root# telnet waal Trying... Connected to waal. Escape character is '^]'. Local flow control off Password: waal> version NetApp Release 6.0.1: Sat Dec 2 00:46:34 PST 2000 waal> Connection closed by foreign host. waal> ndmpd status ndmpd ON. No ndmpd sessions active. waal> sysconfig -m Media changer (5b.0) HP C7145-8000 mc0 - media changer device waal> sysconfig -t Tape drive (5b.1) Quantum DLT8000 rst0l - rewind device, format is: 81633 bpi 40 GB (w/comp) nrst0l - no rewind device, format is: 81633 bpi 40 GB (w/comp) urst0l - unload/reload device, format is: 81633 bpi 40 GB (w/comp) rst0m - rewind device, format is: 85937 bpi 35 GB nrst0m - no rewind device, format is: 85937 bpi 35 GB urst0m - unload/reload device, format is: 85937 bpi 35 GB rst0h - rewind device, format is: 85937 bpi 50 GB (w/comp) nrst0h - no rewind device, format is: 85937 bpi 50 GB (w/comp) urst0h - unload/reload device, format is: 85937 bpi 50 GB (w/comp) rst0a - rewind device, format is: 85937 bpi 70 GB (w/comp) nrst0a - no rewind device, format is: 85937 bpi 70 GB (w/comp) urst0a - unload/reload device, format is: 85937 bpi 70 GB (w/comp) root# /usr/openv/volmgr/bin/set_ndmp_attr -verify waal Connecting to host "waal" as user "root"... Waiting for connect notification message... Opening session with NDMP protocol version 2... Host info is: host name "waal" os type "NetApp" os version "NetApp Release 6.0.1" host id "0033590107" host supports TEXT authentication host supports MD5 authentication Getting MD5 challenge from host... Logging in using MD5 method... Login was successful Opening SCSI device "mc0"... Setting SCSI target controller 0 id 0 lun 0... Inquiry result is "HP C7145-8000 2260c060p.04" Opening SCSI device "spt0"... Setting SCSI target controller 4 id 0 lun 0... Inquiry result is "HP C7145-8000 2260c060p.04"

1 0

Re: restore is very expensive
by Steve Losen 08 Aug '01

08 Aug '01

Thanks to Emmett Hogan, who I think was too shy to post to the whole list. Emmett suggested that I try smbclient, which just so happens to be installed on the unix NFS client where I create the accounts. With smbclient I can make a CIFS connection and get a command line prompt. At the prompt I can type "setmode filename +h" and this turns on the DOS hidden bit for filename. I can feed a file of commands to smbclient, so I think I will modify my bulk account script to use tar, which will be much faster than restore. As I build the accounts I will create a file of smbclient commands to run to set the DOS hidden bits. The file will look like this: setmode a/ab/abc9d/.forward +h setmode a/ab/abc9d/.pinerc +h setmode d/de/def8g/.forward +h ... etc. Then I can run smbclient like this: smbclient //filer/home -U root < command-file I get prompted for the password once and then smbclient sets all the DOS hidden bits. For the curious, we are authenticating CIFS users with a unix NIS database, so all of our volumes have unix permissions. You must authenticate with a domain controller if you want NT or mixed style permissions. Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

1 0

RE: restore is very expensive
by Traitel, Eyal 08 Aug '01

08 Aug '01

In this case an rsh to a PC that can go to the same places on filer thru cifs shares, that runs "attrib" command might help... ----------------------------------------------------------------- eTraitel - I'm the new eBuzzword around !!! Filer Escalation Engineer CNA, MCSE, CSA, LCA, NetApp CA Network Appliance BV Hoofddorp, The Netherlands Office: +31 23 567 9685 Cellular: +31 6 5497 2568 Get answers NOW! - NetApp On the Web - http://now.netapp.com ----------------------------------------------------------------- -----Original Message----- From: Stephen Manley [mailto:stephen@netapp.com] Sent: Wednesday, August 08, 2001 10:42 To: eyal(a)netapp.com Cc: stephen(a)netapp.com; scl(a)sasha.acc.virginia.edu; toasters(a)mathworks.com Subject: Re: restore is very expensive > Steve (not NetApp one :-), > > What do u mean by CIFS hidden attributes - is it ACL with some > permissions ? I think what you're looking for is maybe rsh to NT > server and running CACLS or something... I think Steve is referring to what we have historically called a DOS bit -- the "hidden bit". If you right click a file via Windows and check out the "General" tab, you will see at the bottom Attributes: Read-only Hidden with the Standard Msft checkbox next to them. Dump/restore preserves these attributes, as well as the ACLs, NT streams, 8.3 names, etc. Stephen Manley DAM and NDMP Supreme Court Justice > -----Original Message----- > From: Stephen Manley [mailto:stephen@netapp.com] > Sent: Wednesday, August 08, 2001 09:19 > To: scl(a)sasha.acc.virginia.edu > Cc: toasters(a)mathworks.com > Subject: re: restore is very expensive > > > Hey Steve -- > > The extra dump space and restore temp file space is consumed because > of the number of inodes on the dumped volume. > > Restore creates (and zeroes) a couple of files that map between each > source inode and destination inode. > > To minimize time/space, you want to make your dump from a volume with > a tiny "maxfiles" setting. > > One way to do this would be to: > 1) create a 2 disk volume (don't touch the default maxfiles) > 2) restore newuser.dump into that volume > 3) dump the resulting new directory to a newuser.dump.small > 4) Use newuser.dump.small for your student population scripts. > > > There will still be zeroed temp files, etc. But the size of the files > will be significantly smaller, since the 2 disk volume will have fewer > inodes. (remember it is available inodes, not used inodes) > > > Anyway, just one thought, > Stephen Manley > DAM and NDMP D*mned Dirty Human > > > > > > We are in the midst of our annual bulk account creation for incoming > > students. We use a perl script running on a NFS client. > > > > We store home directories on our filers and these directories are > > accessible from both NFS and CIFS. > > > > We have a template directory for new accounts that contains the > > following. You will notice that there is only one file with any data > > and it is only 711 bytes. > > > > newuser: > > drwx--s--x 4 root usr 4096 Aug 13 1999 . > > drwx------ 15 accounts staff 4096 Jul 25 15:15 .. > > -rw-r--r-- 1 root usr 0 Aug 5 1998 .forward > > -rw-r--r-- 1 root usr 0 Aug 13 1999 .pinerc > > drwx--S--- 2 root usr 4096 Aug 5 1998 private > > drwxr-sr-x 2 root usr 4096 Aug 9 2000 public_html > > > > newuser/private: > > total 16 > > drwx--S--- 2 root usr 4096 Aug 5 1998 . > > drwx--s--x 4 root usr 4096 Aug 13 1999 .. > > > > newuser/public_html: > > total 24 > > drwxr-sr-x 2 root usr 4096 Aug 9 2000 . > > drwx--s--x 4 root usr 4096 Aug 13 1999 .. > > -rw-r--r-- 1 root usr 711 Aug 9 2000 home.html > > > > We want the CIFS hidden attribute set on the .forward and .pinerc > > files so that CIFS users are less likely to see them and remove them. > > > > We have a method that works, but it is *extremely* expensive. > > > > >From CIFS we set the hidden attributes in our template directory. > > We used the netapp dump command to dump the template directory and > > we > > saved the output in a file: > > > > rsh filer dump 0Af - /vol/vol0/template-dir > newuser.dump > > > > Whenever we create a new account, we run the netapp restore: > > > > rsh filer restore xfD - /vol/vol0/new-user-dir < newuser.dump > > > > This nicely preserves the hidden attributes and works fine, but it > > takes somewhere between 20 and 30 seconds to run the restore on a > > F630. Furthermore, the CPU on the filer is pegged at near 100% for > > many seconds, and disk reads and writes go through the roof. > > > > We are adding over 5,000 new accounts, so this is taking a good long > > while. > > > > First of all, the dump file that we created from this nearly empty > > template is a whopping 1.6M. I have since determined that most of > > this is a bit map of the inodes in the filesystem. But even still, > > 1.6M doesn't take 30 seconds to transfer across the net to restore, so > > what else is slowing us down? I also noticed that on the filer in > > /etc/tmp that restore creates several temp files and two of them are > > rather large. One is 26M and the other is 53M. I suppose that these > > are some sort of representation of the inode table in the netapp > > filesystem that we are restoring into. This filesystem is 243G with > > 172G used, 3657389 inodes used, 5776187 free. > > > > Obviously, if we bundled up the template directory into a tar file > > and > > restored it with tar, it would happen in a flash, but we would lose > > the hidden attribute. > > > > We are running DOT 6.0.1R3. Can anyone think of a better way to do > > this? Perhaps there is some option to dump to create a smaller dump > > file or perhaps an option to restore that just does a simple restore > > without all the other jazz it seems to be doing. > > > > I suppose we could use tar and then write some sort of NT script (I > > only know unix) that would run through and set the hidden attributes > > after we add all the accounts. > > > > Are there any magic DOT commands that might help us get the hidden > > attribute set? > > > > > > Steve Losen scl(a)virginia.edu phone: 434-924-0640 > > > > University of Virginia ITC Unix Support > > > >

1 0

RE: restore is very expensive
by Mike Sphar 08 Aug '01

08 Aug '01

Maybe I'm confusing some netapp settings with samba settings, but isn't it possible to configure the netapp to automatically hide files that begin with "." from CIFS clients? I don't have my docs handy at the moment, so I can't double-check that. If not, that would be a good enhancement request, perhaps even to have the netapp automatically translate a file beginning with a dot to have the DOS hidden attribute set. (In which case, the client could have the option of displaying hidden files to see them.) This would mimic the UNIX behavior in the CIFS environment. -----Original Message----- From: Stephen Manley [mailto:stephen@netapp.com] Sent: Wednesday, August 08, 2001 10:42 AM To: eyal(a)netapp.com Cc: stephen(a)netapp.com; scl(a)sasha.acc.virginia.edu; toasters(a)mathworks.com Subject: Re: restore is very expensive > Steve (not NetApp one :-), > > What do u mean by CIFS hidden attributes - is it ACL with some permissions ? > I think what you're looking for is maybe rsh to NT server and running CACLS or something... I think Steve is referring to what we have historically called a DOS bit -- the "hidden bit". If you right click a file via Windows and check out the "General" tab, you will see at the bottom Attributes: Read-only Hidden with the Standard Msft checkbox next to them. Dump/restore preserves these attributes, as well as the ACLs, NT streams, 8.3 names, etc. Stephen Manley DAM and NDMP Supreme Court Justice > -----Original Message----- > From: Stephen Manley [mailto:stephen@netapp.com] > Sent: Wednesday, August 08, 2001 09:19 > To: scl(a)sasha.acc.virginia.edu > Cc: toasters(a)mathworks.com > Subject: re: restore is very expensive > > > Hey Steve -- > > The extra dump space and restore temp file space is consumed because of the number of inodes on the dumped volume. > > Restore creates (and zeroes) a couple of files that map between each source inode and destination inode. > > To minimize time/space, you want to make your dump from a volume with a tiny "maxfiles" setting. > > One way to do this would be to: > 1) create a 2 disk volume (don't touch the default maxfiles) > 2) restore newuser.dump into that volume > 3) dump the resulting new directory to a newuser.dump.small > 4) Use newuser.dump.small for your student population scripts. > > > There will still be zeroed temp files, etc. But the size of the files will be significantly smaller, since the 2 disk volume will have fewer inodes. (remember it is available inodes, not used inodes) > > > Anyway, just one thought, > Stephen Manley > DAM and NDMP D*mned Dirty Human > > > > > > We are in the midst of our annual bulk account creation for incoming > > students. We use a perl script running on a NFS client. > > > > We store home directories on our filers and these directories are > > accessible from both NFS and CIFS. > > > > We have a template directory for new accounts that contains the > > following. You will notice that there is only one file with any data > > and it is only 711 bytes. > > > > newuser: > > drwx--s--x 4 root usr 4096 Aug 13 1999 . > > drwx------ 15 accounts staff 4096 Jul 25 15:15 .. > > -rw-r--r-- 1 root usr 0 Aug 5 1998 .forward > > -rw-r--r-- 1 root usr 0 Aug 13 1999 .pinerc > > drwx--S--- 2 root usr 4096 Aug 5 1998 private > > drwxr-sr-x 2 root usr 4096 Aug 9 2000 public_html > > > > newuser/private: > > total 16 > > drwx--S--- 2 root usr 4096 Aug 5 1998 . > > drwx--s--x 4 root usr 4096 Aug 13 1999 .. > > > > newuser/public_html: > > total 24 > > drwxr-sr-x 2 root usr 4096 Aug 9 2000 . > > drwx--s--x 4 root usr 4096 Aug 13 1999 .. > > -rw-r--r-- 1 root usr 711 Aug 9 2000 home.html > > > > We want the CIFS hidden attribute set on the .forward and .pinerc > > files so that CIFS users are less likely to see them and remove them. > > > > We have a method that works, but it is *extremely* expensive. > > > > >From CIFS we set the hidden attributes in our template directory. > > We used the netapp dump command to dump the template directory and we > > saved the output in a file: > > > > rsh filer dump 0Af - /vol/vol0/template-dir > newuser.dump > > > > Whenever we create a new account, we run the netapp restore: > > > > rsh filer restore xfD - /vol/vol0/new-user-dir < newuser.dump > > > > This nicely preserves the hidden attributes and works fine, but it > > takes somewhere between 20 and 30 seconds to run the restore on a > > F630. Furthermore, the CPU on the filer is pegged at near 100% for > > many seconds, and disk reads and writes go through the roof. > > > > We are adding over 5,000 new accounts, so this is taking a good long > > while. > > > > First of all, the dump file that we created from this nearly empty > > template is a whopping 1.6M. I have since determined that most of > > this is a bit map of the inodes in the filesystem. But even still, > > 1.6M doesn't take 30 seconds to transfer across the net to restore, so > > what else is slowing us down? I also noticed that on the filer in > > /etc/tmp that restore creates several temp files and two of them are > > rather large. One is 26M and the other is 53M. I suppose that these > > are some sort of representation of the inode table in the netapp > > filesystem that we are restoring into. This filesystem is 243G with > > 172G used, 3657389 inodes used, 5776187 free. > > > > Obviously, if we bundled up the template directory into a tar file and > > restored it with tar, it would happen in a flash, but we would lose > > the hidden attribute. > > > > We are running DOT 6.0.1R3. Can anyone think of a better way to do > > this? Perhaps there is some option to dump to create a smaller dump > > file or perhaps an option to restore that just does a simple restore > > without all the other jazz it seems to be doing. > > > > I suppose we could use tar and then write some sort of NT script (I > > only know unix) that would run through and set the hidden attributes > > after we add all the accounts. > > > > Are there any magic DOT commands that might help us get the hidden > > attribute set? > > > > > > Steve Losen scl(a)virginia.edu phone: 434-924-0640 > > > > University of Virginia ITC Unix Support > > > >

1 0

restore is very expensive
by Steve Losen 08 Aug '01

08 Aug '01

We are in the midst of our annual bulk account creation for incoming students. We use a perl script running on a NFS client. We store home directories on our filers and these directories are accessible from both NFS and CIFS. We have a template directory for new accounts that contains the following. You will notice that there is only one file with any data and it is only 711 bytes. newuser: drwx--s--x 4 root usr 4096 Aug 13 1999 . drwx------ 15 accounts staff 4096 Jul 25 15:15 .. -rw-r--r-- 1 root usr 0 Aug 5 1998 .forward -rw-r--r-- 1 root usr 0 Aug 13 1999 .pinerc drwx--S--- 2 root usr 4096 Aug 5 1998 private drwxr-sr-x 2 root usr 4096 Aug 9 2000 public_html newuser/private: total 16 drwx--S--- 2 root usr 4096 Aug 5 1998 . drwx--s--x 4 root usr 4096 Aug 13 1999 .. newuser/public_html: total 24 drwxr-sr-x 2 root usr 4096 Aug 9 2000 . drwx--s--x 4 root usr 4096 Aug 13 1999 .. -rw-r--r-- 1 root usr 711 Aug 9 2000 home.html We want the CIFS hidden attribute set on the .forward and .pinerc files so that CIFS users are less likely to see them and remove them. We have a method that works, but it is *extremely* expensive. From CIFS we set the hidden attributes in our template directory. We used the netapp dump command to dump the template directory and we saved the output in a file: rsh filer dump 0Af - /vol/vol0/template-dir > newuser.dump Whenever we create a new account, we run the netapp restore: rsh filer restore xfD - /vol/vol0/new-user-dir < newuser.dump This nicely preserves the hidden attributes and works fine, but it takes somewhere between 20 and 30 seconds to run the restore on a F630. Furthermore, the CPU on the filer is pegged at near 100% for many seconds, and disk reads and writes go through the roof. We are adding over 5,000 new accounts, so this is taking a good long while. First of all, the dump file that we created from this nearly empty template is a whopping 1.6M. I have since determined that most of this is a bit map of the inodes in the filesystem. But even still, 1.6M doesn't take 30 seconds to transfer across the net to restore, so what else is slowing us down? I also noticed that on the filer in /etc/tmp that restore creates several temp files and two of them are rather large. One is 26M and the other is 53M. I suppose that these are some sort of representation of the inode table in the netapp filesystem that we are restoring into. This filesystem is 243G with 172G used, 3657389 inodes used, 5776187 free. Obviously, if we bundled up the template directory into a tar file and restored it with tar, it would happen in a flash, but we would lose the hidden attribute. We are running DOT 6.0.1R3. Can anyone think of a better way to do this? Perhaps there is some option to dump to create a smaller dump file or perhaps an option to restore that just does a simple restore without all the other jazz it seems to be doing. I suppose we could use tar and then write some sort of NT script (I only know unix) that would run through and set the hidden attributes after we add all the accounts. Are there any magic DOT commands that might help us get the hidden attribute set? Steve Losen scl(a)virginia.edu phone: 434-924-0640 University of Virginia ITC Unix Support

3 2

RE: restore is very expensive
by Traitel, Eyal 08 Aug '01

08 Aug '01

Steve (not NetApp one :-), What do u mean by CIFS hidden attributes - is it ACL with some permissions ? I think what you're looking for is maybe rsh to NT server and running CACLS or something... ----------------------------------------------------------------- eTraitel - I'm the new eBuzzword around !!! Filer Escalation Engineer CNA, MCSE, CSA, LCA, NetApp CA Network Appliance BV Hoofddorp, The Netherlands Office: +31 23 567 9685 Cellular: +31 6 5497 2568 Get answers NOW! - NetApp On the Web - http://now.netapp.com ----------------------------------------------------------------- -----Original Message----- From: Stephen Manley [mailto:stephen@netapp.com] Sent: Wednesday, August 08, 2001 09:19 To: scl(a)sasha.acc.virginia.edu Cc: toasters(a)mathworks.com Subject: re: restore is very expensive Hey Steve -- The extra dump space and restore temp file space is consumed because of the number of inodes on the dumped volume. Restore creates (and zeroes) a couple of files that map between each source inode and destination inode. To minimize time/space, you want to make your dump from a volume with a tiny "maxfiles" setting. One way to do this would be to: 1) create a 2 disk volume (don't touch the default maxfiles) 2) restore newuser.dump into that volume 3) dump the resulting new directory to a newuser.dump.small 4) Use newuser.dump.small for your student population scripts. There will still be zeroed temp files, etc. But the size of the files will be significantly smaller, since the 2 disk volume will have fewer inodes. (remember it is available inodes, not used inodes) Anyway, just one thought, Stephen Manley DAM and NDMP D*mned Dirty Human > > We are in the midst of our annual bulk account creation for incoming > students. We use a perl script running on a NFS client. > > We store home directories on our filers and these directories are > accessible from both NFS and CIFS. > > We have a template directory for new accounts that contains the > following. You will notice that there is only one file with any data > and it is only 711 bytes. > > newuser: > drwx--s--x 4 root usr 4096 Aug 13 1999 . > drwx------ 15 accounts staff 4096 Jul 25 15:15 .. > -rw-r--r-- 1 root usr 0 Aug 5 1998 .forward > -rw-r--r-- 1 root usr 0 Aug 13 1999 .pinerc > drwx--S--- 2 root usr 4096 Aug 5 1998 private > drwxr-sr-x 2 root usr 4096 Aug 9 2000 public_html > > newuser/private: > total 16 > drwx--S--- 2 root usr 4096 Aug 5 1998 . > drwx--s--x 4 root usr 4096 Aug 13 1999 .. > > newuser/public_html: > total 24 > drwxr-sr-x 2 root usr 4096 Aug 9 2000 . > drwx--s--x 4 root usr 4096 Aug 13 1999 .. > -rw-r--r-- 1 root usr 711 Aug 9 2000 home.html > > We want the CIFS hidden attribute set on the .forward and .pinerc > files so that CIFS users are less likely to see them and remove them. > > We have a method that works, but it is *extremely* expensive. > > >From CIFS we set the hidden attributes in our template directory. > We used the netapp dump command to dump the template directory and we > saved the output in a file: > > rsh filer dump 0Af - /vol/vol0/template-dir > newuser.dump > > Whenever we create a new account, we run the netapp restore: > > rsh filer restore xfD - /vol/vol0/new-user-dir < newuser.dump > > This nicely preserves the hidden attributes and works fine, but it > takes somewhere between 20 and 30 seconds to run the restore on a > F630. Furthermore, the CPU on the filer is pegged at near 100% for > many seconds, and disk reads and writes go through the roof. > > We are adding over 5,000 new accounts, so this is taking a good long > while. > > First of all, the dump file that we created from this nearly empty > template is a whopping 1.6M. I have since determined that most of > this is a bit map of the inodes in the filesystem. But even still, > 1.6M doesn't take 30 seconds to transfer across the net to restore, so > what else is slowing us down? I also noticed that on the filer in > /etc/tmp that restore creates several temp files and two of them are > rather large. One is 26M and the other is 53M. I suppose that these > are some sort of representation of the inode table in the netapp > filesystem that we are restoring into. This filesystem is 243G with > 172G used, 3657389 inodes used, 5776187 free. > > Obviously, if we bundled up the template directory into a tar file and > restored it with tar, it would happen in a flash, but we would lose > the hidden attribute. > > We are running DOT 6.0.1R3. Can anyone think of a better way to do > this? Perhaps there is some option to dump to create a smaller dump > file or perhaps an option to restore that just does a simple restore > without all the other jazz it seems to be doing. > > I suppose we could use tar and then write some sort of NT script (I > only know unix) that would run through and set the hidden attributes > after we add all the accounts. > > Are there any magic DOT commands that might help us get the hidden > attribute set? > > > Steve Losen scl(a)virginia.edu phone: 434-924-0640 > > University of Virginia ITC Unix Support > >

2 1

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