headers
Spencer Shepler | 3 Apr 2006 21:57
Picon

NFSv4 conference call agenda -- April 4th at 10am CT


There will be an NFSv4 minor version conference call tomorrow (April 4th).

The conference call numbers are the same as previously. If you need them,
please send me email for the callin information.

Tomorrow I would like to cover the general plan going forward for
document updates and which content will be focused on (schedule essentially).

I would also like to discuss Tom's proposal for sessions use in 4.1
and see if we can draw any remaining issues onto the table and
reach consensus.

Thanks,
Spencer

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 4 Apr 2006 18:46

NFS4ERR_MOVED_DATA_AND_STATE

NFS4ERR_MOVED_WITH_STATE was introduced to solve the problem that a
client has no reliable way to probe a new server to find out whether it
will respect the state that the client got from some old server.

It solves that problem only in one case, though--the case when the
migration is triggered by the server-returned error--and leaves out some
important cases such as failover.

I suppose it's partly for this reason that all the other information
relevant to migration is communicated in attributes, not encoded in
error returns.

Dave Noveck's locations_info proposal would address the problem, though
it's overkill for this case.  Are people still interested in the full
generality of locations_info, or should I propose something smaller?

--b.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Noveck, Dave | 4 Apr 2006 19:16
Picon

RE: NFS4ERR_MOVED_DATA_AND_STATE

I'm in the process of drafting a new chapter on migration,
replication, and referral, and I'm including fs_locations_info,
although pruned a bit.  Also I'm re-organizing things a bit 
to make it a bit easier to understand (I hope).  

I made the decision to go in that direction without a clear 
consensus, with the expectation that we could simplify this
stuff or otherwise alter it as part of the review of the 
v4.1 drafts.  While there was nobody in Dallas loudly chanting 
"We want fs_locations_info and we want it now", there was nobody
arguing against it and a number of people thought it was
needed and asking for extensions (or even more overkill :-).

As I've reviewed what RFC3530 says as part of the process of
drafting, I've become convinced that some sort of locations
info attribute is absolutely required.  That doesn't mean 
that we need everything that has been proposed to be in it,
but as you indicate there is some additional migration/replication
information needed and it makes sense to provide that in an 
attribute.  I'd hope that we can consolidate the information 
and avoid a succession of ad hoc attributes to solve specific
problems.

Anyway, I'd like to understand what your minimum requirement
is and try to see what other people absolutely must have, and
then see if we can create something that includes at least that 
core, plus other things that people believe are nice-to-haves 
without getting too far into the land of overkill. Whether
that's in the form of "this is all that I need that is in 
fs_locations_info" or "here is what I need rather than
(Continue reading)

Permalink | Reply | 752 comments |
headers
J. Bruce Fields | 4 Apr 2006 19:30

Re: NFS4ERR_MOVED_DATA_AND_STATE

On Tue, Apr 04, 2006 at 01:16:34PM -0400, Noveck, Dave wrote:
> I'm in the process of drafting a new chapter on migration,
> replication, and referral, and I'm including fs_locations_info,
> although pruned a bit.  Also I'm re-organizing things a bit 
> to make it a bit easier to understand (I hope).  

OK.  In the interests of simplicity, then, I hope you can just take the
new MOVED error out at the same time locations_info is added, unless
someone can think of a really good reason to have both.

--b.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 4 Apr 2006 19:40

Re: NFS4ERR_MOVED_DATA_AND_STATE

On Tue, Apr 04, 2006 at 01:16:34PM -0400, Noveck, Dave wrote:
> Anyway, I'd like to understand what your minimum requirement
> is and try to see what other people absolutely must have, and
> then see if we can create something that includes at least that 
> core, plus other things that people believe are nice-to-haves 
> without getting too far into the land of overkill.

By the way, I think our minimum requirement is just that both possible
implementations of state migration--one that depends on servers sharing
state, and one that depends on clients reclaiming it--should be
possible.  And that this state sharing shouldn't be tied to other levels
of sharing, such as providing stable filehandles across migration.

(On Linux we just about have the filehandle-sharing non-state-sharing
approach implemented now, albeit scattered in various external patches,
so we expect that approach will mature before we get a mature approach
using state sharing--so this isn't just a theoretical concern.)

The last locations_info proposal I saw looked like it did all this.

--b.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 751 comments |
headers
Black_David | 4 Apr 2006 19:52

RE: Minutes from NFSv4 WG Meetings at IETF65

> Lars noted that either of the Area Directors are are storage guys.

"either" -> "neither" and delete second "are" ;-)

FYI,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Black_David | 4 Apr 2006 20:03

pNFS Callbacks: sizechanged and/or layout recall

> [As I write this, I realize we should have text that explains when the
> CB_SIZECHANGED callback should be used, and when the layout should
> simply be recalled with CB_LAYOUTRECALL.  The current ID says that
> CB_SIZECHANGED is preferred to recalling the layout.  And
> my notes say that the server should do CB_SIZECHANGED before
> responding to a setattr request.  But my dire warnings above indicate
> that a CB_LAYOUTRECALL is more robust.  This may be layout specific.]

I believe the answers are roughly:
- CB_SIZECHANGED: Any client with a layout that will include any bytes
	beyond the new EOF after EOF-related processing (including
LAYOUTRECALL)
	is complete.
- CB_LAYOUTRECALL: Server's discretion.  There are some layout-specific
	cases in which implementation choices will make it essentially
	mandatory (e.g., for the block layout, zeroing the partial block
	beyond new EOF).
There will be cases in which both are required (e.g., move EOF into the
middle of a layout held by a client, and recall just the block that EOF
landed in) - in this case, SIZECHANGED SHOULD come first and a compound
callback encompassing both the size change and recall SHOULD be used to
give the client the maximum "clue" about what's happening. 

Note that SIZECHANGED has layout side effects that need to be documented
in the layout specific drafts (e.g., in the block layout, all data beyond
the new EOF is now invalid - reads return zeros if the file is extended
to include it, and writes need to issue layout commits).

Thanks,
--David
(Continue reading)

Permalink | Reply | 0 comments |
headers
William A.(Andy) Adamson | 4 Apr 2006 21:41
Picon
Favicon

NFSv4 Bakeathon in September at CITI

Mark your calanders! - CITI will host an NFSv4 bakeathon September 11 - 15, 
2006. For those of you who have not attended a CITI NFSv4 bakeathon, see last 
years web page

http://www.citi.umich.edu/projects/nfsv4/citi_bakeathon/12th_nfsv4_bakeathon.ht
ml

for details on location, network, kerberos + ldap services, test suites, etc.
We will post a reminder and a registration web page in June or so.

We are announcing this hosting at this early date because we would like to 
find testing partners for specific features beyond the basic interoperability 
testing that we usually do.

Here is a list of what I think the Linux implementation will be ready to test. 
Any testing partners will be appreciated!

NFSv4.0
	referrals
	spkm3/LIPKEY

NFSv4.1 prototypes:
	directory delegations
	sessions
	pNFS client against Linux/GPFS file layout,  NetApp file layout, pVFS2 
layout, and an EMC block layout.

-->Andy

_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lisa Week | 4 Apr 2006 23:30
Picon

Minutes from Apr. 4, 2006 Conference Call

IETF NFSv4 Working Group Conference Call
April 4, 2006
Note: Action items will be added to the issue tracker 
(http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4).  Attendee list is 
at the end of the minutes.

Agenda:
-----------
    - Discuss the general plan going forward for document updates and 
which content will be focused on.
    - Discuss Tom's proposal for sessions use in 4.1 and see if we can 
draw any remaining issues onto the table and reach consensus.

Agenda additions:
-------------------------
    - None

Minutes:
------------
Document update discussion:

* Goal is to submit a new document every other week.  The I-Ds will be 
published on the off weeks of the WG conference calls.  Spencer will 
work to point out changes between versions of published I-Ds.

* Items to be included in the next version of the 4.1 I-D:
    - Any major sections that haven't been included yet.  For inclusion 
in the next version, Dave Noveck will get sections on Referrals to 
Spencer this week.
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. Bruce Fields | 6 Apr 2006 21:32

simplifying POSIX->NFSv4 ACL mapping

>From thinking about Windows interoperability and our POSIX->NFSv4
mapping, I've noticed some changes to the mapping that might simplify
things quite a bit.

In particular, I'd like to fit most POSIX-mapped ACLs into one of two
subsets:

	- Allow-only ACLs: ACLs without any DENY ACEs at all (except for
	  possibly a DENY at the end to enforce a default-DENY policy)
	- Deny-first ACLs: ACLs that, if they have any DENY ACEs at all,
	  have them all that the start (except for possibly a DENY at
	  the end to enforce a default-DENY policy)

Though the Windows NFSv4/ACL model isn't necessarily complex to
describe, it can be used in complex ways--POSIX-mapped ACLs are a great
example of this.  Unfortunately, this leads to usability problems--for
example, how do you write tools that allow simple operations like "give
user X write permissions to file Y" and that can operate on arbitrary
NFSv4 ACLs?

It would help if by default we produced allow-only (or at least
deny-first) ACLs.  That's also (more or less) what common Windows tools
seem to expect.

Currently the POSIX->NFSv4 mode bit mapping *never* produces allow-only
ACLs, even though in most cases the DENY ACE's it includes are
completely unnecessary.

For example, we're inserting DENY aces after every ALLOW ace in order to
enforce the POSIX first-match semantics.  But those DENY's are
(Continue reading)

Permalink | Reply | 501 comments |

Gmane