toasters

toasters@lists.teaparty.net

13515 discussions

RE: F760/F840, ONTAP 5.3.x/6.x gripes
by Reidenbach, Edward 13 Oct '00

13 Oct '00

Thanks for the feedback on the Data ONTAP release model. There were numerous factors we considered in the decision making process for both Data ONTAP 6.0 and 5.3.6H1. Factors including * time to market * time frame for separation of code lines * feature/function and regression/reliability testing scope * project schedule differences * and the risk profile of the various alternatives were critical in the decision making process. We believe the resulting release model decisions provided the highest quality solution for you in the most timely manner. Follow-on maintenance releases for both Data ONTAP 5.3.6H1 and 6.0 will address the platform specific issues associated with the above mentioned releases. Ed Reidenbach Marketing Manager, Data ONTAP, Multiprotocol and High Availability Network Appliance Phone: 408-822-6167 Email: edr(a)netapp.com -----Original Message----- From: Todd C. Merrill [mailto:tmerrill@mathworks.com] Sent: Thursday, October 12, 2000 7:11 AM To: toasters(a)mathworks.com Subject: F760/F840, ONTAP 5.3.x/6.x gripes Can someone from NetApp comment on these following concerns? It seems...inconvenient for those who upgraded to ONTAP 6 on F760s to have to revert back to 5.3.6.x in order to upgrade to the F840s. The release of ONTAP 6 couldn't wait until a port to the x86 code was ready for the F840s? And, also, why won't 5.3.6H1 run on an alpha-based filer? I couldn't test 5.3.6H1 *anywhere* in my environment, except on my new F840 which I needed immediately on a high-visibilty filer. I upgraded and went live with 5.3.6H1 and crossed my fingers that there would be no problems with this new release. Very unnerving. I'm now running with two different ONTAP versions on a group of filers, and hoping I don't run into any inconsistencies across my environment due to this. Again, a port of 5.3.6H1 couldn't have been made for the alpha-based filers coincident with the x86-based F840? Lastly, could the boot process be made smarter to load the appropriate microkernel, x86 or alpha, if *both* were included on disk? These gyrations to install and download x86- or alpha-based code from *floppy* (slllooowwwww) just seems so...so...kludgy. Probably not, but I'm just asking. Makes a simple head-swap upgrade not so simple. In summary, in comparison to the usual elegant and quick upgrades and downgrades for previous ONTAP versions, these points above just increased my downtime [0] and decreased my comfort level. (BTW, the 840 is taking the load of our previous 760 without even breaking a sweat. Yipee!) [0] Just one of these migrations or ugprade/downgrades takes you far below a 99.999% uptime metric. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

F760/F840, ONTAP 5.3.x/6.x gripes
by Todd C. Merrill 12 Oct '00

12 Oct '00

Can someone from NetApp comment on these following concerns? It seems...inconvenient for those who upgraded to ONTAP 6 on F760s to have to revert back to 5.3.6.x in order to upgrade to the F840s. The release of ONTAP 6 couldn't wait until a port to the x86 code was ready for the F840s? And, also, why won't 5.3.6H1 run on an alpha-based filer? I couldn't test 5.3.6H1 *anywhere* in my environment, except on my new F840 which I needed immediately on a high-visibilty filer. I upgraded and went live with 5.3.6H1 and crossed my fingers that there would be no problems with this new release. Very unnerving. I'm now running with two different ONTAP versions on a group of filers, and hoping I don't run into any inconsistencies across my environment due to this. Again, a port of 5.3.6H1 couldn't have been made for the alpha-based filers coincident with the x86-based F840? Lastly, could the boot process be made smarter to load the appropriate microkernel, x86 or alpha, if *both* were included on disk? These gyrations to install and download x86- or alpha-based code from *floppy* (slllooowwwww) just seems so...so...kludgy. Probably not, but I'm just asking. Makes a simple head-swap upgrade not so simple. In summary, in comparison to the usual elegant and quick upgrades and downgrades for previous ONTAP versions, these points above just increased my downtime [0] and decreased my comfort level. (BTW, the 840 is taking the load of our previous 760 without even breaking a sweat. Yipee!) [0] Just one of these migrations or ugprade/downgrades takes you far below a 99.999% uptime metric. Until next time... The Mathworks, Inc. 508-647-7000 x7792 3 Apple Hill Drive, Natick, MA 01760-2098 508-647-7001 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

3 4

SAN's and backups (Was: Re: Veritas NetBackup + NDMP == Doh!!)
by mds＠gbnet.net 12 Oct '00

12 Oct '00

On Wed 11 Oct, 2000, Marion Hakanson <hakanson(a)cse.ogi.edu> wrote: > I think things are headed toward the use of SAN-connected tape > drives and libraries for this type of setup. The backup software > tells the SAN switch to connect up the appropriate number of drives > to the backup client (NetApp), and then uses NDMP to initiate the > backup on the client, using "direct attached" tape drives. When > that backup is done, you "direct attach" the drives to the next client. I can think of a rather neat scenario along those lines: as described tape drives and disk drives are all on a switched FC fabric along with one or more NetApp filers, and possibly an NDMP backup host or two. When a backup host starts a backup running, the NetApp starts causing blocks to be transferred directly from the disks it manages to the tape drive(s) that the backup host controls, mingled with a little metadata it originates itself, while sending the lion's share of metadata to the NDMP backup host. Nothing should go across any piece of wire any more times than is absolutely necessary. The same scenario could go for any normal open system (Unix, NT, AS400, whatever) in a similar fabric, but I'm not sure who's best placed to actually make it work. I'd like to think NetApp were. See, until these scenarios start coming true, SAN's aren't much more than an overworked buzzword for big flipping messes made of disks and fibre. I still think SAN's are an about-to-be-useful item, but I've yet to see much real progress. > Heck, some libraries (ATL, for one) are becoming available with NDMP > servers right in them, ethernet interface included. Dunno where > you put the file history or tape indexes, but it's getting interesting. With the nominated backup controller boxes, which keep the metadata on-line (on disk) so that restores, archival, cloning etc. remain first-order activities, as much as running databases and maintaining other applications. Backups should never be afterthoughts as they so often are. Sorry, got a bit bitter and twisted there. 8) > Speaking of NAS & tape libraries, does anybody have any experience > with the Grau Data "Infinistore Virtual Disk System" (www.graudata.com)? > It's apparently a NAS box with a RAID cache in front of a tape library. Sounds like fun. Crafted well, the scenario I describe would ideally have the IO balanced to keep the tape drives well-fed, the backup window small, the filer heads serving out of the front-door performantly and the backup controllers adequately busy. Otherwise, what would be the point? Strikes me that they're angling toward HSM which is related but not the same. > The brief article I saw in Server/Workstation Expert magazine mentioned > that an "entry level" system starts at around $100k, so I didn't read > beyond that (:-). We sure wish NetApp had something like this, > since somewhere around 80% of our filer's capacity is tied up in > files that haven't been accessed in a year or more. And that final comment makes me think you'd quite like an HSM product with NetApp-style qualities. I've often thought that it'd be nice if NetApp could make such boxes, by way of extension beyond the filers, but I don't know if anyone's tested the market to see what sort of demand there might be. >-- End of excerpt from Marion Hakanson -- -Mark ... an Englishman in Derby ...

2 1

RE: Migrating 2 x F740 => F840
by Knight, Graham 12 Oct '00

12 Oct '00

If you have two volumes that will be merged on to one F840 and they have the same name, I would suggest attaching only the volume you'd like to use as the root of the F840 first. Then follow the procedure at the link below. After the F840 is up and running on the new volume then add the second volume. When the second vol0 is added the system will recognize it as a foreign volume and leave it offline. At that point you can rename it and bring it online with the other volume. Graham -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Wednesday, October 11, 2000 8:52 PM To: toasters(a)mathworks.com Subject: Migrating 2 x F740 => F840 Is it possible to "merge" the disk shelves from two or more F740's onto a single F840 without losing the data? It sounds like it might be as simple as having to rename volumes (to avoid having multiple /vol/vol0's) when attaching the shelves to the F840. Has anyone tried this? Any requirements or caveats to watch out for? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

RE: Migrating 2 x F740 => F840
by Ljungberg, Anders 12 Oct '00

12 Oct '00

Hello Brian, Well first you have to decide which volume to be your new root. (or you may be using a brand new one) ( vol options volname root) The volumes will come up as "foreign" and named /vol/vol0 and /vol/vol0(2) Bring them online with "vol online" and change the names with "vol rename" Anders Ljungberg -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: Thursday, October 12, 2000 6:12 AM To: toasters(a)mathworks.com Subject: Re: Migrating 2 x F740 => F840 On Wed, 11 Oct 2000, Brian Tao wrote: > > Is it possible to "merge" the disk shelves from two or more F740's > onto a single F840 without losing the data? It sounds like it might > be as simple as having to rename volumes (to avoid having multiple > /vol/vol0's) when attaching the shelves to the F840. Has anyone tried > this? Any requirements or caveats to watch out for? Here is the document on NOW describing the migration procedure (including kernel and bootblock update) going from an F700 series to an F840: http://now.netapp.com/Knowledgebase/solutionarea.asp?id=3.0.6869703.2865011 It doesn't specifically cover adding another volume of disks that was once considered to be the /vol/vol0 boot volume on different filer, but I imagine that is easily solved by renaming the volume once it is on the destination filer? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 0

Migrating 2 x F740 => F840
by Brian Tao 12 Oct '00

12 Oct '00

Is it possible to "merge" the disk shelves from two or more F740's onto a single F840 without losing the data? It sounds like it might be as simple as having to rename volumes (to avoid having multiple /vol/vol0's) when attaching the shelves to the F840. Has anyone tried this? Any requirements or caveats to watch out for? -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't"

1 1

RE: Veritas NetBackup + NDMP == Doh!!
by Alvarado, Michael 11 Oct '00

11 Oct '00

Here are two documents that overview the new library with the Gigabit Ethernet interface along with the ported NDMP tape server. http://www.atlp.com/pdf/ctrjuly2000.pdf ATL supports NDMP/NAS/GbE http://is.pennnet.com/home/articles.cfm?ARTICLE_ID=81787&VERSION_NUM=1&PUBL… ON_ID=23&Section=CurrentIssue -----Original Message----- From: Joe Luchtenberg [mailto:joe.luchtenberg@data-line.com] Sent: Wednesday, October 11, 2000 2:06 PM To: 'Marion Hakanson'; Scott Mikusko Cc: Cormier, Darleen; 'Jeffrey Krueger'; toasters(a)mathworks.com Subject: RE: Veritas NetBackup + NDMP == Doh!! Didn't take time to check the archives, but I believe the NAS w/SAN centralized tape backup has been addressed here before. The "certified" solution incorporates NetApp/Veritas/Vixel/Spectra Logic. Joe Joe Luchtenberg Dataline, Inc. New number and email, please update: 757.858.0600 858.0606 fax joe.luchtenberg(a)data-line.com > -----Original Message----- > From: Marion Hakanson [SMTP:hakanson@cse.ogi.edu] > Sent: Wednesday, October 11, 2000 2:27 PM > To: Scott Mikusko > Cc: Cormier, Darleen; 'Jeffrey Krueger'; toasters(a)mathworks.com > Subject: Re: Veritas NetBackup + NDMP == Doh!! > > > . . . > > This is where allowing NDMP to dump to a remote tape library is very > > important, because systems such as I support require more than 4 drives > > and having local tapes drives on filers is not really feasible. > > > > -Scott > > I think things are headed toward the use of SAN-connected tape > drives and libraries for this type of setup. The backup software > tells the SAN switch to connect up the appropriate number of drives > to the backup client (NetApp), and then uses NDMP to initiate the > backup on the client, using "direct attached" tape drives. When > that backup is done, you "direct attach" the drives to the next client. > > I think Veritas and NetApp claim to support something like this, but > only with certain SAN switching equipment. If you've got SCSI drives > (as opposed to FC), then you'll need a SCSI-to-FC converter while > you're at it. > > Heck, some libraries (ATL, for one) are becoming available with NDMP > servers right in them, ethernet interface included. Dunno where > you put the file history or tape indexes, but it's getting interesting. > > Speaking of NAS & tape libraries, does anybody have any experience > with the Grau Data "Infinistore Virtual Disk System" (www.graudata.com)? > It's apparently a NAS box with a RAID cache in front of a tape library. > > The brief article I saw in Server/Workstation Expert magazine mentioned > that an "entry level" system starts at around $100k, so I didn't read > beyond that (:-). We sure wish NetApp had something like this, > since somewhere around 80% of our filer's capacity is tied up in > files that haven't been accessed in a year or more. > > Regards, > > -- > Marion Hakanson <hakanson(a)cse.ogi.edu> > CSE Computing Facilities >

1 0

RE: Veritas NetBackup + NDMP == Doh!!
by Joe Luchtenberg 11 Oct '00

11 Oct '00

Didn't take time to check the archives, but I believe the NAS w/SAN centralized tape backup has been addressed here before. The "certified" solution incorporates NetApp/Veritas/Vixel/Spectra Logic. Joe Joe Luchtenberg Dataline, Inc. New number and email, please update: 757.858.0600 858.0606 fax joe.luchtenberg(a)data-line.com > -----Original Message----- > From: Marion Hakanson [SMTP:hakanson@cse.ogi.edu] > Sent: Wednesday, October 11, 2000 2:27 PM > To: Scott Mikusko > Cc: Cormier, Darleen; 'Jeffrey Krueger'; toasters(a)mathworks.com > Subject: Re: Veritas NetBackup + NDMP == Doh!! > > > . . . > > This is where allowing NDMP to dump to a remote tape library is very > > important, because systems such as I support require more than 4 drives > > and having local tapes drives on filers is not really feasible. > > > > -Scott > > I think things are headed toward the use of SAN-connected tape > drives and libraries for this type of setup. The backup software > tells the SAN switch to connect up the appropriate number of drives > to the backup client (NetApp), and then uses NDMP to initiate the > backup on the client, using "direct attached" tape drives. When > that backup is done, you "direct attach" the drives to the next client. > > I think Veritas and NetApp claim to support something like this, but > only with certain SAN switching equipment. If you've got SCSI drives > (as opposed to FC), then you'll need a SCSI-to-FC converter while > you're at it. > > Heck, some libraries (ATL, for one) are becoming available with NDMP > servers right in them, ethernet interface included. Dunno where > you put the file history or tape indexes, but it's getting interesting. > > Speaking of NAS & tape libraries, does anybody have any experience > with the Grau Data "Infinistore Virtual Disk System" (www.graudata.com)? > It's apparently a NAS box with a RAID cache in front of a tape library. > > The brief article I saw in Server/Workstation Expert magazine mentioned > that an "entry level" system starts at around $100k, so I didn't read > beyond that (:-). We sure wish NetApp had something like this, > since somewhere around 80% of our filer's capacity is tied up in > files that haven't been accessed in a year or more. > > Regards, > > -- > Marion Hakanson <hakanson(a)cse.ogi.edu> > CSE Computing Facilities >

1 0

RE: Veritas NetBackup + NDMP == Doh!!
by Cormier, Darleen 11 Oct '00

11 Oct '00

Jeff, FYI, Workstation Solutions' Quick Restore package also allows all of the configuration options that Budtools allowed. If you want to take a look at their stuff, the url is www.worksta.com You're right that Veritas requires the drives in the library to be either directly attached to a filer, or attached to another filer. On the second issue, each F760 is able to support up to four tape drives, an F740 can support 2 and our newer F840 can support up to 8, so it depends on the model of filer you have. If your tape library supports splitting the internal bus, by daisy chaining a couple of drives together and cabling them directly to a filer, we have customers who are doing this, using Veritas to control the robotics. A backup package is required to control the robotics because we have no robotics control capability built-in to DataOnTap. Hope this helps. -----Original Message----- From: Jeffrey Krueger [mailto:jkrueger@qualcomm.com] Sent: Tuesday, October 10, 2000 7:04 PM To: toasters(a)mathworks.com Subject: Veritas NetBackup + NDMP == Doh!! We are currently using BudTool and implementing Veritas NetBackup as a replacement. We want to use NDMP to dump the filer's data off to a NetBackup server (big honkin' sun box w/ lots of library enclosed DLT7k's). Veritas says that in 3.2, they only support NDMP dump/restore to filer attached tape. In 3.4 they claim to support NDMP 3-way dump/restore from one NetApp to another NetApp with locally attached tape. So we are double hosed. Of course, BudTool effortlessly does NDMP to the filer attached tape, 3-way to another filer attached tape, and apparently right back into the BudTool host which is what we want with NetBackup. Anyone else trying to do the same thing? Any other ideas short of sitting on Veritas? On another topic entirely, does anyone have experience attaching many (2-4) DLT7k's per NetApp and using them as a backup tape server via 3-way NDMP? Something tells me that ONTAP and the filer are not designed to handle this well, but we'd like to see if anyone else is trying this. A possible solution for us would be using two or three filers with 4 drives attached to each as a pool of dump/restore servers for the other 20 or 30 filers. Thanks!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

3 2

FS: F200/F300/F500 parts and upgrades
by ScottUCE＠aol.com 11 Oct '00

11 Oct '00

Various older Netapp parts are priced as follows: X1101 FDDI dual attached cards 395.00 X1001 10Base-T/100Base-T cards 65.00 X311 2mb NVRAM expansions 75.00 X312 64mb system memory expansions 125.00 X212 4gb narrow disk drives 125.00 X217 4gb wide disk drives 250.00 X219 9gb fiber channel drives 450.00 Further, we have many other hard-to-find parts and upgrades for the F200, F300, F500 and F600 series systems. Please call for availability and pricing; we invite any offers. Scott Fischmann Union Computer Exchange, Inc. 6233 Idylwood Lane Minneapolis, MN 55436 (952) 935-7282 (952) 935-5056 - FAX www.unioncomputer.com

1 0

Veritas NetBackup + NDMP == Doh!!
by Jeffrey Krueger 11 Oct '00

11 Oct '00

We are currently using BudTool and implementing Veritas NetBackup as a replacement. We want to use NDMP to dump the filer's data off to a NetBackup server (big honkin' sun box w/ lots of library enclosed DLT7k's). Veritas says that in 3.2, they only support NDMP dump/restore to filer attached tape. In 3.4 they claim to support NDMP 3-way dump/restore from one NetApp to another NetApp with locally attached tape. So we are double hosed. Of course, BudTool effortlessly does NDMP to the filer attached tape, 3-way to another filer attached tape, and apparently right back into the BudTool host which is what we want with NetBackup. Anyone else trying to do the same thing? Any other ideas short of sitting on Veritas? On another topic entirely, does anyone have experience attaching many (2-4) DLT7k's per NetApp and using them as a backup tape server via 3-way NDMP? Something tells me that ONTAP and the filer are not designed to handle this well, but we'd like to see if anyone else is trying this. A possible solution for us would be using two or three filers with 4 drives attached to each as a pool of dump/restore servers for the other 20 or 30 filers. Thanks!! -- Jeff -- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff(a)qualcomm.com Senior Engineer Phone: 858-651-6709 NetApp Filers / UNIX Infrastructure Fax: 858-651-6627 QUALCOMM, Inc. IT Engineering Web: www.qualcomm.com

3 2

RE: Mac G4 with Netapp
by Mike Sphar 11 Oct '00

11 Oct '00

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

2 1

Re: High Performance volume configuration
by Rick Hulsey 11 Oct '00

11 Oct '00

They (Netapp) spent a fair amount time in the Netapp 202 class teaching about how it is best to keep a RAID group on one controller. If you have a single RAID group that spans more than one FC-AL interface, it is called a fractured RAID group, and there was even a lab in the class where they went through how to correct a fractured RAID group and put the disks back on one FC-AL controller. It looks like the configuration that was used in the benchmark was a single volume that had 2 RAID groups (RAID group 0, and RAID group 1, presumably), and each of these RAID groups was cabled up to separate interfaces. I'm guessing that this configuration would yield a filesystem that is striped across both FC-AL interfaces. Since the RAID calculations are done at the RAID group level rather than at the volume level it makes sense that more than one RAID calculation can be done in parallel. Based on that assumption, splitting a volume across 2 controllers (while preventing RAID group fracturing) should improve performance. Rick Hulsey Southwest Airlines 2425 Wyman Mail Stop 4DC Dallas, Tx., 75235 rick.hulsey(a)wnco.com (214) 792-7188 Office (972) 880-6882 Cell (800) 915-3747 Pager >>> Graydon Dodson <grdodson(a)lexmark.com> 10/09/00 04:22PM >>> > 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: Mac G4 with NetApp
by Mike Sphar 11 Oct '00

11 Oct '00

Actually, I've worked with TotalNet before in the past as well, though we didn't use the Appletalk features. It's been a while, but I'm almost positive that Totalnet could be pointed at NT domain controllers for authentication. The question would be whether the appletalk module would utilize that as well. We were pretty happy with Totalnet as I recall. The only issue we had was that it sprinkled little .tn<something> hidden files everywhere that we had to remember to remove before burning our final software releases to CD. Speaking of CAP, I did a little checking up on it, and it does appear to be falling by the wayside. Even one of the major contributors says he uses Netatalk instead now. -- Mike Sphar - Sr Systems Administrator - Engineering Support Services, BOFH, GWP, MCP, MCP+I, MCSE, BFD -----Original Message----- From: Knight, Graham [mailto:Graham.Knight@netapp.com] Sent: Tuesday, October 10, 2000 2:43 PM To: toasters(a)mathworks.com Subject: RE: Mac G4 with NetApp When I was with Lockheed we were faced with a similar dilemma. We tested a number of Unix based solutions. The best we found was the "totalnet advanced server" by Syntax software ( www.syntax.com <http://www.syntax.com> ). It can take an NFS mount served by a Netapp and export it to a Mac. CAP has fallen badly behind and I honestly don't think it will ever catch up with the level of support that it gets. There are serious file locking and file rename problems with CAP and Microsoft applications. We never had the same type of problems with Syntax. To solve the specific problem as I understood it (need to use NT authentication for the NFS mounted Appletalk share (Phew!)), I think you would have to bundle something like Syntax software with some sort of LDAP solution pointing to the PDC for user authentication. Not an easy problem to solve. It could be that Syntax has a solution nowadays. It's been a couple years since I looked into this. I don't have anything to do with Syntax (Neither does Netapp to my knowledge) I just used it, and it worked well for Macintosh services. It might be a good place to start the search for the solution to the problem. Graham -----Original Message----- From: Mike Sphar [mailto:mikey@remedy.com] Sent: Tuesday, October 10, 2000 2:58 PM To: toasters(a)mathworks.com Subject: RE: Mac G4 with NetApp 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 Knight, Graham 10 Oct '00

10 Oct '00

When I was with Lockheed we were faced with a similar dilemma. We tested a number of Unix based solutions. The best we found was the "totalnet advanced server" by Syntax software ( www.syntax.com <http://www.syntax.com> ). It can take an NFS mount served by a Netapp and export it to a Mac. CAP has fallen badly behind and I honestly don't think it will ever catch up with the level of support that it gets. There are serious file locking and file rename problems with CAP and Microsoft applications. We never had the same type of problems with Syntax. To solve the specific problem as I understood it (need to use NT authentication for the NFS mounted Appletalk share (Phew!)), I think you would have to bundle something like Syntax software with some sort of LDAP solution pointing to the PDC for user authentication. Not an easy problem to solve. It could be that Syntax has a solution nowadays. It's been a couple years since I looked into this. I don't have anything to do with Syntax (Neither does Netapp to my knowledge) I just used it, and it worked well for Macintosh services. It might be a good place to start the search for the solution to the problem. Graham -----Original Message----- From: Mike Sphar [mailto:mikey@remedy.com] Sent: Tuesday, October 10, 2000 2:58 PM To: toasters(a)mathworks.com Subject: RE: Mac G4 with NetApp 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: 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