![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Hi David -
I would prefer not to do this. It's fairly easy to make a mistake in this environment that has the client looking in the wrong place for the volume identification, risking a false positive, and unpleasant results. Beyond this, removing the requirement that server and client have the same understanding of the disk size may create situations in which different clients have different ideas of the disk size; that seems like needless complexity, so all clients need to have the sameunderstanding of disk size, and adding the server to that understandingis a small and reasonable step in pursuit of robustness.
I don't have a strong opinion on whether you add full support for negative disk offsets despite potential implementation difficulties, or whether you prohibit such support in order to avoid implementation bugs. Personally, I would go for the former option -- and add text that warns about related implementation challenges. But I won't complain if you choose the latter option, of course.
As Hannes has already pointed out, there's quite a bit of crash detection and recovery material in the main NFSv4.1 draft, including descriptions of how to recover layouts in general (layouts are among the resources that a client can reclaim during a grace period after server restart). Hence this draft only adds material specific to the block/volume layout. We'll add a sentence or two in order to explain this and point to the material in the main NFSv4.1 draft.
Right, a reference to the document that contains the necessary background
information is all that's necessary here.
We'll expand the first uses of the four acronyms.
Perfect. - Christian _______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.