toasters

toasters@lists.teaparty.net

13520 discussions

RE: Backups of NT partitions to Unix
by Benn, Paul 10 Oct '00

10 Oct '00

One more thing (thanks to my buddy Ernst Bokkelkamp for reminding me privately).... Check to make sure that the NetWorker service accounts have permission to access the filer. By default, the local system account is used, which won't work. Setup a special domain account for your NetWorker user and pop it into the domain's backup administrators group. Put that global group into the filer's local Backup administrator group. Now configure the NetWorker services to use this account. This is the most common NT backup issue, by the way. Regards, Paul Benn Network Appliance -----Original Message----- From: Benn, Paul Sent: Tuesday, October 10, 2000 8:43 AM To: 'Watts, James A.'; Toasters Mailing list Subject: RE: Backups of NT partitions to Unix Hello Jim, Yes, the paper is a little long in the tooth with respect to product versions and performance numbers. The basic information should still be relevant, though. Here's a link to the paper: http://www.netapp.com/tech_library/3052.html Anyway, you'll need to "front end" the filer with another NT server loaded with the NetWorker client. When I wrote the paper, UNC paths weren't supported but now they are. You can enter the UNC path directly rather than map a drive letter using the AutoExecNT service from the resource kit. The platform (UNIX or NT) of the NetWorker server doesn't matter. What matters is the platform of the server running the NetWorker client on the machine configured to "front end" the filer. Did you use a UNC path or a mapped drive letter in your test? I don't know if it's the same problem but when I was testing NetWorker to write the paper, I found that the drive letter mapping was lost for unknown reasons as soon as the backup started. The result was "0 files backed up." The reason we use AutoExNT is twofold. First of all, it eliminated this problem and secondly. Secondly, it allows one to map a drive letter as a service rather than having to leave a user logged in at the NT machine (drive letters are mapped at login). It sounds like you may already know but I'll restate it anyway. If you backup a qtree with NTFS style permissions via NFS, you will loose the file permissions and file attributes (it would be like backing up a FAT partition less the DOS file attributes). Backing up a qtree with UNIX style permissions over CIFS will, however, retain the UNIX permissions. The filer also tracks an archive bit for UNIX data so NT backup apps (NetWorker isn't one of them) relying on the archive bit can run an incremental backup of UNIX data. The bottom line.... if you already have an NT based NetWorker client you should be able to back up your filer without having to buy more software. Regards, Paul Benn Technical Marketing Network Appliance -----Original Message----- From: Watts, James A. [mailto:james.a.watts@gbr.conoco.com] Sent: Tuesday, October 10, 2000 7:38 AM To: Toasters Mailing list Subject: Backups of NT partitions to Unix I've looked through the archive, and also across, but have had problems getting a definitive answer on the following : We have a filer supplying an CIFS partition to an NT4 server. Our Legato ( v5.5.1 ) server is a Sun Solaris 2.6 box. Can we back up the filer to Legato without having to buy additional software ? We have tried so far, but while Legato seems to see the partition it backs up 0 files. I have seen posts about the NetApp white paper describing how to do this, but our Legato support company says this was on an older version of Legato ( I've asked for clarification on whether they mean the functionality has been removed ). The other option is to make the partition both NFS and CIFS, but I'm trying to avoid the pain if possible. Thanks in advance, Jim Watts, Conoco (UK) Ltd.

1 0

RE: Mac G4 with NetApp
by Mike Sphar 10 Oct '00

10 Oct '00

Ah, my mistake. Thanks for the correction. I only played with the Services for Macintosh a little bit, and I foolishly assumed you could re-share a mounted network share. Also, now that I think about it, we used to use CAP a few years ago when we needed such things and I remember it being pretty reliable and easy to maintain. Netatalk is also supposed to be good, but I've never used it. Generally, my preference is to install new services on a server when I can rather than be forced to deploy and support new client software. Letting the client OS access data using its native capabilities usually results in less maintenance and support headaches. (Ugh, now I'm having flashbacks of supporting ChameleonNFS on hundreds of machines.) -- Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH, GWP, MCP, MCP+I, MCSE, BFD -----Original Message----- From: Benn, Paul [mailto:paul.benn@netapp.com] Sent: Tuesday, October 10, 2000 1:50 PM To: 'Mike Sphar'; toasters(a)mathworks.com Subject: RE: Mac G4 with NetApp Just to clarify.... Exporting a CIFS share (whether from a filer or another NT server) to AFP won't work with the Microsoft service for Macintosh (at least it didn't with NT4 and AutoExNT was no help either). I tried an early W2K beta but it was no help either. The Microsoft service only supports local disk. Sorry :( As for a gateway type product, I've only heard of NFS/AFP solutions. Paul Benn Network Appliance -----Original Message----- From: Mike Sphar [mailto:mikey@remedy.com] Sent: Monday, October 09, 2000 1:24 PM To: toasters(a)mathworks.com Subject: RE: Mac G4 with Netapp As others have mentions, you could either make sure you have a good NFS or CIFS client for the Mac installed. Or, depending on how much traffic you expect from the Mac and how many macs you have, it might be easier to re-share the Netapp through a Windows or UNIX box. Netatalk I believe is the name of a free appletalk file server for UNIX. And Windows NT/2000 Server also comes with a free Services for Macintosh package as well, I believe. -- Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH, GWP, MCP, MCP+I, MCSE, BFD -----Original Message----- From: Mathew Anderson [mailto:mathew@nm.net] Sent: Monday, October 09, 2000 9:59 AM To: toasters(a)mathworks.com Subject: Mac G4 with Netapp Has anyone tried to get a G4 to mount a netapp share? We have the netapp setup with both nfs and cifs, and we are using a PDC. Any pointers on where to start? (apples KB does not help at all).. Thanks -Mathew Mathew Anderson Systems Administration NM Technet Oso Grande Technologies, Inc. mathew(a)nm.net mathew(a)osogrande.net

1 0

RE: Mac G4 with NetApp
by Benn, Paul 10 Oct '00

10 Oct '00

Just to clarify.... Exporting a CIFS share (whether from a filer or another NT server) to AFP won't work with the Microsoft service for Macintosh (at least it didn't with NT4 and AutoExNT was no help either). I tried an early W2K beta but it was no help either. The Microsoft service only supports local disk. Sorry :( As for a gateway type product, I've only heard of NFS/AFP solutions. Paul Benn Network Appliance -----Original Message----- From: Mike Sphar [mailto:mikey@remedy.com] Sent: Monday, October 09, 2000 1:24 PM To: toasters(a)mathworks.com Subject: RE: Mac G4 with Netapp As others have mentions, you could either make sure you have a good NFS or CIFS client for the Mac installed. Or, depending on how much traffic you expect from the Mac and how many macs you have, it might be easier to re-share the Netapp through a Windows or UNIX box. Netatalk I believe is the name of a free appletalk file server for UNIX. And Windows NT/2000 Server also comes with a free Services for Macintosh package as well, I believe. -- Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH, GWP, MCP, MCP+I, MCSE, BFD -----Original Message----- From: Mathew Anderson [mailto:mathew@nm.net] Sent: Monday, October 09, 2000 9:59 AM To: toasters(a)mathworks.com Subject: Mac G4 with Netapp Has anyone tried to get a G4 to mount a netapp share? We have the netapp setup with both nfs and cifs, and we are using a PDC. Any pointers on where to start? (apples KB does not help at all).. Thanks -Mathew Mathew Anderson Systems Administration NM Technet Oso Grande Technologies, Inc. mathew(a)nm.net mathew(a)osogrande.net

1 0

mixing 18GB and 36GB drives
by jmiddlebrooks＠datalink.com 10 Oct '00

10 Oct '00

I was told by a Netapp rep that you can not mix 18Gb and 36Gb drives on a F720. This is not true is it as long as you use the correct disk shelves is it? Are there certain memory requirments for the 36Gb drives? Thanks Jason Middlebrooks Systems Engineer Datalink Corp. 888-933-9327 x2970

13 17

RE: Backups of NT partitions to Unix
by Benn, Paul 10 Oct '00

10 Oct '00

Hello Jim, Yes, the paper is a little long in the tooth with respect to product versions and performance numbers. The basic information should still be relevant, though. Here's a link to the paper: http://www.netapp.com/tech_library/3052.html Anyway, you'll need to "front end" the filer with another NT server loaded with the NetWorker client. When I wrote the paper, UNC paths weren't supported but now they are. You can enter the UNC path directly rather than map a drive letter using the AutoExecNT service from the resource kit. The platform (UNIX or NT) of the NetWorker server doesn't matter. What matters is the platform of the server running the NetWorker client on the machine configured to "front end" the filer. Did you use a UNC path or a mapped drive letter in your test? I don't know if it's the same problem but when I was testing NetWorker to write the paper, I found that the drive letter mapping was lost for unknown reasons as soon as the backup started. The result was "0 files backed up." The reason we use AutoExNT is twofold. First of all, it eliminated this problem and secondly. Secondly, it allows one to map a drive letter as a service rather than having to leave a user logged in at the NT machine (drive letters are mapped at login). It sounds like you may already know but I'll restate it anyway. If you backup a qtree with NTFS style permissions via NFS, you will loose the file permissions and file attributes (it would be like backing up a FAT partition less the DOS file attributes). Backing up a qtree with UNIX style permissions over CIFS will, however, retain the UNIX permissions. The filer also tracks an archive bit for UNIX data so NT backup apps (NetWorker isn't one of them) relying on the archive bit can run an incremental backup of UNIX data. The bottom line.... if you already have an NT based NetWorker client you should be able to back up your filer without having to buy more software. Regards, Paul Benn Technical Marketing Network Appliance -----Original Message----- From: Watts, James A. [mailto:james.a.watts@gbr.conoco.com] Sent: Tuesday, October 10, 2000 7:38 AM To: Toasters Mailing list Subject: Backups of NT partitions to Unix I've looked through the archive, and also across, but have had problems getting a definitive answer on the following : We have a filer supplying an CIFS partition to an NT4 server. Our Legato ( v5.5.1 ) server is a Sun Solaris 2.6 box. Can we back up the filer to Legato without having to buy additional software ? We have tried so far, but while Legato seems to see the partition it backs up 0 files. I have seen posts about the NetApp white paper describing how to do this, but our Legato support company says this was on an older version of Legato ( I've asked for clarification on whether they mean the functionality has been removed ). The other option is to make the partition both NFS and CIFS, but I'm trying to avoid the pain if possible. Thanks in advance, Jim Watts, Conoco (UK) Ltd.

1 0

RE: Backups of NT partitions to Unix
by Ljungberg, Anders 10 Oct '00

10 Oct '00

Hi James, This should not be a problem "whatever" version you are using. Specify the shares that you want to backup in the client definition in Legato. I.e. \\NTBOX\SHARE$\nightly.0 ( were SHARE$ points to the snapshot directory ). Please contact me if you need further assistance. Anders Ljungberg Professional Services Consultant Network Appliance UK Ltd. Tel: 0208 756 6785 -----Original Message----- From: Watts, James A. [mailto:james.a.watts@gbr.conoco.com] Sent: Tuesday, October 10, 2000 4:38 PM To: Toasters Mailing list Subject: Backups of NT partitions to Unix I've looked through the archive, and also across, but have had problems getting a definitive answer on the following : We have a filer supplying an CIFS partition to an NT4 server. Our Legato ( v5.5.1 ) server is a Sun Solaris 2.6 box. Can we back up the filer to Legato without having to buy additional software ? We have tried so far, but while Legato seems to see the partition it backs up 0 files. I have seen posts about the NetApp white paper describing how to do this, but our Legato support company says this was on an older version of Legato ( I've asked for clarification on whether they mean the functionality has been removed ). The other option is to make the partition both NFS and CIFS, but I'm trying to avoid the pain if possible. Thanks in advance, Jim Watts, Conoco (UK) Ltd.

1 0

Backups of NT partitions to Unix
by Watts, James A. 10 Oct '00

10 Oct '00

I've looked through the archive, and also across, but have had problems getting a definitive answer on the following : We have a filer supplying an CIFS partition to an NT4 server. Our Legato ( v5.5.1 ) server is a Sun Solaris 2.6 box. Can we back up the filer to Legato without having to buy additional software ? We have tried so far, but while Legato seems to see the partition it backs up 0 files. I have seen posts about the NetApp white paper describing how to do this, but our Legato support company says this was on an older version of Legato ( I've asked for clarification on whether they mean the functionality has been removed ). The other option is to make the partition both NFS and CIFS, but I'm trying to avoid the pain if possible. Thanks in advance, Jim Watts, Conoco (UK) Ltd.

1 0

High Performance volume configuration
by Graydon Dodson 10 Oct '00

10 Oct '00

> I also had a 760 survive doing 17,000 nfs ops/second once. ... When running compiles, it is not unusual for us to see numbers over 22,000 on the op-panel of our 760. Anyone know where the top end of an 840 is? Support has been unable to answer that one for us. So in our move to an 840 I want to configure it's volume for maximum performance. The ground rules are two FC-AL adapters, seven full trays of 18G drives. All one volume is very desirable. Now the SPECsfs97 benchmark on the 840 states: * The F1 filesystem was composed of two RAID groups, each containing 17 data disks and one parity disk. Two spare disks were present * The F1 filesystem was striped across both disk controllers Since I have to assume that NetApp would use a high performance architecture for the benchmark I am guessing that this is the way to go, but there is quite a bit of detail missing. Is it a good or bad idea to split a raid group over two FC-AL interfaces? What does "striped across both disk controllers" mean? If there are spare disks (same size) on both FC-AL interfaces and a disk fails Which one is used to rebuild? (Same FC-AL or random choice) Is it a good or bad idea to split a volume over multiple FC-AL interfaces? The need for speed Graydon Dodson (606) 232-6483 grdodson(a)lexmark.com Lexmark International Inc.

3 4

RE: 32-bit uptime counter?
by Strange, Steve 10 Oct '00

10 Oct '00

I think the fix first appears in 6.0 (I happened to be the one who fixed it). We now use a 64-bit millisecond counter. Not sure how many years that is offhand, but I think we're ok for a while. Brian -- your quoted mail msg below is the text of the bug report :-). Thanks!! Steve > -----Original Message----- > From: Brian Tao [mailto:taob@risc.org] > Sent: Monday, October 09, 2000 9:53 PM > To: toasters(a)mathworks.com > Cc: Yoder, Alan > Subject: RE: 32-bit uptime counter? > > > On Wed, 19 May 1999, Yoder, Alan wrote: > > [Guy Harris writes]... > > > [Brian Tao writes]... > > > > Still running good ol' 4.2a on an F230: > > > > > > > > Sun Apr 18 21:00:00 EDT [statd]: 9:00pm up 497 days, > 1:10 407777519 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > Sun Apr 18 22:00:00 EDT [statd]: 10:00pm up 497 days, > 2:10 408458997 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > Sun Apr 18 23:00:00 EDT [statd]: 11:00pm up 42 mins, > 409036765 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > Mon Apr 19 00:00:00 EDT [statd]: 12:00am up 1:42 > 409494263 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > > > > > This looks like 2^32 ticks elapsed (about 42949673 > seconds)... > > > > > > Yes, the tick counter is 32 bits in 4.2a: > > > > > > tooting$ egrep sk_tics ../sk/*.h > > > ../sk/sk.h:extern VOLATILE int4 sk_tics; /* > > > number of ticks since boot */ > > > > > > > is this one of the counters being increased to 64 bits? > > > > > > It's not been increased in size yet; I don't know if it's > one of the > > > ones we plan to boost in size. > > > > It is now. > > Say, which release was the change incorporated? I'm gettin' tired > of seeing my uptime counters roll. ;-) > > | Sun Oct 1 00:00:01 EDT [asup_main]: System Notification mail sent > | Sun Oct 1 01:00:00 EDT [statd]: 1:00am up 496 days, > 16:35 1845869853 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 01:00:00 EDT [raid_scrub_admin]: Beginning disk > scrubbing... > | Sun Oct 1 02:01:03 EDT [statd]: 2:01am up 496 days, > 17:35 1846202045 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 parity > inconsistencies > | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 media errors > | Sun Oct 1 03:00:32 EDT [consumer]: Disk scrubbing finished... > | Sun Oct 1 03:00:42 EDT [statd]: 3:00am up 496 days, > 18:34 1846455096 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 04:00:00 EDT [statd]: 4:00am up 496 days, > 19:33 1846520843 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 05:00:00 EDT [statd]: 5:00am up 496 days, > 20:34 1846581690 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 06:00:00 EDT [statd]: 6:00am up 496 days, > 21:34 1846983917 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 07:00:01 EDT [statd]: 7:00am up 496 days, > 22:34 1847368872 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 08:00:00 EDT [statd]: 8:00am up 496 days, > 23:33 1847430632 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 09:00:00 EDT [statd]: 9:00am up 497 days, 34 > mins, 1847493449 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 10:00:00 EDT [statd]: 10:00am up 497 days, > 1:34 1847553879 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 11:00:00 EDT [statd]: 11:00am up 6 mins, > 1847633991 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 12:00:00 EDT [statd]: 12:00pm up 1:06 > 1847697785 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 13:00:00 EDT [statd]: 1:00pm up 2:06 > 1847760829 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 14:00:00 EDT [statd]: 2:00pm up 3:06 > 1847824644 NFS ops, 0 CIFS ops, 0 HTTP ops > | Sun Oct 1 15:00:00 EDT [statd]: 3:00pm up 4:06 > 1847886612 NFS ops, 0 CIFS ops, 0 HTTP ops > > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" >

1 0

RE: 32-bit uptime counter?
by Brian Tao 10 Oct '00

10 Oct '00

On Wed, 19 May 1999, Yoder, Alan wrote: > [Guy Harris writes]... > > [Brian Tao writes]... > > > Still running good ol' 4.2a on an F230: > > > > > > Sun Apr 18 21:00:00 EDT [statd]: 9:00pm up 497 days, 1:10 407777519 NFS ops, 0 CIFS ops, 0 HTTP ops > > > Sun Apr 18 22:00:00 EDT [statd]: 10:00pm up 497 days, 2:10 408458997 NFS ops, 0 CIFS ops, 0 HTTP ops > > > Sun Apr 18 23:00:00 EDT [statd]: 11:00pm up 42 mins, 409036765 NFS ops, 0 CIFS ops, 0 HTTP ops > > > Mon Apr 19 00:00:00 EDT [statd]: 12:00am up 1:42 409494263 NFS ops, 0 CIFS ops, 0 HTTP ops > > > > > > This looks like 2^32 ticks elapsed (about 42949673 seconds)... > > > > Yes, the tick counter is 32 bits in 4.2a: > > > > tooting$ egrep sk_tics ../sk/*.h > > ../sk/sk.h:extern VOLATILE int4 sk_tics; /* > > number of ticks since boot */ > > > > > is this one of the counters being increased to 64 bits? > > > > It's not been increased in size yet; I don't know if it's one of the > > ones we plan to boost in size. > > It is now. Say, which release was the change incorporated? I'm gettin' tired of seeing my uptime counters roll. ;-) | Sun Oct 1 00:00:01 EDT [asup_main]: System Notification mail sent | Sun Oct 1 01:00:00 EDT [statd]: 1:00am up 496 days, 16:35 1845869853 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 01:00:00 EDT [raid_scrub_admin]: Beginning disk scrubbing... | Sun Oct 1 02:01:03 EDT [statd]: 2:01am up 496 days, 17:35 1846202045 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 parity inconsistencies | Sun Oct 1 03:00:32 EDT [consumer]: Scrub found 0 media errors | Sun Oct 1 03:00:32 EDT [consumer]: Disk scrubbing finished... | Sun Oct 1 03:00:42 EDT [statd]: 3:00am up 496 days, 18:34 1846455096 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 04:00:00 EDT [statd]: 4:00am up 496 days, 19:33 1846520843 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 05:00:00 EDT [statd]: 5:00am up 496 days, 20:34 1846581690 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 06:00:00 EDT [statd]: 6:00am up 496 days, 21:34 1846983917 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 07:00:01 EDT [statd]: 7:00am up 496 days, 22:34 1847368872 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 08:00:00 EDT [statd]: 8:00am up 496 days, 23:33 1847430632 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 09:00:00 EDT [statd]: 9:00am up 497 days, 34 mins, 1847493449 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 10:00:00 EDT [statd]: 10:00am up 497 days, 1:34 1847553879 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 11:00:00 EDT [statd]: 11:00am up 6 mins, 1847633991 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 12:00:00 EDT [statd]: 12:00pm up 1:06 1847697785 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 13:00:00 EDT [statd]: 1:00pm up 2:06 1847760829 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 14:00:00 EDT [statd]: 2:00pm up 3:06 1847824644 NFS ops, 0 CIFS ops, 0 HTTP ops | Sun Oct 1 15:00:00 EDT [statd]: 3:00pm up 4:06 1847886612 NFS ops, 0 CIFS ops, 0 HTTP ops -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

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