On Oct 29, 2013, at 9:24 AM, Hellwig Christoph <hch@xxxxxxxxxxxxx> wrote:
> On Tue, Oct 29, 2013 at 01:21:26PM +0000, Myklebust, Trond wrote:
>> The current draft spec even allows the client to specify a "pattern" to be written to the "hole".
>
> That's indeed the WRITE SAME lookalike then. At least the SCSI people
> were smart enough to define an unmap bit for "hole punching" and allow
> the target to reject all other versions if they don't want to support
> it.
>
> Given that NFS v4.2 isn't finalized I'd very much recommend to
>
> a) properly separate those case s
> b) do not make the async version mandatory
union write_plus_arg4 switch (data_content4 wpa_content) {
case NFS4_CONTENT_DATA:
data4 wpa_data;
case NFS4_CONTENT_APP_DATA_HOLE:
app_data_hole4 wpa_adh;
case NFS4_CONTENT_HOLE:
data_info4 wpa_hole;
default:
void;
};
I suppose we could add cases: NFS4_CONTENT_APP_DATA_HOLE_SYNC, NFS4_CONTENT_HOLE_SYNC to allow the client to specify that it doesn't want asynchronous behaviour (and add error cases to allow the server to specify that it cannot safely do so).
There is already a 'di_allocated' boolean for the NFS4_CONTENT_HOLE case (which is used to distinguish between holes and zeroed extents). The only thing missing there is an error case, AFAICS, to allow the server to return that it doesn't support holes.
Tom, any thoughts on whether or not this kind of change to the spec is doable at this time?
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
