headers
Todd Pisek | 1 Dec 2005 21:49
Picon

pNFS -layouts and byte ranges

I have a couple of questions:

1 - The pNFS draft refers to layouts and layout segments.
    If I understand correctly, a layout segment is a byte
    range within a file layout. Am I correct in assuming
    that LAYOUTGET specifies a layout range?

2 - Are layout segments recalled for range splitting?

3 - Does a layout segment carry an implicit byte range
    delegation (as opposed to a byte range lock)?

4 - How is byte range locking enforced by object/block
    data servers?

--- Todd

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 9 comments |
headers
Garth Goodson | 1 Dec 2005 22:33
Picon

Re: pNFS -layouts and byte ranges

Todd Pisek wrote:
> I have a couple of questions:
> 
> 1 - The pNFS draft refers to layouts and layout segments.
>     If I understand correctly, a layout segment is a byte
>     range within a file layout. Am I correct in assuming
>     that LAYOUTGET specifies a layout range?
> 
Correct.  LAYOUTGET specifies a byte range.

> 2 - Are layout segments recalled for range splitting?
> 
Not sure what you mean exactly by "range splitting", but recalls can be 
done for file ranges.  These file ranges need not match the ranges 
returned by LAYOUTGET.  They can either span or sub-divide layout 
segments held by clients.  Note: layout segment is just terminology for 
a byte range within a layout.  A client may hold a layout that is 
comprised of multiple sets of byte-ranges gotten through separate 
LAYOUTGETs.

> 3 - Does a layout segment carry an implicit byte range
>     delegation (as opposed to a byte range lock)?
> 
NO.  Delegations and locks are separate from layouts (at least to the 
extent possible as determined by the layout type).  E.g., for file 
layouts they are totally separate.  Also note, that byte range 
delegations don't currently exist.  Trond has proposed them, but they 
are not part of pNFS.

> 4 - How is byte range locking enforced by object/block
(Continue reading)

Permalink | Reply | 8 comments |
headers
Garth Goodson | 2 Dec 2005 00:41
Picon

Re: pNFS -layouts and byte ranges


Todd Pisek wrote:
> Garth Goodson wrote On 12/01/05 03:33 PM,:
> 
>>Todd Pisek wrote:
>>
> 
> :
> :
> 
>>>4 - How is byte range locking enforced by object/block
>>>   data servers?
>>>
>>
>>Check with the corresponding specs.  Objects will use capabilities to 
>>enforce mandatory locks.  Blocks can tie byte-ranged locks to layouts. 
>>Note: only mandatory locks need be enforced at the data server.
>>
> 
> 
> When you refer to "mandatory locks", is this synonymous with LOCK?
> I thought the only operations between a client and the data servers
> was READ, WRITE, COMMIT, and NULL. Is there an implied operation between
> the metadata server and the data servers for the LOCK operation?
> 
All metadata ops go to the metadata server.  However, mandatory locks 
must be respected on the data server even though there is no client call 
to that data server.  Thus, there is a need for a back-end control 
protocol between metadata and data servers.  Data servers do not accept 
LOCK operations from the client.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Brent Welch | 2 Dec 2005 02:39
X-Face
Favicon

Re: pNFS -layouts and byte ranges

The capability will be an opaque sent from the metadata server.
Ideally it will be encyrpted using the GSS context that the
client has established with the server, but I'm not sure the
best way to spec that yet.

>>>Garth Goodson said:
 > 
 > 
 > 
 > Todd Pisek wrote:
 > > Garth Goodson wrote On 12/01/05 03:33 PM,:
 > > 
 > >>Todd Pisek wrote:
 > >>
 > > 
 > > :
 > > :
 > > 
 > >>>4 - How is byte range locking enforced by object/block
 > >>>   data servers?
 > >>>
 > >>
 > >>Check with the corresponding specs.  Objects will use capabilities to 
 > >>enforce mandatory locks.  Blocks can tie byte-ranged locks to layouts. 
 > >>Note: only mandatory locks need be enforced at the data server.
 > >>
 > > 
 > > 
 > > When you refer to "mandatory locks", is this synonymous with LOCK?
 > > I thought the only operations between a client and the data servers
(Continue reading)

Permalink | Reply | 0 comments |
headers
Todd Pisek | 2 Dec 2005 00:35
Picon

Re: pNFS -layouts and byte ranges

Garth Goodson wrote On 12/01/05 03:33 PM,:
> Todd Pisek wrote:
> 
:
:
> 
>>4 - How is byte range locking enforced by object/block
>>    data servers?
>>
> 
> Check with the corresponding specs.  Objects will use capabilities to 
> enforce mandatory locks.  Blocks can tie byte-ranged locks to layouts. 
> Note: only mandatory locks need be enforced at the data server.
> 

When you refer to "mandatory locks", is this synonymous with LOCK?
I thought the only operations between a client and the data servers
was READ, WRITE, COMMIT, and NULL. Is there an implied operation between
the metadata server and the data servers for the LOCK operation?

For OSD data servers, how are the capabilities for the data servers
conveyed to the client?

--- Todd

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
(Continue reading)

Permalink | Reply | 7 comments |
headers
Halevy, Benny | 2 Dec 2005 19:11
Favicon

pnfs last write offset

draft-ietf-nfsv4-pnfs-00.txt says:
   The "last_write_offset" field specifies the offset of the last byte
   written by the client previous to the LAYOUTCOMMIT.  Note: this value
   is never equal to the file's size (at most it is one byte less than
   the file's size).  The metadata server may use this information to
   determine whether the file's size needs to be updated.  If the
   metadata server updates the file's size as the result of the
   LAYOUTCOMMIT operation, it must return the new size as part of the
   results.

What should the client set this to if it never wrote to the file
and issues LAYOUTCOMMIT e.g. to free up provisionally allocated
blocks?

A last_write_offset value of 0 means that the file has 1 byte written
to it so maybe last_write_offset should be of type newsize4 rather than
length4.

Benny

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 0 comments |
headers
Noveck, Dave | 2 Dec 2005 19:32
Picon

RE: pnfs last write offset

Or maybe we want the field to be one byte beyond the offset of 
the last byte you wrote.

Maybe this would be a problem if you are writing a byte at offset
0xffffffffffffffff but if you did the size of the file wouldn't
be representable in v4 anyway.

-----Original Message-----
From: Halevy, Benny [mailto:bhalevy <at> panasas.com] 
Sent: Friday, December 02, 2005 1:11 PM
To: Goodson, Garth; Welch, Brent; Zelenka, Jim; 'David Black' (E-mail)
Cc: 'nfsv4 <at> ietf.org'
Subject: [nfsv4] pnfs last write offset

draft-ietf-nfsv4-pnfs-00.txt says:
   The "last_write_offset" field specifies the offset of the last byte
   written by the client previous to the LAYOUTCOMMIT.  Note: this value
   is never equal to the file's size (at most it is one byte less than
   the file's size).  The metadata server may use this information to
   determine whether the file's size needs to be updated.  If the
   metadata server updates the file's size as the result of the
   LAYOUTCOMMIT operation, it must return the new size as part of the
   results.

What should the client set this to if it never wrote to the file
and issues LAYOUTCOMMIT e.g. to free up provisionally allocated
blocks?

A last_write_offset value of 0 means that the file has 1 byte written
to it so maybe last_write_offset should be of type newsize4 rather than
(Continue reading)

Permalink | Reply | 2 comments |
headers
Halevy, Benny | 2 Dec 2005 19:39
Favicon

RE: pnfs last write offset

I'm fine with that too.

I think that the field was defined as such to stress the
fact that the client is not setting the file's length but
rather it's just reporting what's the highest offset it
wrote to and server should determine the new length
of the file based on these reports and possibly other
information it has about the file.

If we're going the way you proposed than the client
is sending its local notion of the file size, hence the
field should be named accordingly: e.g. local_file_size.

Benny

> -----Original Message-----
> From: Noveck, Dave [mailto:Dave.Noveck <at> netapp.com]
> Sent: Friday, December 02, 2005 8:32 PM
> To: Halevy, Benny; Goodson, Garth; Welch, Brent; Zelenka, Jim; 'David
> Black' (E-mail)
> Cc: nfsv4 <at> ietf.org
> Subject: RE: [nfsv4] pnfs last write offset
> 
> 
> Or maybe we want the field to be one byte beyond the offset of 
> the last byte you wrote.
> 
> Maybe this would be a problem if you are writing a byte at offset
> 0xffffffffffffffff but if you did the size of the file wouldn't
> be representable in v4 anyway.
(Continue reading)

Permalink | Reply | 3 comments |
headers
J. Bruce Fields | 2 Dec 2005 20:14

Re: pnfs last write offset

On Fri, Dec 02, 2005 at 01:39:56PM -0500, Halevy, Benny wrote:
> I think that the field was defined as such to stress the
> fact that the client is not setting the file's length but
> rather it's just reporting what's the highest offset it
> wrote to and server should determine the new length
> of the file based on these reports and possibly other
> information it has about the file.

Right.

> If we're going the way you proposed than the client
> is sending its local notion of the file size, hence the
> field should be named accordingly: e.g. local_file_size.

I'd probably assume that the client's "local notion of the file size"
refers to what it currently thinks the file size is--maybe whatever it
cached from its most recent getattr request.

But it's true that the field would be more obviously one and not
zero-based if it was described as a length or size instead of an offset.
The special interpretation of zero would be obvious then too.  How about
"total_write_size"?

For text, you could use something like:

	The "total_write_size" field gives the length of the initial
	segment of the file containing all the bytes this client has
	written previous to the LAYOUTCOMMIT.  Thus this field is zero
	if and only if the client has not written to the file, and in
	the case where the client's writes are the only factor
(Continue reading)

Permalink | Reply | 0 comments |
headers
Garth Goodson | 2 Dec 2005 20:13
Picon

Re: pnfs last write offset

Halevy, Benny wrote:
> I'm fine with that too.
> 
> I think that the field was defined as such to stress the
> fact that the client is not setting the file's length but
> rather it's just reporting what's the highest offset it
> wrote to and server should determine the new length
> of the file based on these reports and possibly other
> information it has about the file.

Exactly, and I really like this way of having the client report to the 
server what it wrote.

> 
> If we're going the way you proposed than the client
> is sending its local notion of the file size, hence the
> field should be named accordingly: e.g. local_file_size.
> 
I think we should think carefully before doing this.

I'm also not convinced that this field can be soley used for free space 
reclaimation as it does not give enough information back.  It only gives 
an offset, it does not tell where holes are etc.  I think that an 
appropriate layoutupdate structure may be better at conveying this 
information (especially in the blocks world).

But we should make the spec clear on this point.

-Garth
(Continue reading)

Permalink | Reply | 0 comments |

Gmane