Benny Halevy
2010-09-30 18:53:13 UTC
-------- Original Message --------
Subject: Re: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)
Date: Thu, 30 Sep 2010 11:15:10 +0200
From: Benny Halevy <bhalevy at panasas.com>
To: Dean Hildebrand <seattleplus at gmail.com>
CC: nfsv4 at ietf.org <nfsv4 at ietf.org>
1) Section 5.2:
"If data_length is not zero, then the data in the
file from data_offset until data_length is allocated"
should be:
"If data_length is not zero, then the data in the
file from data_offset until data_offset+data_length is allocated"
2) Either way, the client can ignore
the information in READ4reshole.
This sounds too weak. Either the metadata the server return is useful or not.
When data_length is not zero, the server MUST provide the same semantics
for READ4reshole as if the client read the region and received zeroes;
the implied holes contents lifetime MUST be exactly the same as any other read data.
The client MAY use the information in READ4reshole to optimize access
to the server and avoid sending READ requests for the region.
3) Section 5.3:
"when a data server is returning a
READ4reshole structure, it should still contain the offset and length
of the next allocated block in the file, even if that block is not
located on that particular data server."
First, "should" is problematic. Assuming you meant "SHOULD", what
would the DS return in case it doesn't know where the next allocated data region is?
I'd specify this on these lines:
i. If the DS has full knowledge of the allocation state for the whole file
the it SHOULD return the data_offset and data_length of the next allocated
region in the file.
ii. Otherwise, if the next allocated offset is on the same strip unit as the hole, i.e.
it is served by the same DS, then the DS SHOULD return that data_offset, and set
data length to the number of bytes contiguously allocated following data_offset in
this stripe unit.
iii. Otherwise, the DS SHOULD return the data_offset of the next stripe unit and set
data_length to zero.
Benny
Subject: Re: [nfsv4] New version of sparse draft (draft-hildebrand-nfsv4-read-sparse-01.txt)
Date: Thu, 30 Sep 2010 11:15:10 +0200
From: Benny Halevy <bhalevy at panasas.com>
To: Dean Hildebrand <seattleplus at gmail.com>
CC: nfsv4 at ietf.org <nfsv4 at ietf.org>
Hello,
I uploaded a new version of our internet draft "Simple and Efficient Read Support for Sparse Files".
http://www.ietf.org/id/draft-hildebrand-nfsv4-read-sparse-01.txt
Please have a look and give us any feedback.
1) Added section regarding pNFS (which basically states that there are no real changes to how pNFS works)
2) Added example sparse read message flow
3) Added statement to the effect that if a client sends a read request for a chunk that ends in zeroes, the server can return a short read (thanks to Benny)
4) I didn't change the return value. There was a suggestion to use a flag instead of overloaded the length parameter, but I'm not sure what this gives us (although it might be more clear in the doc)
Dean
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
Dean, a few comments:I uploaded a new version of our internet draft "Simple and Efficient Read Support for Sparse Files".
http://www.ietf.org/id/draft-hildebrand-nfsv4-read-sparse-01.txt
Please have a look and give us any feedback.
1) Added section regarding pNFS (which basically states that there are no real changes to how pNFS works)
2) Added example sparse read message flow
3) Added statement to the effect that if a client sends a read request for a chunk that ends in zeroes, the server can return a short read (thanks to Benny)
4) I didn't change the return value. There was a suggestion to use a flag instead of overloaded the length parameter, but I'm not sure what this gives us (although it might be more clear in the doc)
Dean
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4
1) Section 5.2:
"If data_length is not zero, then the data in the
file from data_offset until data_length is allocated"
should be:
"If data_length is not zero, then the data in the
file from data_offset until data_offset+data_length is allocated"
2) Either way, the client can ignore
the information in READ4reshole.
This sounds too weak. Either the metadata the server return is useful or not.
When data_length is not zero, the server MUST provide the same semantics
for READ4reshole as if the client read the region and received zeroes;
the implied holes contents lifetime MUST be exactly the same as any other read data.
The client MAY use the information in READ4reshole to optimize access
to the server and avoid sending READ requests for the region.
3) Section 5.3:
"when a data server is returning a
READ4reshole structure, it should still contain the offset and length
of the next allocated block in the file, even if that block is not
located on that particular data server."
First, "should" is problematic. Assuming you meant "SHOULD", what
would the DS return in case it doesn't know where the next allocated data region is?
I'd specify this on these lines:
i. If the DS has full knowledge of the allocation state for the whole file
the it SHOULD return the data_offset and data_length of the next allocated
region in the file.
ii. Otherwise, if the next allocated offset is on the same strip unit as the hole, i.e.
it is served by the same DS, then the DS SHOULD return that data_offset, and set
data length to the number of bytes contiguously allocated following data_offset in
this stripe unit.
iii. Otherwise, the DS SHOULD return the data_offset of the next stripe unit and set
data_length to zero.
Benny