Subject: Re: [nfsv4] draft notes from pNFS meeting held in Vancouver

From: "Suchit Kaura" <[email-masked]>
Date: Thu, 6 Dec 2007 14:10:02 -0800

I agree with Garth. The proposal from Anatoly provided earlier does
resolve this as it has offset and length for the layout followed by the
various layouts the range has correspondence too.
 
Also, the current model will duplicate the io_mode field in each layout4
member that does not seem very logical.
 
Regards,
Suchit
 
I think you are assuming that the offset in each layout4 structure is
always the beginning offset for that layout -- this means that if I have
a layout covering say 0-0x80000 then I can't give a layout4 structure
covering just 0x40000-0x80000 since there is no way for the client to
know where the layout really started. I think we need this flexibility;
that is if I'm right about this.

-Garth

Mike Eisler wrote: 

		Anatoly/Suchit: We will produce a proposal. 

	I met with Anatoly and Suchit after the WG meeting today.

	All three of us came to the conclusion (though Anatoly wants to
	do some test cases) that the existing results in LAYOUTGET
	are sufficient for calculating the relative offset. 

	Cutting and pasting Anatoly's example which kicked off the DENSE
	packing issue:

	struct nfsv4_1_file_layout_ds_addr4
	dev0 = { // ID is 0
	{0},
	{{A}}
	},
	dev1 = { // ID is 1
	{0},
	{{B}}
	};
	File Layouts for a client file
	struct nfsv4_1_file_layout4
	fl0 = {
	0,
	x, // stripe unit size of 0x400 is coded with x
	0,
	fh0
	},
	fl1 = {
	1,
	y, // stripe unit size of 0x1000 and dense packing are coded
with y
	0,
	fh1
	};
	fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400,
	0x1400-1];
	Now a client requests layout for an offset of 0x800 and length
0x400
	and the reply is:
	struct layout4
	lo = {
	0x800,
	0x400,
	lo_iomode, // some IO mode
	lo_content // see below
	};
	struct layout_content4
	lo_content = {
	LAYOUT4_NFSV4_1_FILES,
	loc_body // see below
	};
	loc_body contains fl1 defined above.
	So, the client knows the server (B) and the file handle (fh1) to
do IO
	on. Offset for the fh1 is needed as well. The formula from
paragraph
	14.5 does not provide correct offset since
	data_file_offset = floor(file_offset / stripe_width)
	* stripe_unit_size + file_offset % stripe_unit_size =
	floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800;
	and the correct offset is
	
	rel_offset = (file_offset - layout_offset) = (0x800 - 0x400) =
0x400;
	data_file_offset = floor(rel_offset / stripe_width)
	* stripe_unit_size + rel_offset % stripe_unit_size =
	floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400;
	Offset of first byte the layout is applicable to (layout_offset
=
	0x400) is used in the calculation of the data file offset.
Therefore,
	it should be stored in the nfsv4_1_file_layout4 structure
returned to
	the client.

	The layout_offset is available in results from LAYOUTGET.
	So the spec needs to be updated to reflect proper calculation.

	Have we missed anything?

	--------------

		Sparse and Dense

		Garth - Needs to clear that that if two layout ranges
		on a file have two different device IDs, the ranges are
		not mergeable.

		Trond: If you can't merge layout ranges, you can't
append
		(mre: huh?)

		Brent: 3 choices
		  - when you add devices to your device set, you have to
		    recall the layout
		  - fix the math with dense
		  - throw out dense

		Mike: Having different striping patterns for different
		ranges of a file is an absolute requirement. Cannot
require
		the entire file to be re-striped when new devices come
		online in order to benefit from those devices.

		Brent: I don't really have a stake in this, since it is
a file
		layout issue.

		Mike: What happens if Panasas adds an NFSv4.1 wrapper to
its data
		server>

		Brent: OK, in that case, since objects uses dense, it
		would be much better if I give a file and object layout
		that they both use the same packing. So I would prefer
		DENSE be supported.

		Rough consensus is that DENSE is needed.

		Mike: A simple proposal is desired. The proposal Anatoly
		emailed to the nfsv4 at ietf.org on November 28, 2007
looked
		complex.

		Anatoly/Suchit: We will produce a proposal. 

	_______________________________________________
	nfsv4 mailing list
	nfsv4 at ietf.org
	https://www1.ietf.org/mailman/listinfo/nfsv4

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

---

From: "Anatoly Pinchuk" <[email-masked]>
Date: Thu, 6 Dec 2007 17:21:15 -0800

Let us distinguish three things

-        reply for LAYOUTGETREQUEST (currently it is the
LAYOUTGET4resok)

-        generic layout   (currently it is array of layout type
independent parts of layout4)

-        type specific layout (currently it is array of layout type
dependent parts of layout4 which is layout_content4).

Now, if we say that layout type independent semantic of the LAYOUTGET is
to return ONE IO mode and mapping for ONE client's sub-range given IO
mode and the range, it seems logical to return just ONE generic layout
(generic part of layout4). Because of that, only ONE layout_content4
structure is returned as well. Doing so allows avoiding unnecessary
repetitions of loc_type and io_mode fields with the same value. Thus
structure of  LAYOUTGET4resok becomes logically simpler and more
compact. Finally, layout specific part of the LAYOUTGET4resok should be
an array and reside in loc_body field of  layout_content4 structure.
That field is to store collection of the file layout items based on
different striping patterns and representing client file segments. I
already mentioned such layering in my previous posting on the file
layout issues. As we agreed on, I will simplify the proposed solution
soon.

- Anatoly