This patchset is just about ready to go upstream. Just need to write a couple tests (familiar refrain eh?:)). These changes add a new Get-Partial-Object (GET_PART) chunkd operation. GET_PART permits partial retrieval of an object, by adding an (offset,length) pair to the standard Get-Object (GET) operation. length==0 is special-cased as meaning "retrieve until end of object." The maximum number of bytes that may be requested in a single GET_PART request is 4 x 64k blocks (256k). Larger lengths will be truncated down to the maximum. Because we currently only store whole-object SHA1 checksums, we are left without an ability to verify on-disk data is valid, when retrieving a subset of an object. Thus, a necessary pre-req of GET_PART is changing the checksum scheme, which is done as follows: * objects are defined as runs of 64k logical blocks * checksums are stored on-disk for each 64k in an object * Rather than returning the stored SHA1 checksum, which serves to verify both on-disk and network integrity, we break this into two steps, * verify per-64k checksums at GET_PART time * generate on-the-fly SHA1 checksum for GET_PART returned data The chunkd network protocol supports any offset/length, including not-64k-aligned values. However, failure to align GET_PART requests on 64k boundaries will result in reduced performance, due to additional work chunkd must perform [and then throw away], because chunkd now works in 64k chunks internally. This is a major protocol milestone, and should immediately enable sane usage by nfs4d and itd (see wiki if unfamiliar), as well as hopefully providing useful benefits to tabled as well. -- To unsubscribe from this list: send the line "unsubscribe hail-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
