From: Boris Z. (boris@conley.com)
Date: 09/24/98-03:19:54 PM Z
Message-ID: <01BDE7BE.0561CD20.boris@conley.com> From: "Boris Z." <boris@conley.com> Subject: RE: locking errors Date: Thu, 24 Sep 1998 13:19:54 -0700 There is a truce in both positions. 1) We definitely want to have a protocol suitable for building a 'turn key implementations' capable of running without any management interventions. 2) The protocol can define SNMP type of MIBs for getting some statistics out of the servers and resetting some performance related parameters (lease TMO, # of open files, # of connections, etc.) Boris. On Thursday, September 24, 1998 9:35 AM, Carl Beame [SMTP:beame@mail1.tinet.ie] wrote: > On Wed Sep 23 22:45:26 1998, Brent Callaghan wrote: > > > > > If the client never talks to the specific server again, the lock > > > remains until the administrator uses the VERY useful tools to > > > either > > > close the file or disconnect the client. Both the client and the > > > actual file and locks are displayed by the tools. The idle time > > > of the client is also displayed. > > > > > > Just as an aside here, should we not have some procedures which > >will > > > allow similar management utilities? FILE_HANDLE_TO_FILE_NAME, > > > DUMP_LOCK_TABLE? > > > > > > I think we should make every effort to avoid management utilities. > > The notion of a box of disks that's connected to the network, > > gathers dust, and is "administered" by the receptionist is > > a very attractive one. The NFS v4 server administrators > > manual should be very thin - or non-existent. > > > ** FLAME ON ** > I think this is a very narrow and simplistic view! > ** FLAME OFF ** > > I have been in the Personal Computer NFS business since 1989 and I > have won big deals away from Sun Microsystems by the simple fact that our > company wanted NFS to compete against Novell and Microsoft Networking > while Sun simply stated that NFS was an access method for their > servers. > > To complete against other networking platforms we must provide the > consumer/user with what they want. And they want management! They > want to be able to remotely manage their disk and print servers. I am > sure that some Unix or specialized NFS server companies can make money > selling remotely manageable servers, but the idea with NFS is that we > can operate in a heterogeneous environment. Thus we need standardized > remote calls which will allow for the management of a network > full of varied NFS servers. > > The calls above may look like debug calls, but they provide useful > information to a SYSTEM ADMINISTRATOR remotely! > > - Carl
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:18 AM Z CST