From: ampass (ampass@ftp.com)
Date: 12/03/98-02:50:52 PM Z
Message-ID: <3666F9AC.7B931A2D@ftp.com>
Date: Thu, 03 Dec 1998 15:50:52 -0500
From: ampass <ampass@ftp.com>
Subject: Re: NFS V4 attributes proposal
Mike Eisler wrote:
>
> > On Sun Nov 29 23:34:11 1998, Robert Thurlow wrote:
> > >
> > > The set of attributes which are classified as mandatory is
> > > deliberately
> > > small, since servers must do whatever it takes to support them. The
> > > recommended attributes may be unsupported, though a server should
> > > support
> > > as many as it can. Attributes are deemed mandatory if the data is
> > > both
> > > needed by a large number of clients and is not otherwise reasonably
> > > computable by the client when support is not provided on the server.
> > >
> >
> > I have a problem with the idea of unsupported attributes. If an
> > operating system client needs an attribute like modification time
> > (for example) and the server cannot supply it, what should the client
> > do? What will Unix do? What value will be returned in the stat() call?
>
> For the client, what it can do is cache its own mtime (faking a value
> that would be equal to current time of day when the file is opened
> for the first time).
>
> If the client needs a way to see if his cached file data is out of date,
> then it can rely on the mandatory "change" attribute. If it issues
> a GETATTR { change } request, and finds that the new value
> is different from the cached value, then it artificially bump up the
> faked mtime.
>
> Turn it around. If a server doesn't have the attribute available, what should
> it do if the it is a MUST to support? I can envision an algorithm, and it
> looks fairly complex, and not as robust as a client centric mtime similation.
>
> Each attribute needs to be looked at one by one to see if a reasonable
> simulation is best done by the server or the client.
>
> > Now since there are many different client implementations which need
> > modification time how do we mandate the view of the server that the
> > clients will present?
> >
> > To provide a uniform view it would make more sense for the server to
> > simulate the modification time. This goes for all attributes that are
> > on an operating system level.
>
> Which operating systems?
>
> -mre
I'd say that declaring the attribute already presenting in nfs2/3
protocols (like mtime)
as optional creates unnecessary difficulties for a client, while the
server have already resolve
the issue (somehow). I'd propose to declare such an attribute as
mandatory unless there is
no strong reason to do otherwise.
Sasha
This archive was generated by hypermail 2.1.2 : 03/04/05-01:46:36 AM Z CST