Subject: Re: [nfsv4] Eliminating stateid's from pnfs IO

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 22 Sep 2005 12:03:33 -0400

On Thu, Sep 22, 2005 at 11:49:33AM -0400, Everhart, Craig wrote:
> I think the proposed requirements are that the clients use the real
> stateids (not e.g. all-ones), and that the data servers provide the
> intended security and lock-conflict semantics.

That makes sense.

> Seems like an overstatement to require data servers support a specific
> protocol to support such semantics.

Noone wants to require a specific protocol, but the language of section
5.4 does seem to requir propagating stateid's specifically, which is
overkill if the data servers can provide the intended semantics some
other way--e.g.  with a combination of sessions information and
preexisting backend lock protocols.

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "Everhart, Craig" <[email-masked]>
Date: Thu, 22 Sep 2005 11:49:33 -0400

I think the proposed requirements are that the clients use the real
stateids (not e.g. all-ones), and that the data servers provide the
intended security and lock-conflict semantics.  Seems like an
overstatement to require data servers support a specific protocol to
support such semantics.

		Craig

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Thursday, September 22, 2005 11:22 AM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] Eliminating stateid's from pnfs IO

On Thu, Sep 22, 2005 at 10:38:01AM -0400, Noveck, Dave wrote:
> > The second problem should also be solveable using sessions: the 
> > session allows the server to determine the client that sent a given 
> > I/O request, thus allowing it to recognize inter-client conflicts.
> I assume that the server being referred to is the data server.

Right, sorry.

> So the data server can recognize conflicts among its clients but 
> conflicts we are worried about are conflicts between a client of a 
> meta-data server, where a lock is done and an IO by a client of data 
> server.

Right.  But some setups (e.g. cluster filesystem backends) already have
some way of handling lock conflicts that would need little if any
modification to handle this case.

> > The current draft's stateid requirement necessitates a 
> > high-performance nfssv4-specific server-to-server protocol, which 
> > seems likely to complicate pNFS implementation.  So it would 
> > obviously be nice if we could eliminate that requirement.
> 
> Right but if the data server is going to be making decisions that 
> require knowledge that the metadata server has, it has to get that 
> knowledge.  Whether that is in the form of stateid or client conflict 
> imformattion, it does have to be propagated to the data servers.

There has to be some sort of propagation, but I'm not convinced it has
to propagate stateid's specifically.  (What I'm complaining about the is
the need for a high-performance *nfsv4-specific* server-to-server
protocol.)

Also, I should have said that it's not the client requirement that's the
problems--clients can use real stateid's easily enough, and if that
helps some implementations, fine--it's the requirement that data servers
check them.

--b.

---

From: Garth Goodson <[email-masked]>
Date: Fri, 23 Sep 2005 09:52:02 -0700

> preexisting backend lock protocols.

Is this the section that causes most grief, if not let me know which is?:

5.2 Global Stateid Requirements

The stateid used for I/O MUST have the same effect and be subject to the 
same validation on storage device as it would if the I/O was being 
performed on the metadata server itself (in the absence of pNFS). This 
has the implication that stateids are globally valid on both the 
metadata and storage devices. This requires the metadata server to 
propagate changes in lock and open state to the data-servers, so that 
the data-servers can validate I/O accesses.

There are some things in section 5.4, but this is more to do with lock, 
open-state, and ACL propagation.  It mentions stateids, but nowhere does 
it explicitly mention stateids must be propagated.  I think we both 
agree that I/Os must have the same effect (in terms of validation) as 
they would on the metadata server, and I think you are saying that this 
can be achieved in ways other than propagating stateids.  If so, I would 
probably be ok with looser language, such as:

I/Os using stateids obtained from the metadata server MUST have the same 
effect, in terms of access, lock, and open state validation.  The 
simplest mechanism to achieve this is through the propagation of 
stateids to the data servers, and the validation thereof; however, other 
mechanisms may exist to ensure the desired effect is obtained.

Note: I'm not willing to say anything about clients enforcing 
intra-client accesses.  That is a discussion you'll have to have with 
the client guys...

-Garth

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 23 Sep 2005 13:43:03 -0400

> the data-servers can validate I/O accesses.

Sorry, yes, that's what I was thinking of.

> mechanisms may exist to ensure the desired effect is obtained.

That might reduce the burden on the server maintainer.

One remaining thing I'm confused about, that effects the requirements on
servers, is whether in 4.0 servers are *required* to use stateid's like
file descriptors: for example, is the server required to use the stateid
when deciding whether to grant access when a mode bit (or acl) change
since the original open has denied access granted by the open?  (E.g.,
an open O_CREAT|O_RDRW with mode bits that deny write is usually made
possible by a server hack that allow the file owner to bypass access
checks; in v4 a server can turn off that hack for accesses that don't
use an appropriate stateid and principal.)

> intra-client accesses.  That is a discussion you'll have to have with 

OK.  I need to catch up on the other threads and think about this some
more, thanks.--b.