Subject: [nfsv4] stateids for SEEK, ALLOCATE and DEALLOCATE

From: Christoph Hellwig <[email-masked]>
Date: Mon, 27 Apr 2015 15:31:29 +0200

Currently the 4.2 draft only speciefies the stateid requirements
for READ, COPY and CLONE by referring to the rules for READ and WRITE,
but it does not specify any rules for SEEK, ALLOCATE and DEALLOCATE.

It seems natural to refer to the WRITE or SEATTATR with size changes
for ALLOCATE and DEALLOCATE, but I'm not sure what we should do for
SEEK.  In fact I'm not even sure SEEK should have a stateid argument
at all when I think about it.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 27 Apr 2015 09:41:11 -0400

> at all when I think about it.

I suppose whatever arguments justify a stateid argument to READ should
apply to SEEK(SEEK_HOLE|SEEK_DATA) as well as they're returning some
(limited) information about a range of file data.

--b.

---

From: Trond Myklebust <[email-masked]>
Date: Mon, 27 Apr 2015 10:42:34 -0400

> (limited) information about a range of file data.

Agreed. If your share locks contain a DENY_READ, or you have a
mandatory byte range lock preventing reads, then surely you should not
be able to determine data/hole information either.

Cheers
  Trond