toasters

toasters@lists.teaparty.net

13515 discussions

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

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

08 Aug '01

Hello all, 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

1 0

Re: 3rd party drives for Netapp F820 (fwd)
by don_maloy＠closures.intier.com 08 Aug '01

08 Aug '01

To the best of my knowledge, it is a drive firmware issue. I had taken several Seagate drives (ST39103FC) from various Sun machines and put them into our FC9 shelf attached to a 740. The drives work, but it does complain about them. I tried modifying the etc/qual_devices file which contained what firmware level was expected by the filer, but that didn't work either. I tried the disk_fw_update on the disks hoping that it would just put the Netapp firmware that I downloaded from the NOW site on top of the Sun firmware, but it would not perform the operation. If you figure out a way to perform this, please post it to the list. Donald J. Maloy Sr. CAD Administrator Intier Automotive - Latching Systems 19888 Haggerty Road Livonia, MI 48152 734.432.4418 734.591.6463 (Fax) Daniel Feenberg To: toasters(a)mathworks.com <feenberg@nber cc: (bcc: Don Maloy/PDD/DORTEC) .org> Subject: 3rd party drives for Netapp F820 (fwd) 08/08/01 07:34 AM Sorry if this is a FAQ, but I am new to the list and can't seem to browse http://teaparty.mathworks.com:1999/toasters. We have an F820 filer from Network Appliance with a single DS14 drive shelf. The shelf came with 14 cartriges, of which 7 had 36 gigabyte ST336704FC drives, and 7 were empty. We would like to fill the empty drive cartridges with Seagate ST373405FC (72 gigabyte) drives, but the F820 complains "Drive not supported" when we insert the drives in the slots. Is the error message because we didn't buy the drive from Netapp, didn't buy the right drives, or some firmware issue, or do we just need to update the F820 OS software? Does anyone have experience with using non-Netapp drives in an F820? We have heard that it works, but this is our first attempt. Daniel Feenberg feenberg(a)nber.org

1 0

3rd party drives for Netapp F820 (fwd)
by Daniel Feenberg 08 Aug '01

08 Aug '01

Sorry if this is a FAQ, but I am new to the list and can't seem to browse http://teaparty.mathworks.com:1999/toasters. We have an F820 filer from Network Appliance with a single DS14 drive shelf. The shelf came with 14 cartriges, of which 7 had 36 gigabyte ST336704FC drives, and 7 were empty. We would like to fill the empty drive cartridges with Seagate ST373405FC (72 gigabyte) drives, but the F820 complains "Drive not supported" when we insert the drives in the slots. Is the error message because we didn't buy the drive from Netapp, didn't buy the right drives, or some firmware issue, or do we just need to update the F820 OS software? Does anyone have experience with using non-Netapp drives in an F820? We have heard that it works, but this is our first attempt. Daniel Feenberg feenberg(a)nber.org

1 0

SSAM Hangs
by NicholosC 08 Aug '01

08 Aug '01

Hi, Has anyone experienced a hung session of the SSAM while converting a domain of 10,000 records? Any experience to share would be greatly appreciated. Regards, Nic

1 0

RE: qpopper file locks
by Sims, Aaron 07 Aug '01

07 Aug '01

You don't mention whether or not you'll have more than one HP-UX system accessing the mail spool. If it's just one, then no problem, stop reading here. If more than one system can access the same mailbox (i.e. load balancing), read on. There are two mailbox formats commonly used. One is 'mbox' the other is 'maildir'. 'mbox' format mailboxes are the most common. They use one file for multiple messages. File locking is always an issue with this format. 'maildir' format is one file per message. This format is generally headache-free in terms of file locking. My experience is that relying on lockd for file locking works 99.9...% of the time. Your milage can and will vary here. Not all NFS clients are made the same. Some UNIX vendors have better NFS and NLM (Network Lock Manager) clients than others. While I don't have direct experience with HP-UX, in small environments, lockd should work fine. (Although in a past life, I've run a F630 cluster with at least 8 Solaris based clients and 250,000 mailboxes relying on lockd with no problems.) If you run into problems, then you should convert to the maildir format. This will require that you patch or change your local delivery agent (the program that sendmail calls to actually write the email to a file, probably mail.local) and your qpopper. Aaron > -----Original Message----- > From: Todd Watson [mailto:tkw@southwestern.edu] > Sent: Tuesday, August 07, 2001 3:34 PM > To: toasters(a)mathworks.com > Subject: qpopper file locks > > > > My apologies if this question has been hashed over before on the list, > but the archives seem inaccessible at the moment. > > We are planning on migrating our mail spool files from an HP-UX server > to our 740 filer and then mounting them back via NFS. This HP system > runs sendmail and pop (qpopper specifically). We are concerned about > file-locking issues which may arise or any other "gotchas" that we > should be aware of. > > Thanks! > > Todd > -- > Todd K. Watson > Senior System & Network Administrator > Southwestern University, Georgetown, TX > tkw(a)southwestern.edu || TEL:512.863.1508 || FAX:512.863.1605 >

1 0

qpopper file locks
by Todd Watson 07 Aug '01

07 Aug '01

My apologies if this question has been hashed over before on the list, but the archives seem inaccessible at the moment. We are planning on migrating our mail spool files from an HP-UX server to our 740 filer and then mounting them back via NFS. This HP system runs sendmail and pop (qpopper specifically). We are concerned about file-locking issues which may arise or any other "gotchas" that we should be aware of. Thanks! Todd -- Todd K. Watson Senior System & Network Administrator Southwestern University, Georgetown, TX tkw(a)southwestern.edu || TEL:512.863.1508 || FAX:512.863.1605

1 0

RE: HP surestore dlt1
by Joe Luchtenberg 07 Aug '01

07 Aug '01

If you need support for LVD devices, P/N X2023B-C is an LVD SCSI backup adapter for tape. Check the Sysconfig guide for slots and supported tape drives: http://now.netapp.com/NOW/knowledge/docs/hardware/syscfg/scdot611/index.htm Joe Luchtenberg Dataline, Inc. 757-858-0600 757-285-1223 (mobile) 757-858-0606 (fax) joe.luchtenberg(a)data-line.com www.data-line.com > -----Original Message----- > From: Jim Davis [mailto:jdavis@cs.arizona.edu] > Sent: Tuesday, August 07, 2001 12:31 PM > To: > Subject: Re: HP surestore dlt1 > > > Thanks to the people who reminded me the onboard adapter > really is for HVD > devices, not LVD devices. Of course the drive I was trying was an LVD > device... >

1 0

is symbol link can be used on filer?
by Zhonghua-Dennis.Huang＠nokia.com 07 Aug '01

07 Aug '01

Hi toasters, An urgent question. There are soft links on my exported q-trees. the link is directed to files on another machine. When windows users want to acces the files, it always says pemission denied. How to do with it?

2 2

Direct attaching SCSI tape drives to 760's
by Paul Letta 07 Aug '01

07 Aug '01

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

1 0

Looking to purchase older Filer SCSI tape, disk drives, shelf
by Scott Chellis 04 Aug '01

04 Aug '01

Hi, I am looking to purchase our would appreciate source information for purchase of: qty(3) (or more) 4GB ST15230N disk drives with/in canisters. qty(1) StorageShelf1 with or without drives Exabyte 8505 tape drive with proper mounting bracket, cable, etc for internal F520 install. Any information on any part of the above would be greatly appreciated -- replies to me directly. Thanks Scott B. Chellis Consulting I/T Architect - Network Integration - MCNE, CCNA, CCNP, CIFI South Outsourcing Network Design Office : 919.852.4080 Tieline: 223.9629 Fax : 919.852.4020 Cellular: 919.244.7050 Pager: 800.252.5972 Email: schellis(a)us.ibm.com Notes: Scott Chellis/Raleigh/IBM@IBMUS

1 0

RE: Veritas b/u not clearing archive bit on NetApp volume
by Adrian Phillips 03 Aug '01

03 Aug '01

Hello again all; Just an update to this issue, that I've recently discovered. I've found that the archive bit does not get cleared if the account used for backup does not have access (NTFS permissions) to the file. It will back it up, but not clear the archive bit. Our user's home folders are all on C:, so that is why I thought it was drive specific. The backup account is in the local Backup Operators group, and is also a member of the Domain Admins group. If anyone has seen this behavior before and has any thoughts, please let me know. Thanks again for your time and help. Regards, -Adrian -----Original Message----- From: Adrian Phillips Sent: Tuesday, July 31, 2001 4:30 PM To: 'toasters(a)mathworks.com' Subject: Veritas b/u not clearing archive bit on NetApp volume Hello List; We have an F760 running CIFS, with ONTAP 6.0.1R3. "C:" is mapped to vol0, and "D:" to vol1. We use Veritas BackupExec 8.5 over the network to connect to and back up the data/shares on these NTFS volumes. What is very odd (and I nor Netapp can seem to figure out thus far) is that the archive bit for files on C: do not get reset after full or incremental backups. Meanwhile, through the same backup jobs, the archive bit on files on drive D: DOES get properly cleared after being backed up. Because the archive bit is not being cleared on C:, our incremental backups are very large, and running well into the work day. I can't seem to find any differences in the volumes, other than vol0/C: is the root volume and uses 9GB drives, compared to vol1/D:'s 36GB drives. Regards, -Adrian

1 0

symbolic link
by Maximus Moua 03 Aug '01

03 Aug '01

hi list: Does anyone in here know if one can create a symbolic link from a NAS share to a Quantum snap box on the network in a cifs environment? Thanks. max

1 0

RE: NetApp telnetd safe?
by Fox, Adam 03 Aug '01

03 Aug '01

> > Can anyone say whether the NetApp filer telnetd implementation > is free from the buffer overflow bugs described in > <http://www.cert.org/advisories/CA-2001-21.html> (24 July 2001)? We've had quite a few calls on this and the word from the engineers involved in that code assure us ONTAP is *not* vulnerable to this so no patches are needed. Hope this helps. -- Adam Fox NetApp Professional Services, NC adamfox(a)netapp.com

1 0

5.7 Legato client no longer backs up NT Registry
by E.J. Jantz 03 Aug '01

03 Aug '01

Before having to Hold for tech support for however long.. Does anyone know why the NT 4 Registry is no longer being backed up by my Legato server? The server is HPUX rel 11+ and the NT clients are running service pak6 and clientpak is Networker 5.7 Server is Networker 5.5.2. no patches applied to the Legato app. Thanks in advance. EJ Jantz, IST Dept. BSW International One West Third, Ste 100 Tulsa, OK 74103-3505 918 582-8771 ej_jantz(a)bswintl.com 918 295-4166 918 587-3594 fax

1 0

NetApp telnetd safe?
by Chris Thompson 03 Aug '01

03 Aug '01

Can anyone say whether the NetApp filer telnetd implementation is free from the buffer overflow bugs described in <http://www.cert.org/advisories/CA-2001-21.html> (24 July 2001)? 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

Quota Question?
by NicholosC 02 Aug '01

02 Aug '01

This is what I'm trying to achieve: Z:\world\asia Z:\world\america Z:\world\europe I'm trying to set quota of 1G for asia, america, europe which can not be done on directory level. Then I created qtree asia, america & europe so that I can set tree quota on them. By creating individual shares have the qtree, I have to map them into three separate drive letter asia on 'netapp1' (X:) america on 'netapp1' (Y:) europe on 'netapp1' (Z:) I would still like to have the above first illustrated structure but with quota control. Is there any work around to achieve this, or at least fix my second method to better organize it under one top level directory structure? Regards, Nic

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