toasters

toasters@lists.teaparty.net

13531 discussions

RE: Filers and Lotus Notes...
by Allison, Bridget 19 Mar '99

19 Mar '99

Unfortunately I don't have any good info on Notes with NFS but we're about to publish a tech report detailing a config that works fine with NT. I'd be happy to send you a draft version if you need it within the next week or so. We've validated the NT based Notes stuff via NotesBench and the report can be viewed at http://www.netapp.com/technology/level3/notesbench.html or at www.notesbench.org. > -----Original Message----- > From: Paul Taylor [mailto:ptaylor@netaxs.com] > Sent: Monday, March 15, 1999 11:17 AM > To: toasters(a)mathworks.com > Cc: Catalyst PECO support > Subject: Filers and Lotus Notes... > > > > Hi. I would like to know if anyone has had any experience with NetApp > filers and Lotus Notes. Here is our situation: > > We have an F630 that has 2 LN server attached to it (among > other things), > running across Fast Etherchannel. One of the LN servers is on > WinNT and > the other is on AIX. The AIX box is a RS/6000 H50 with a > single CPU, and > 512MB RAM. The NT box is a single CPU netfinity with 512MB > RAM, running at > 400mhz. The Filer has 512MB onboard, running DoT 5.1D12. LN > is v. 4.6.2. > We have 2 networks on each server, a public network that goes to the > internet, and a private network (a 10. ) that goes to the filer. > > The problem we had at first was with LN itself not liking UNC > names. For > this problem I installed PCNFSD, and ran it that way for a > while. Now we > are experiencing corruption at random times. I figure it is > probably the > connectionless nature of NFS. Bah. Anyone have any better ideas? BTW: > client doesn't want to do directory links, it has to run as a > service, and > it has to run as system. > > Next problem: We installed Domino on an RS6K adn it ran > horribly. I moved > it over to local disk, and it ran great. Hmmmmm.... > > Here is the mount info for the rs6k from /etc/filesystems > (commented out > for now since we went to local disk: > > * /lnmobem01: > * dev = "/vol/vol0/lnmobem01" > * vfs = nfs > * nodename = efiler01 > * mount = true > * options > =bg,hard,intr,rsize=4096,wsize=4096,vers=2,proto=udp > account = true > > Anyone have any ideas as to why this would act slow when > opening a DB? it > takes about 1.5 min to open log.nsf, when it should take > about .5 sec. > > Thanks, > > > Paul > > > > >

2 1

stupid SMTP questions
by Graham C. Knight 19 Mar '99

19 Mar '99

Sorry if this seems rudimentary - but i'm looking into this stuff for the first time and i'm finding it a bit confusing. I downloaded and i'm using filer-mrtg which uses mrtg to plot various system parameters - some of which are collected using SMTP. In the cfg files for the filers i can see lines like this: Target[ast-h-tsb02.net.snmp]: 1.3.6.1.4.1.789.1.2.2.2.0&1.3.6.1.4.1.789.1.2.2.3.0:public@ast-h-tsb02 The one above gets total network traffic from the filer. Where do these long lines of numbers come from? Where are they defined? I'm getting the impression that they are somehow related to the netapp.mib file - but i can't find any clues how that format is converted into these sets on numbers. For instance, i'd like to monitor snapshot size - it looks like i could do it according to the netapp.mib but i cannot figure out what string of numbers or parameters to put into the Target field. Any tips - or pointers (including "go read this book") would be much appreciated. Thx, Graham

3 2

Re: NetCaches and IP representations
by jrg＠acm.org 19 Mar '99

19 Mar '99

On Thu 18 Mar, 1999, Alex French <alex(a)medianet.ie> wrote: >Here's one for the obscurities wishlist: our NetCaches don't recognise >integer representations of IPs. Instead of interpreting 3263497985 as >194.133.7.1, for example, they look for www.3263497985.com. If we look at the RFC that covers the specification of URLs - RFC 1738 - and looking at the section that applies to http (3.3): http://<host>:<port>/<path>?<searchpart> where <host> and <port> are as described in Section 3.1. If :<port> [and 3.1 says] host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses. (That sort of 'feature' can allow you through proxy net-nanny filters, too, quite often) James.

3 2

Re: NetCaches and IP representations
by sirbruce＠ix.netcom.com 19 Mar '99

19 Mar '99

On 03/17/99 22:07:19 you wrote: OTOH, are non-doted IP adresses valid URLs? They are not required according to the RFC (see guy's email for a full discussion). When I did a quick look I couldn't find any other interface documents (telnet, etc.) that required anything other than dotted decimals for IP translation, either, but I can't say for certain that's entirely true. Anyway, when it comes to URLs, the fact that they work is an artifact of the code, not the specification. Bruce

4 4

RE: stupid SMTP questions
by Hackworth, Brian 18 Mar '99

18 Mar '99

: In the cfg files for the filers i can see lines like this: : : Target[ast-h-tsb02.net.snmp]: : 1.3.6.1.4.1.789.1.2.2.2.0&1.3.6.1.4.1.789.1.2.2.3.0:public@ast-h-tsb02 : : The one above gets total network traffic from the filer. : : Where do these long lines of numbers come from? Where : are they defined? I'm getting the impression that they : are somehow related to the netapp.mib file - but i can't : find any clues how that format is converted into these : sets on numbers. These numbers are indeed derived from the netapp.mib. The 1.3.6.1.4.1.789 is the top of the NetApp MIB. You can map the other numbers to names by following the trail in the MIB: netapp OBJECT IDENTIFIER ::= { enterprises 789 } netapp1 OBJECT IDENTIFIER ::= { netapp 1 } sysStat OBJECT IDENTIFIER ::= { netapp1 2 } misc OBJECT IDENTIFIER ::= { sysStat 2 } miscNetRcvdKB OBJECT-TYPE ::= { misc 2 } miscNetSentKB OBJECT-TYPE ::= { misc 3 } So 1.3.6.1.4.1.789.1.2.2.2.0 is netapp.netapp1.sysStat.misc.miscNetRcvdKB and 1.3.6.1.4.1.789.1.2.2.2.0 us netapp.netapp1.sysStat.misc.miscNetSentKB. Software can do this mapping for you, too. The CMU snmp tools can parse the MIB and show numbers or names. Here's a table of some of the more commonly-used variables from the NetApp version 1.1.1 MIB (supported in ONTAP 5.1 and later). Note that all of the OIDs should be prefixed with "1.3.6.1.4.1.789.1": 1.1.0 product.productType 1.2.0 product.productVersion 1.3.0 product.productId 2.1.1.0 sysStat.cpu.cpuUpTime 2.1.2.0 sysStat.cpu.cpuBusyTime 2.1.3.0 sysStat.cpu.cpuBusyTimePerCent 2.1.4.0 sysStat.cpu.cpuIdleTime 2.1.5.0 sysStat.cpu.cpuIdleTimePerCent 2.2.1.0 sysStat.misc.miscNfsOps 2.2.2.0 sysStat.misc.miscNetRcvdKB 2.2.3.0 sysStat.misc.miscNetSentKB 2.3.1.0 sysStat.cf.cfSettings 2.3.2.0 sysStat.cf.cfState 2.3.3.0 sysStat.cf.cfCannotTakeoverCause 2.3.4.0 sysStat.cf.cfPartnerStatus 2.3.5.0 sysStat.cf.cfPartnerLastStatusUpdate 2.3.6.0 sysStat.cf.cfPartnerName 2.3.7.0 sysStat.cf.cfPartnerSysid 2.3.8.0 sysStat.cf.cfInterconnectStatus 3.1.1.1.0 nfs.curNfs.rpcServ.rpcCalls 3.1.1.2.0 nfs.curNfs.rpcServ.rpcBadCalls 3.1.1.3.0 nfs.curNfs.rpcServ.rpcNullRecvs 3.1.1.4.0 nfs.curNfs.rpcServ.rpcBadLens 3.1.1.5.0 nfs.curNfs.rpcServ.rpcServXDRCalls 3.1.2.1.0 nfs.curNfs.nfsServ.nfsCalls 3.1.2.2.0 nfs.curNfs.nfsServ.nfsServBadCalls 3.1.2.3.1.1.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cNulls 3.1.2.3.1.2.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cGetattrs 3.1.2.3.1.3.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cSetattrs 3.1.2.3.1.4.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cRoots 3.1.2.3.1.5.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cLookups 3.1.2.3.1.6.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cReadlinks 3.1.2.3.1.7.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cReads 3.1.2.3.1.8.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cWrcaches 3.1.2.3.1.9.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cWrites 3.1.2.3.1.10.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cCreates 3.1.2.3.1.11.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cRemoves 3.1.2.3.1.12.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cRenames 3.1.2.3.1.13.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cLinks 3.1.2.3.1.14.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cSymlinks 3.1.2.3.1.15.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cMkdirs 3.1.2.3.1.16.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cRmdirs 3.1.2.3.1.17.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cReaddirs 3.1.2.3.1.18.0 nfs.curNfs.nfsServ.nfsV2.v2Calls.v2cStatfss 3.1.2.3.2.1.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pNulls 3.1.2.3.2.2.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pGetattrs 3.1.2.3.2.3.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pSetattrs 3.1.2.3.2.4.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pRoots 3.1.2.3.2.5.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pLookups 3.1.2.3.2.6.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pReadlinks 3.1.2.3.2.7.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pReads 3.1.2.3.2.8.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pWrcaches 3.1.2.3.2.9.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pWrites 3.1.2.3.2.10.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pCreates 3.1.2.3.2.11.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pRemoves 3.1.2.3.2.12.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pRenames 3.1.2.3.2.13.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pLinks 3.1.2.3.2.14.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pSymlinks 3.1.2.3.2.15.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pMkdirs 3.1.2.3.2.16.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pRmdirs 3.1.2.3.2.17.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pReaddirs 3.1.2.3.2.18.0 nfs.curNfs.nfsServ.nfsV2.v2Percent.v2pStatfss 3.1.2.3.3.1.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccNulls 3.1.2.3.3.2.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccGetattrs 3.1.2.3.3.3.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccSetattrs 3.1.2.3.3.4.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccRoots 3.1.2.3.3.5.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccLookups 3.1.2.3.3.6.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccReadlinks 3.1.2.3.3.7.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccReads 3.1.2.3.3.8.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccWrcaches 3.1.2.3.3.9.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccWrites 3.1.2.3.3.10.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccCreates 3.1.2.3.3.11.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccRemoves 3.1.2.3.3.12.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccRenames 3.1.2.3.3.13.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccLinks 3.1.2.3.3.14.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccSymlinks 3.1.2.3.3.15.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccMkdirs 3.1.2.3.3.16.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccRmdirs 3.1.2.3.3.17.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccReaddirs 3.1.2.3.3.18.0 nfs.curNfs.nfsServ.nfsV2.v2CachedCalls.v2ccStatfss 3.1.2.3.4.1.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpNulls 3.1.2.3.4.2.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpGetattrs 3.1.2.3.4.3.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpSetattrs 3.1.2.3.4.4.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpRoots 3.1.2.3.4.5.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpLookups 3.1.2.3.4.6.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpReadlinks 3.1.2.3.4.7.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpReads 3.1.2.3.4.8.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpWrcaches 3.1.2.3.4.9.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpWrites 3.1.2.3.4.10.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpCreates 3.1.2.3.4.11.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpRemoves 3.1.2.3.4.12.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpRenames 3.1.2.3.4.13.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpLinks 3.1.2.3.4.14.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpSymlinks 3.1.2.3.4.15.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpMkdirs 3.1.2.3.4.16.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpRmdirs 3.1.2.3.4.17.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpReaddirs 3.1.2.3.4.18.0 nfs.curNfs.nfsServ.nfsV2.v2CachedPerCent.v2cpStatfss 3.1.2.4.1.1.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cNulls 3.1.2.4.1.2.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cGetattrs 3.1.2.4.1.3.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cSetattrs 3.1.2.4.1.4.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cLookups 3.1.2.4.1.5.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cAccesss 3.1.2.4.1.6.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cReadlinks 3.1.2.4.1.7.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cReads 3.1.2.4.1.8.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cWrites 3.1.2.4.1.9.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cCreates 3.1.2.4.1.10.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cMkdirs 3.1.2.4.1.11.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cSymlinks 3.1.2.4.1.12.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cMknods 3.1.2.4.1.13.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cRemoves 3.1.2.4.1.14.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cRmdirs 3.1.2.4.1.15.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cRenames 3.1.2.4.1.16.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cLinks 3.1.2.4.1.17.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cReaddirs 3.1.2.4.1.18.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cReaddirPluss 3.1.2.4.1.19.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cFsstats 3.1.2.4.1.20.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cFsinfos 3.1.2.4.1.21.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cPathconfs 3.1.2.4.1.22.0 nfs.curNfs.nfsServ.nfsV3.v3Calls.v3cCommits 3.1.2.4.2.1.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pNulls 3.1.2.4.2.2.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pGetattrs 3.1.2.4.2.3.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pSetattrs 3.1.2.4.2.4.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pLookups 3.1.2.4.2.5.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pAccesss 3.1.2.4.2.6.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pReadlinks 3.1.2.4.2.7.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pReads 3.1.2.4.2.8.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pWrites 3.1.2.4.2.9.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pCreates 3.1.2.4.2.10.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pMkdirs 3.1.2.4.2.11.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pSymlinks 3.1.2.4.2.12.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pMknods 3.1.2.4.2.13.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pRemoves 3.1.2.4.2.14.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pRmdirs 3.1.2.4.2.15.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pRenames 3.1.2.4.2.16.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pLinks 3.1.2.4.2.17.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pReaddirs 3.1.2.4.2.18.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pReaddirPluss 3.1.2.4.2.19.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pFsstats 3.1.2.4.2.20.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pFsinfos 3.1.2.4.2.21.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pPathconfs 3.1.2.4.2.22.0 nfs.curNfs.nfsServ.nfsV3.v3Percent.v3pCommits 3.1.2.4.3.1.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccNulls 3.1.2.4.3.2.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccGetattrs 3.1.2.4.3.3.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccSetattrs 3.1.2.4.3.4.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccLookups 3.1.2.4.3.5.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccAccesss 3.1.2.4.3.6.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccReadlinks 3.1.2.4.3.7.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccReads 3.1.2.4.3.8.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccWrites 3.1.2.4.3.9.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccCreates 3.1.2.4.3.10.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccMkdirs 3.1.2.4.3.11.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccSymlinks 3.1.2.4.3.12.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccMknods 3.1.2.4.3.13.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccRemoves 3.1.2.4.3.14.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccRmdirs 3.1.2.4.3.15.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccRenames 3.1.2.4.3.16.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccLinks 3.1.2.4.3.17.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccReaddirs 3.1.2.4.3.18.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccReaddirPluss 3.1.2.4.3.19.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccFsstats 3.1.2.4.3.20.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccFsinfos 3.1.2.4.3.21.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccPathconfs 3.1.2.4.3.22.0 nfs.curNfs.nfsServ.nfsV3.v3CachedCalls.v3ccCommits 3.1.2.4.4.1.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpNulls 3.1.2.4.4.2.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpGetattrs 3.1.2.4.4.3.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpSetattrs 3.1.2.4.4.4.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpLookups 3.1.2.4.4.5.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpAccesss 3.1.2.4.4.6.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpReadlinks 3.1.2.4.4.7.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpReads 3.1.2.4.4.8.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpWrites 3.1.2.4.4.9.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpCreates 3.1.2.4.4.10.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpMkdirs 3.1.2.4.4.11.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpSymlinks 3.1.2.4.4.12.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpMknods 3.1.2.4.4.13.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpRemoves 3.1.2.4.4.14.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpRmdirs 3.1.2.4.4.15.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpRenames 3.1.2.4.4.16.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpLinks 3.1.2.4.4.17.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpReaddirs 3.1.2.4.4.18.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpReaddirPluss 3.1.2.4.4.19.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpFsstats 3.1.2.4.4.20.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpFsinfos 3.1.2.4.4.21.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpPathconfs 3.1.2.4.4.22.0 nfs.curNfs.nfsServ.nfsV3.v3CachedPerCent.v3cpCommits 3.1.2.5.1.0 nfs.curNfs.nfsServ.replyCache.rcInProgressHits 3.1.2.5.2.0 nfs.curNfs.nfsServ.replyCache.rcDelayHits 3.1.2.5.3.0 nfs.curNfs.nfsServ.replyCache.rcMisses 3.1.2.5.4.0 nfs.curNfs.nfsServ.replyCache.rcNonIdemDoneHits 3.1.2.5.5.0 nfs.curNfs.nfsServ.replyCache.rcNonIdemNotDoneHits 3.2.1.1.0 nfs.totNfs.trpcServ.trpcCalls 3.2.1.2.0 nfs.totNfs.trpcServ.trpcBadCalls 3.2.1.3.0 nfs.totNfs.trpcServ.trpcNullRecvs 3.2.1.4.0 nfs.totNfs.trpcServ.trpcBadLens 3.2.1.5.0 nfs.totNfs.trpcServ.trpcServXDRCalls 3.2.2.1.0 nfs.totNfs.tnfsServ.tnfsCalls 3.2.2.2.0 nfs.totNfs.tnfsServ.tnfsServBadCalls 3.2.2.3.1.1.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cNulls 3.2.2.3.1.2.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cGetattrs 3.2.2.3.1.3.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cSetattrs 3.2.2.3.1.4.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cRoots 3.2.2.3.1.5.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cLookups 3.2.2.3.1.6.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cReadlinks 3.2.2.3.1.7.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cReads 3.2.2.3.1.8.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cWrcaches 3.2.2.3.1.9.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cWrites 3.2.2.3.1.10.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cCreates 3.2.2.3.1.11.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cRemoves 3.2.2.3.1.12.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cRenames 3.2.2.3.1.13.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cLinks 3.2.2.3.1.14.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cSymlinks 3.2.2.3.1.15.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cMkdirs 3.2.2.3.1.16.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cRmdirs 3.2.2.3.1.17.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cReaddirs 3.2.2.3.1.18.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Calls.tv2cStatfss 3.2.2.3.2.1.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pNulls 3.2.2.3.2.2.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pGetattrs 3.2.2.3.2.3.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pSetattrs 3.2.2.3.2.4.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pRoots 3.2.2.3.2.5.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pLookups 3.2.2.3.2.6.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pReadlinks 3.2.2.3.2.7.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pReads 3.2.2.3.2.8.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pWrcaches 3.2.2.3.2.9.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pWrites 3.2.2.3.2.10.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pCreates 3.2.2.3.2.11.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pRemoves 3.2.2.3.2.12.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pRenames 3.2.2.3.2.13.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pLinks 3.2.2.3.2.14.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pSymlinks 3.2.2.3.2.15.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pMkdirs 3.2.2.3.2.16.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pRmdirs 3.2.2.3.2.17.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pReaddirs 3.2.2.3.2.18.0 nfs.totNfs.tnfsServ.tnfsV2.tv2Percent.tv2pStatfss 3.2.2.3.3.1.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccNulls 3.2.2.3.3.2.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccGetattrs 3.2.2.3.3.3.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccSetattrs 3.2.2.3.3.4.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccRoots 3.2.2.3.3.5.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccLookups 3.2.2.3.3.6.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccReadlinks 3.2.2.3.3.7.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccReads 3.2.2.3.3.8.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccWrcaches 3.2.2.3.3.9.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccWrites 3.2.2.3.3.10.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccCreates 3.2.2.3.3.11.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccRemoves 3.2.2.3.3.12.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccRenames 3.2.2.3.3.13.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccLinks 3.2.2.3.3.14.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccSymlinks 3.2.2.3.3.15.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccMkdirs 3.2.2.3.3.16.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccRmdirs 3.2.2.3.3.17.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccReaddirs 3.2.2.3.3.18.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedCalls.tv2ccStatfss 3.2.2.3.4.1.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpNulls 3.2.2.3.4.2.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpGetattrs 3.2.2.3.4.3.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpSetattrs 3.2.2.3.4.4.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpRoots 3.2.2.3.4.5.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpLookups 3.2.2.3.4.6.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpReadlinks 3.2.2.3.4.7.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpReads 3.2.2.3.4.8.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpWrcaches 3.2.2.3.4.9.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpWrites 3.2.2.3.4.10.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpCreates 3.2.2.3.4.11.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpRemoves 3.2.2.3.4.12.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpRenames 3.2.2.3.4.13.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpLinks 3.2.2.3.4.14.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpSymlinks 3.2.2.3.4.15.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpMkdirs 3.2.2.3.4.16.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpRmdirs 3.2.2.3.4.17.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpReaddirs 3.2.2.3.4.18.0 nfs.totNfs.tnfsServ.tnfsV2.tv2CachedPerCent.tv2cpStatfss 3.2.2.4.1.1.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cNulls 3.2.2.4.1.2.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cGetattrs 3.2.2.4.1.3.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cSetattrs 3.2.2.4.1.4.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cLookups 3.2.2.4.1.5.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cAccesss 3.2.2.4.1.6.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cReadlinks 3.2.2.4.1.7.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cReads 3.2.2.4.1.8.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cWrites 3.2.2.4.1.9.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cCreates 3.2.2.4.1.10.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cMkdirs 3.2.2.4.1.11.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cSymlinks 3.2.2.4.1.12.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cMknods 3.2.2.4.1.13.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cRemoves 3.2.2.4.1.14.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cRmdirs 3.2.2.4.1.15.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cRenames 3.2.2.4.1.16.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cLinks 3.2.2.4.1.17.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cReaddirs 3.2.2.4.1.18.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cReaddirPluss 3.2.2.4.1.19.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cFsstats 3.2.2.4.1.20.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cFsinfos 3.2.2.4.1.21.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cPathconfs 3.2.2.4.1.22.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Calls.tv3cCommits 3.2.2.4.2.1.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pNulls 3.2.2.4.2.2.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pGetattrs 3.2.2.4.2.3.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pSetattrs 3.2.2.4.2.4.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pLookups 3.2.2.4.2.5.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pAccesss 3.2.2.4.2.6.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pReadlinks 3.2.2.4.2.7.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pReads 3.2.2.4.2.8.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pWrites 3.2.2.4.2.9.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pCreates 3.2.2.4.2.10.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pMkdirs 3.2.2.4.2.11.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pSymlinks 3.2.2.4.2.12.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pMknods 3.2.2.4.2.13.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pRemoves 3.2.2.4.2.14.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pRmdirs 3.2.2.4.2.15.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pRenames 3.2.2.4.2.16.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pLinks 3.2.2.4.2.17.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pReaddirs 3.2.2.4.2.18.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pReaddirPluss 3.2.2.4.2.19.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pFsstats 3.2.2.4.2.20.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pFsinfos 3.2.2.4.2.21.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pPathconfs 3.2.2.4.2.22.0 nfs.totNfs.tnfsServ.tnfsV3.tv3Percent.tv3pCommits 3.2.2.4.3.1.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccNulls 3.2.2.4.3.2.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccGetattrs 3.2.2.4.3.3.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccSetattrs 3.2.2.4.3.4.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccLookups 3.2.2.4.3.5.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccAccesss 3.2.2.4.3.6.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccReadlinks 3.2.2.4.3.7.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccReads 3.2.2.4.3.8.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccWrites 3.2.2.4.3.9.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccCreates 3.2.2.4.3.10.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccMkdirs 3.2.2.4.3.11.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccSymlinks 3.2.2.4.3.12.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccMknods 3.2.2.4.3.13.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccRemoves 3.2.2.4.3.14.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccRmdirs 3.2.2.4.3.15.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccRenames 3.2.2.4.3.16.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccLinks 3.2.2.4.3.17.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccReaddirs 3.2.2.4.3.18.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccReaddirPluss 3.2.2.4.3.19.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccFsstats 3.2.2.4.3.20.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccFsinfos 3.2.2.4.3.21.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccPathconfs 3.2.2.4.3.22.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedCalls.tv3ccCommits 3.2.2.4.4.1.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpNulls 3.2.2.4.4.2.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpGetattrs 3.2.2.4.4.3.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpSetattrs 3.2.2.4.4.4.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpLookups 3.2.2.4.4.5.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpAccesss 3.2.2.4.4.6.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpReadlinks 3.2.2.4.4.7.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpReads 3.2.2.4.4.8.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpWrites 3.2.2.4.4.9.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpCreates 3.2.2.4.4.10.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpMkdirs 3.2.2.4.4.11.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpSymlinks 3.2.2.4.4.12.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpMknods 3.2.2.4.4.13.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpRemoves 3.2.2.4.4.14.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpRmdirs 3.2.2.4.4.15.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpRenames 3.2.2.4.4.16.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpLinks 3.2.2.4.4.17.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpReaddirs 3.2.2.4.4.18.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpReaddirPluss 3.2.2.4.4.19.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpFsstats 3.2.2.4.4.20.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpFsinfos 3.2.2.4.4.21.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpPathconfs 3.2.2.4.4.22.0 nfs.totNfs.tnfsServ.tnfsV3.tv3CachedPerCent.tv3cpCommits 3.2.2.5.1.0 nfs.totNfs.tnfsServ.treplyCache.trcInProgressHits 3.2.2.5.2.0 nfs.totNfs.tnfsServ.treplyCache.trcDelayHits 3.2.2.5.3.0 nfs.totNfs.tnfsServ.treplyCache.trcMisses 3.2.2.5.4.0 nfs.totNfs.tnfsServ.treplyCache.trcNonIdemDoneHits 3.2.2.5.5.0 nfs.totNfs.tnfsServ.treplyCache.trcNonIdemNotDoneHits 4.1.0 quota.quotaState 4.2.0 quota.quotaInitPercent 4.3.1.1.1 quota.qrTable.qrEntry.qrIndex 4.3.1.2.1 quota.qrTable.qrEntry.qrType 4.3.1.3.1 quota.qrTable.qrEntry.qrId 4.3.1.4.1 quota.qrTable.qrEntry.qrKBytesUsed 4.3.1.5.1 quota.qrTable.qrEntry.qrKBytesLimit 4.3.1.6.1 quota.qrTable.qrEntry.qrFilesUsed 4.3.1.7.1 quota.qrTable.qrEntry.qrFileLimit 4.3.1.8.1 quota.qrTable.qrEntry.qrPathName 4.4.1.1.1 quota.qvStateTable.qvStateEntry.qvStateVolume 4.4.1.2.1 quota.qvStateTable.qvStateEntry.qvStateName 4.4.1.3.1 quota.qvStateTable.qvStateEntry.qvStateStat 4.4.1.4.1 quota.qvStateTable.qvStateEntry.qvStateInitPercent 4.5.1.1.1 quota.qrVTable.qrVEntry.qrVIndex 4.5.1.2.1 quota.qrVTable.qrVEntry.qrVType 4.5.1.3.1 quota.qrVTable.qrVEntry.qrVId 4.5.1.4.1 quota.qrVTable.qrVEntry.qrVKBytesUsed 4.5.1.5.1 quota.qrVTable.qrVEntry.qrVKBytesLimit 4.5.1.6.1 quota.qrVTable.qrVEntry.qrVFilesUsed 4.5.1.7.1 quota.qrVTable.qrVEntry.qrVFileLimit 4.5.1.8.1 quota.qrVTable.qrVEntry.qrVPathName 4.5.1.9.1 quota.qrVTable.qrVEntry.qrVVolume 4.5.1.10.1 quota.qrVTable.qrVEntry.qrVTree 5.1.0 filesys.filesysMaxfilesAvail 5.2.0 filesys.filesysMaxfilesUsed 5.3.0 filesys.filesysMaxfilesPossible 5.4.1.1.1 filesys.dfTable.dfEntry.dfIndex 5.4.1.2.1 filesys.dfTable.dfEntry.dfFileSys 5.4.1.3.1 filesys.dfTable.dfEntry.dfKBytesTotal 5.4.1.4.1 filesys.dfTable.dfEntry.dfKBytesUsed 5.4.1.5.1 filesys.dfTable.dfEntry.dfKBytesAvail 5.4.1.6.1 filesys.dfTable.dfEntry.dfPerCentKBytesCapacity 5.4.1.7.1 filesys.dfTable.dfEntry.dfInodesUsed 5.4.1.8.1 filesys.dfTable.dfEntry.dfInodesFree 5.4.1.9.1 filesys.dfTable.dfEntry.dfPerCentInodeCapacity 5.4.1.10.1 filesys.dfTable.dfEntry.dfMountedOn 5.4.1.11.1 filesys.dfTable.dfEntry.dfMaxFilesAvail 5.4.1.12.1 filesys.dfTable.dfEntry.dfMaxFilesUsed 5.4.1.13.1 filesys.dfTable.dfEntry.dfMaxFilesPossible 5.5.1.1.1.1 filesys.snapshot.slTable.slEntry.slIndex 5.5.1.1.2.1 filesys.snapshot.slTable.slEntry.slMonth 5.5.1.1.3.1 filesys.snapshot.slTable.slEntry.slDay 5.5.1.1.4.1 filesys.snapshot.slTable.slEntry.slHour 5.5.1.1.5.1 filesys.snapshot.slTable.slEntry.slMinutes 5.5.1.1.6.1 filesys.snapshot.slTable.slEntry.slName 5.5.2.1.1.1 filesys.snapshot.slVTable.slVEntry.slVIndex 5.5.2.1.2.1 filesys.snapshot.slVTable.slVEntry.slVMonth 5.5.2.1.3.1 filesys.snapshot.slVTable.slVEntry.slVDay 5.5.2.1.4.1 filesys.snapshot.slVTable.slVEntry.slVHour 5.5.2.1.5.1 filesys.snapshot.slVTable.slVEntry.slVMinutes 5.5.2.1.6.1 filesys.snapshot.slVTable.slVEntry.slVName 5.5.2.1.7.1 filesys.snapshot.slVTable.slVEntry.slVVolume 6.1.1.1.1 raid.raidTable.raidEntry.raidIndex 6.1.1.2.1 raid.raidTable.raidEntry.raidDiskName 6.1.1.3.1 raid.raidTable.raidEntry.raidStatus 6.1.1.4.1 raid.raidTable.raidEntry.raidDiskId 6.1.1.5.1 raid.raidTable.raidEntry.raidScsiAdapter 6.1.1.6.1 raid.raidTable.raidEntry.raidScsiId 6.1.1.7.1 raid.raidTable.raidEntry.raidUsedMb 6.1.1.8.1 raid.raidTable.raidEntry.raidUsedBlocks 6.1.1.9.1 raid.raidTable.raidEntry.raidTotalMb 6.1.1.10.1 raid.raidTable.raidEntry.raidTotalBlocks 6.1.1.11.1 raid.raidTable.raidEntry.raidCompletionPerCent 6.2.1.1.1 raid.raidVTable.raidVEntry.raidVIndex 6.2.1.2.1 raid.raidVTable.raidVEntry.raidVDiskName 6.2.1.3.1 raid.raidVTable.raidVEntry.raidVStatus 6.2.1.4.1 raid.raidVTable.raidVEntry.raidVDiskId 6.2.1.5.1 raid.raidVTable.raidVEntry.raidVScsiAdapter 6.2.1.6.1 raid.raidVTable.raidVEntry.raidVScsiId 6.2.1.7.1 raid.raidVTable.raidVEntry.raidVUsedMb 6.2.1.8.1 raid.raidVTable.raidVEntry.raidVUsedBlocks 6.2.1.9.1 raid.raidVTable.raidVEntry.raidVTotalMb 6.2.1.10.1 raid.raidVTable.raidVEntry.raidVTotalBlocks 6.2.1.11.1 raid.raidVTable.raidVEntry.raidVCompletionPerCent 6.2.1.12.1 raid.raidVTable.raidVEntry.raidVVol 6.2.1.13.1 raid.raidVTable.raidVEntry.raidVGroup 6.3.1.1.1 raid.spareTable.spareEntry.spareIndex 6.3.1.2.1 raid.spareTable.spareEntry.spareDiskName 6.3.1.3.1 raid.spareTable.spareEntry.spareStatus 6.3.1.4.1 raid.spareTable.spareEntry.spareDiskId 6.3.1.5.1 raid.spareTable.spareEntry.spareScsiAdapter 6.3.1.6.1 raid.spareTable.spareEntry.spareScsiId 6.3.1.7.1 raid.spareTable.spareEntry.spareTotalMb 6.3.1.8.1 raid.spareTable.spareEntry.spareTotalBlocks - Brian Hackworth

1 0

Re: NetCaches and IP representations
by mds＠gbnet.net 18 Mar '99

18 Mar '99

On Wed 17 Mar, 1999, sirbruce(a)ix.netcom.com wrote: > On 03/17/99 20:57:20 you wrote: > > > >On Thu, 18 Mar 1999, Alex French wrote: > > > >> Here's one for the obscurities wishlist: our NetCaches don't recognise > >> integer representations of IPs. Instead of interpreting 3263497985 as > >> 194.133.7.1, for example, they look for www.3263497985.com. > > > >Hmmm... > > > >That's kinda interesting seeing as I'm sure NetApp claim to be using a BSD > >TCP/IP stack... > > 1. When did they claim that? > 2. I suspect they meant *compatible* stack... there are surely some changes. > 3. The translation of decimals to octets isn't really the "stack" IMHO. I don't think they claim it as such. However, it is believed that they started out with NetBSD and then hacked and slashed and tweaked and slowly but surely DOT was born from the ashes. Check out the standard BSD 'Regents of the University of California' boilerplate in the manuals. There's also an entry for Chris Demetriou and CMU for their work in NetBSD (specifically). This shows the worth of the BSD license over the GPL - if NetApp wanted to, for example, build the same embedded kernel style OS out of Linux, they'd have had to decided whether to make their proprietary code public, giving away competitive advantage at a critical time in their company's life, or to make their code run as application-layer stuff over a trimmed down Linux kernel. Either way wouldn't have been as satisfactory IMHO. Anyway, enough digression. It seems likely that, at least at one time, the network stack owed a great deal to the BSD stack. Whether, in 5.2.* this holds true anymore is only known to NetApp folk. > > Bruce > > >-- End of excerpt from sirbruce(a)ix.netcom.com

2 1

Re: filer NFS to hp700 or alpha: client cache problem?
by Tony Paolucci 18 Mar '99

18 Mar '99

On Wed, 17 Mar 1999, Thomson, Michael (UK, GIS ISM Group for R&D) wrote: > Could I suggest you check the time synchronisation between your client box > (doing the linking) and the Filer? >>> "Todd C. Merrill" <tmerrill(a)mathworks.com> 03/17 10:00 AM >>> All our machines run xntpd, except <*cough*> the filer. ;) I'll try the -noac nfs mount option and/or patches and report back if the problem gets solved. Have you considered setting a cron job to execute rdate on the filer? For example, you could put the following in the crontab of you admin host: 0 3 * * * rsh toaster rdate clock1 This syncs the filer's clock with xntpd server "clock1" every night at 3am. We're doing this and it works pretty well. It ain't xntpd on the filer, but is serviceable for our purposes. -Tony Paolucci System Administrator, Growth Management, Metro, Portland, Oregon

1 0

NetCaches and IP representations
by Alex French 18 Mar '99

18 Mar '99

Here's one for the obscurities wishlist: our NetCaches don't recognise integer representations of IPs. Instead of interpreting 3263497985 as 194.133.7.1, for example, they look for www.3263497985.com. Although nobody in their right mind would want to do this, people do use it when they want to obscure the tru source of a URL (yes, mainly in dodgy newsgroups, I know). Later, Alex.

5 4

RE: NetApp/Auspex killer?
by Weeks, Thomas 18 Mar '99

18 Mar '99

I would probably go with a multi-x86 box (low cost) running Linux (kernel 2.2), SAMBA, hardware RAID, etc. I have seen some very good comparative SMB numbers on these boxes. And now that the processor archetecture is scalable with Linux's kernel, the sky's the limit and the cost is VERY low! Tom Weeks -----Original Message----- From: askaquestion(a)iname.com [mailto:askaquestion@iname.com] Sent: Saturday, March 06, 1999 4:36 PM To: toasters(a)mathworks.com Subject: NetApp/Auspex killer? Yes, NetApps are fine boxes but... If you started a company to build a NAS box, what would you build that would be better than what NetApp, Auspex, etc. has? I'm looking for serious responses here - to improve the market with competition! I don't view the kind of very-low $ suggestions on this list recently as the kind of thing that most of us are interested in. Don't let my anonymous query lead you into thinking that I'm not 100% serious. If anything it should illustrate just how serious I am. --------------------------------------------------- Get free personalized email at http://www.iname.com

4 7

Re: NetCaches and IP representations
by sirbruce＠ix.netcom.com 18 Mar '99

18 Mar '99

On 03/17/99 20:57:20 you wrote: > >On Thu, 18 Mar 1999, Alex French wrote: > >> Here's one for the obscurities wishlist: our NetCaches don't recognise >> integer representations of IPs. Instead of interpreting 3263497985 as >> 194.133.7.1, for example, they look for www.3263497985.com. > >Hmmm... > >That's kinda interesting seeing as I'm sure NetApp claim to be using a BSD >TCP/IP stack... 1. When did they claim that? 2. I suspect they meant *compatible* stack... there are surely some changes. 3. The translation of decimals to octets isn't really the "stack" IMHO. Bruce

1 0

Re: NetCaches and IP representations
by sirbruce＠ix.netcom.com 18 Mar '99

18 Mar '99

On 03/18/99 01:34:50 you wrote: > >Here's one for the obscurities wishlist: our NetCaches don't recognise >integer representations of IPs. Instead of interpreting 3263497985 as >194.133.7.1, for example, they look for www.3263497985.com. > >Although nobody in their right mind would want to do this, people do use it >when they want to obscure the tru source of a URL (yes, mainly in dodgy >newsgroups, I know). Argh!!! I would just like to say I think this is really, really dumb. I've seen more and more people using this "trick" in the past 2 years and it's just annoying as hell. It's just a side-effect of a particular lookup routine! If you check the specs for just about anything (especially URLs) you will see this is *not* guaranteed behavior. If people want and expect this, put it in the standard. Until then, if you find out people have trouble getting the that URL, then that's what you get for using it! The problem is enough lookup routines handle it anyway that the ones that don't look like they are the "non-standard" ones, so now they are forced to adopt this inane behavior. Bruce

1 0

Re: Any comments on emergin SANS technology...
by mds＠gbnet.net 18 Mar '99

18 Mar '99

To an extent filer clusters are SAN's. I personally think NAS is superior to SANs architecturally, even if NAS's use SAN's. One day we'll have a network for network traffic, another for disk traffic, another for backup traffic, another for montoring/maintenance traffic, and some bright spark will come along and say 'We could do all this with one proper network!' and I'll just shake my head and cry. 8)

2 1

Re: Any comments on emergin SANS technology...
by jrg＠acm.org 17 Mar '99

17 Mar '99

On Tue 16 Mar, 1999, mds(a)gbnet.net (mark) wrote: >To an extent filer clusters are SAN's. I personally think NAS is superior >to SANs architecturally, even if NAS's use SAN's. indeedy - the big problem all the plain SAN kit seems to suffer from is that a filesystem belongs to only one of the hosts, can only be intepreted by a subset anyway (eg only NT boxes grok NTFS, only SGI's grok XFS) and doesn't expect to be shared or be sharing with anyone else ('Hey! The link-count on that directory in that local read-only filesystem just changed. Oops.' *BANG*). Enter NFS (or AFS, DFS, Coda..) and systems that are designed to share their filesystems with others. >One day we'll have a network for network traffic, another for disk >traffic, another for backup traffic, another for montoring/maintenance >traffic, and some bright spark will come along and say 'We could do all >this with one proper network!' and I'll just shake my head and cry. > >8) I still say that I don't want to have to worry about lots of different networks! :-p (Or was I arguing to keep them seperate last time? I forget...) James.

1 0

syslog
by Todd C. Merrill 17 Mar '99

17 Mar '99

Is there any way to get syslog to log not only a telnet connection (default): Sun Mar 14 11:45:35 EST [tn_login_0]: Login from host: hostname but also rsh connections and the command that was executed? file:/..../5_2_1-cd/ontap/5_2_1/doc/html/sag/routin12.htm file:/..../5_2_1-cd/ontap/5_2_1/doc/html/man/index.htm Out of the box, there isn't an etc/syslog.conf file, only a sample one. It appears to be logging: *.info /etc/messages at least. What else? I think what I want is: daemon.* /etc/messages But if I create a new syslog.conf file with just those two, what other "default" selectors will I be missing? How do I "kick" ONTAP to start using a new syslog.conf file? "Reboot the filer" is not an acceptable answer. ;) Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

3 3

Fwd: Fw: CIFS directory conversion of NFS created files
by Joan Pearson 17 Mar '99

17 Mar '99

Todd, Directories are converted to CIFS format the first time they are accessed from CIFS. There is no real need to preconvert any directory, but it doesn't hurt. Since snapshots are read-only, directories in snapshots cannot be converted. Access from CIFS to an unconverted directory in a snapshot will get an access denied error, as you have noticed. If NFS creates a directory and it is not accessed by CIFS before the nightly snapshot, that directory is unconverted in the snapshot and will not be accessible from CIFS. The is no "inheritance" of directory type. Directories are always created in non-CIFS format, independent of the type the parent directory. In current releases there is no way force creation of CIFS format directories. In 5.3, there will be an option to force creation of CIFS format directories. There will also be an option to convert a directory to CIFS format even when accessed by NFS. Joan Pearson >From: "Mark Muhlestein" <mmm(a)netapp.com> >To: "Joan Pearson" <jpearson(a)netapp.com> >Subject: Fw: CIFS directory conversion of NFS created files >Date: Wed, 17 Mar 1999 12:32:20 -0800 >X-Mailer: Microsoft Outlook Express 4.72.3155.0 > > >-----Original Message----- >From: Todd C. Merrill <tmerrill(a)mathworks.com> >To: toasters(a)mathworks.com <toasters(a)mathworks.com> >Date: Wednesday, March 17, 1999 10:26 AM >Subject: CIFS directory conversion of NFS created files > > >> >>This from the docs for ontap 5.2.1: >> >>file://....5_2_1-cd/ontap/5_2_1/doc/html/sag/multi5.htm#1180418 >> >>Timing of directory conversion for CIFS access to NFS-created files >> >>[...] >> >>One-time access conversion >> >>If you add CIFS access to files that were created by NFS clients, the >>first time a directory is accessed through CIFS, the filer >>automatically converts it to the format required to support CIFS >>clients. "Accessed" here includes listing the contents of a directory; >>for example, with the File Manager, Explorer, or DOS dir command, or by >>accessing any files or directories contained in that directory. >> >>Under some circumstances, the CIFS client might automatically look at >>the directory's subdirectories, thereby triggering conversion of the >>subdirectories as well. (For example, this happens if the user has set >>the Expand All option under the File Manager Tree menu.) >> >>After a directory is converted, it does not have to be converted >>again. >> >> >> >>Here's my question(s): >> >>I have a directory on the filer root (at the level of etc) called "devel." >>Under that is a tree called "tree." A CIFS share is defined on "tree." >>Under "tree" is a bunch of other directories: >> >>devel/tree/{dir1,dir2,dir3,...dirN} >> >>When I first got the filer, I did a right-click:properties from an NT >>box on all directories dir1,dir2,...dirN in order to force the >>conversion process recursively. Things have been running smoothly. >> >>Until yesterday. The darn "access is denied" error message on the NT >>box is showing up again under the nightly snapshot for this tree on some >>directories. I suspect the directories are new, but have been renamed >>to previously named directories. (I.e., `mkdir new; mv dir old; mv new >>dir; rm -rf old` might have happened from an NFS mount). >> >>Question1: If I create a new directory devel/tree/dirnew and put some >>stuff in it, and no NT box access it before the nightly snapshot, this >>directory will give an "access denied" message to any NT box trying to >>access this directory from the snapshot, right? (I believe the answer >>is "yes" since this seems to jive with empirical data.) >> >>Question2: If I define a share at "devel" and then convert the entire >>*tree* directory, instead of dir1,dir2,...dirN, will any subsequent >>directory created under that tree (at the level devel/tree/dirnew) already >>automatically be converted, since its parent was? (This is kinda like the >>old SunOS subdirectories inheriting the group (?) owner of the parent.) >>(I think the answer is no, from FAQ#486). >> >>Question3: If the answer to #2 is no, is there another way to make this >>happen automagically? It seems reasonable, especially if a share is >>defined on any directory higher in the tree. >> >> Until next time... >> >>Todd C. Merrill >>The Mathworks, Inc. 508-647-7792 >>24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX >>tmerrill(a)mathworks.com http://www.mathworks.com >>--- >> >> >> >

1 0

Re: syslog
by mds＠gbnet.net 17 Mar '99

17 Mar '99

That's a good one, and one I've thought of asking about myself before now. On Wed 17 Mar, 1999, "Todd C. Merrill" <tmerrill(a)mathworks.com> wrote: > > Is there any way to get syslog to log not only a telnet connection (default): <stuff> > > but also rsh connections and the command that was executed? <morestuff>

1 0

RE: syslog
by Hackworth, Brian 17 Mar '99

17 Mar '99

: Is there any way to get syslog to log not only a telnet : connection (default) but also rsh connections and the : command that was executed? The ONTAP rshd does not log successful logins, nor does it log the command that was executed. We're considering this feature for a future release. : Out of the box, there isn't an etc/syslog.conf file, : only a sample one. It appears to be logging: If there's no syslog.conf file, ONTAP uses the equivalent of *.info /dev/console *.info /etc/messages : How do I "kick" ONTAP to start using a new syslog.conf file? : "Reboot the filer" is not an acceptable answer. ;) No action is necessary. ONTAP notices the change and incorporates it automatically. - Brian Hackworth

1 0

CIFS directory conversion of NFS created files
by Todd C. Merrill 17 Mar '99

17 Mar '99

This from the docs for ontap 5.2.1: file://....5_2_1-cd/ontap/5_2_1/doc/html/sag/multi5.htm#1180418 Timing of directory conversion for CIFS access to NFS-created files [...] One-time access conversion If you add CIFS access to files that were created by NFS clients, the first time a directory is accessed through CIFS, the filer automatically converts it to the format required to support CIFS clients. "Accessed" here includes listing the contents of a directory; for example, with the File Manager, Explorer, or DOS dir command, or by accessing any files or directories contained in that directory. Under some circumstances, the CIFS client might automatically look at the directory's subdirectories, thereby triggering conversion of the subdirectories as well. (For example, this happens if the user has set the Expand All option under the File Manager Tree menu.) After a directory is converted, it does not have to be converted again. Here's my question(s): I have a directory on the filer root (at the level of etc) called "devel." Under that is a tree called "tree." A CIFS share is defined on "tree." Under "tree" is a bunch of other directories: devel/tree/{dir1,dir2,dir3,...dirN} When I first got the filer, I did a right-click:properties from an NT box on all directories dir1,dir2,...dirN in order to force the conversion process recursively. Things have been running smoothly. Until yesterday. The darn "access is denied" error message on the NT box is showing up again under the nightly snapshot for this tree on some directories. I suspect the directories are new, but have been renamed to previously named directories. (I.e., `mkdir new; mv dir old; mv new dir; rm -rf old` might have happened from an NFS mount). Question1: If I create a new directory devel/tree/dirnew and put some stuff in it, and no NT box access it before the nightly snapshot, this directory will give an "access denied" message to any NT box trying to access this directory from the snapshot, right? (I believe the answer is "yes" since this seems to jive with empirical data.) Question2: If I define a share at "devel" and then convert the entire *tree* directory, instead of dir1,dir2,...dirN, will any subsequent directory created under that tree (at the level devel/tree/dirnew) already automatically be converted, since its parent was? (This is kinda like the old SunOS subdirectories inheriting the group (?) owner of the parent.) (I think the answer is no, from FAQ#486). Question3: If the answer to #2 is no, is there another way to make this happen automagically? It seems reasonable, especially if a share is defined on any directory higher in the tree. Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

1 0

RE: filer NFS to hp700 or alpha: client cache problem?
by Thomson, Michael (UK, GIS ISM Group for R&D) 17 Mar '99

17 Mar '99

Todd, Could I suggest you check the time synchronisation between your client box (doing the linking) and the Filer? In a previous life I found that 'make' and other tools ignore files if their creation dates are in the 'future', even if it's only a few seconds to a minute. I suspect that might explain why depending on how quickly you run the 'rm', only 2/3 or all the files vanish. Now, all together: "Please can we have Network Time Protocol support on our filer?" Cheers, Mike > -----Original Message----- > From: Todd C. Merrill [SMTP:tmerrill@mathworks.com] > Sent: Tuesday, March 16, 1999 10:43 PM > To: toasters(a)mathworks.com > Subject: filer NFS to hp700 or alpha: client cache problem? > > > We haven't narrowed down the problem entirely yet, but I'd thought I'd > ask anyway.... > > During a linking stage, in linking a bunch of .o files into a library > .a, the linker will grab about 2/3 of the files in a directory into the > archive, and that's it. A subsequent `rm` of *.o sometimes removes only > those exact 2/3 files, sometimes removes all of them, even though the > archive only has 2/3 of them in it. > > It seems as if the directory inode is only showing the oldest 2/3 of the > files, and depending on how long it takes the `ar` and `rm` commands to > execute, removes 2/3 or all of the files. > > I don't suspect it's the filer; watching an `ls` of the directory from > another machine (Solaris) shows all the files there. There are only > about 150 .o files to archive. > > Anyone aware of any client-side NFS caching problems with Alpha or HP700 > boxes? The HP is running HPUX10.20 and appears to be using only NFS V2; > the alpha is running Digital UNIX V4.0D and appears to be using only V3. > (NFS version from `nfsstat -h hostname` on the filer.) The filer is set > nfs.tcp.enable off, NetApp Release 5.2.1. > > Until next time... > > Todd C. Merrill > The Mathworks, Inc. 508-647-7792 > 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX > tmerrill(a)mathworks.com > http://www.mathworks.com > ---

2 1

Backups from DUMP command and snapshots
by Mike Ball 17 Mar '99

17 Mar '99

Questions Please understand I am a novice to the "dump" command when answering the following questions. Thank you for the help! 1) From what I understand running, a full backup with the "dump" command does not backup existing snapshots. Is this correct? 2) It looks like if you want to backup snapshots, you must backup a particular snapshot one at a time. Is this correct? 3) If I do a full restore (if the file system on the filer completely crashed) from a backup created by the "dump" command on the filer, it looks like I must first create the exact qtree structure which was previously on the filer before I can run the full restore. Is this correct?

2 1

filer NFS to hp700 or alpha: client cache problem?
by Todd C. Merrill 17 Mar '99

17 Mar '99

We haven't narrowed down the problem entirely yet, but I'd thought I'd ask anyway.... During a linking stage, in linking a bunch of .o files into a library .a, the linker will grab about 2/3 of the files in a directory into the archive, and that's it. A subsequent `rm` of *.o sometimes removes only those exact 2/3 files, sometimes removes all of them, even though the archive only has 2/3 of them in it. It seems as if the directory inode is only showing the oldest 2/3 of the files, and depending on how long it takes the `ar` and `rm` commands to execute, removes 2/3 or all of the files. I don't suspect it's the filer; watching an `ls` of the directory from another machine (Solaris) shows all the files there. There are only about 150 .o files to archive. Anyone aware of any client-side NFS caching problems with Alpha or HP700 boxes? The HP is running HPUX10.20 and appears to be using only NFS V2; the alpha is running Digital UNIX V4.0D and appears to be using only V3. (NFS version from `nfsstat -h hostname` on the filer.) The filer is set nfs.tcp.enable off, NetApp Release 5.2.1. Until next time... Todd C. Merrill The Mathworks, Inc. 508-647-7792 24 Prime Park Way, Natick, MA 01760-1500 508-647-7012 FAX tmerrill(a)mathworks.com http://www.mathworks.com ---

4 3

RE: Etherchannel (was Re: NetApp/Auspex killer?)
by Mohler, Jeff 16 Mar '99

16 Mar '99

FYI here is what I have on EC on the NA. *heh* <<TRUNKING.html>> > -----Original Message----- > From: Bennett Todd [SMTP:bet@newritz.mordor.net] > Sent: Tuesday, March 16, 1999 11:48 AM > To: tkaczma(a)gryf.net > Cc: toasters(a)mathworks.com > Subject: Etherchannel (was Re: NetApp/Auspex killer?) > > 1999-03-16-02:01:42 Tom: > > Speaking of EtherChannel or more generically Link Aggregation. Does > > anyone know a link describing it in quite a detail without going through > a > > complete protocol suite definition. > > Don't know of a link, would love to see one. But as I understand it, the > general strategy is that very roughly each side separately runs simple > algorithms to attempt to schmeer traffic over the multiple links. Often > the > algorithm is based on the MAC addrs of the two endpoints, and so won't > yield > over 100Mbps for any single link, but will hopefully (3 times out of 4) > place > competing high-volume connections on separate links. > > There are then hacks for failing over to another line when one link drops, > and > other border-condition exotica. > > But the basic idea is that given a large number of communication > endpoints, > you can schmear the traffic over multiple links quite cheaply. > > Dunno if this is any help to you. > > -Bennett

1 0

Re: BDC/NAC issues
by Mark Muhlestein 16 Mar '99

16 Mar '99

Not true. If a BDC the filer is talking to goes away the filer will just attempt to connect with another one. If the "NAC people" are NetApp employees, please let us know who they are so we can give them the correct information. Mark Muhlestein -- mmm(a)netapp.com -----Original Message----- From: Graham C. Knight <grahamk(a)ast.lmco.com> To: toasters(a)mathworks.com <toasters(a)mathworks.com> Date: Tuesday, March 16, 1999 10:13 AM Subject: BDC/NAC issues >Someone just posted this message to just about >every top level manager in our company :-( > >> >> What I am hearing 2nd hand is that NAC people say that the NAC's get locked >> into a BDC for authentication. >> If that BDC goes away or gets renamed that all the NACs will need to be >> removed from server manager, CIFS will have to be reconfigured, and then >> they will have to be added back into the servers Domain. >> >> If this is true then we have no unattended failover capabilities for a BDC >> dying. This could be a significant problem. > > >So - is this true? I don't know enough about NT to comment... > >TIA, > Graham

1 0

BDC/NAC issues
by Graham C. Knight 16 Mar '99

16 Mar '99

Someone just posted this message to just about every top level manager in our company :-( > > What I am hearing 2nd hand is that NAC people say that the NAC's get locked > into a BDC for authentication. > If that BDC goes away or gets renamed that all the NACs will need to be > removed from server manager, CIFS will have to be reconfigured, and then > they will have to be added back into the servers Domain. > > If this is true then we have no unattended failover capabilities for a BDC > dying. This could be a significant problem. So - is this true? I don't know enough about NT to comment... TIA, Graham

1 0

Any comments on emergin SANS technology...
by Christoph Doerbeck A242369 16 Mar '99

16 Mar '99

Just wondering if anyone on the list has an opinion on Storage Array Networks (SANS)... Should NetApp try to develop another product line for SANS based on WAFL? I don't know enough about the underlying technology to make any clever or intelligent comments. - Christoph

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters