From: Boris Zuckerman (boris@nextpoint.com)
Date: 06/12/98-05:10:51 PM Z
Message-ID: <01BD962D.6FA040F0@bnext> From: Boris Zuckerman <boris@nextpoint.com> Subject: RE: metadata Date: Fri, 12 Jun 1998 18:10:51 -0400 We have to define a GENERIC protocol that reflects the requirements of a 'modern' file system. All servers should implement all functions of this protocol. We should leave behind some features of older file systems, but allow and may be even define extensions for matching client/server environments. [Boris Zuckerman] > > > > > It is my opinion that NFS would benefit from a _separate_ metadata > > > protocol which could be negotiated between the client and server. > > > The rudimentary start towards such a protocol can be found at > > > http://www.york.ac.uk/~mrw103/nfsmdt.txt. What do other people think? > > > > > The NFS_METADATA protocol makes sense for v2 and v3 clients that > > need access to non-POSIX attributes, but what advantage is there > > in making NFS v4 blind to metadata (requiring a separate protocol) ? > > > > Why not use a separate protocol to manage metadata? What inherent > reason is there to have one large monolithic protocol? > > > NFS has taken the correct approach in resisting the temptation > > to reveal characteristics of the underlying filesystem, i.e. protocol > > designer disengages brain and builds a protocol that supports many > > filesystems each with their own pathnames, attributes and semantics > > leaving the poor implementor to build something that has to work with any > > of several different models. Let's not build a Balkanized protocol! > > > > For instance, if Unix and NT filesystems both have a notion of > > file "size" measured in bytes, then lets have a common "size" > > attribute (as is supported now in v2 and v3). > > > > I think that you may find that there isn't all that much in common. > A lot of the file attributes, fattr or fattr3, are very UNIX specific. > The PC implementations have had to resort to emulating the fields > which they couldn't really support. This includes things like uid, uid, > mode, link count, etc. > > > However, if there's a *unique* attribute that's supported by one > > filesystem but not others then it's reasonable that the protocol > > should support it, e.g. Windows NT has an "archive" bit - Unix > > does not. > > > > I think most of us would agree that NFS needs to support > > a richer set of attributes than the current POSIX set and I do > > think the client should be able to determine which attributes the > > server supports (as in NFSMETADATA_CAPABILITIES). > > > > > If it can be done without too much extra complexity, why not have > the servers support what the clients need? Why handicap the clients > because the server doesn't support what the client needed? > > ps
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:49 AM Z CST