On Fri, Apr 04, 2014 at 04:20:41PM +0100, Filipe David Borba Manana wrote:
> @@ -4307,6 +4348,22 @@ out:
> return num_read;
> }
>
> +static int send_total_data_size(struct send_ctx *sctx, u64 data_size)
> +{
> + int ret;
> +
> + ret = begin_cmd(sctx, BTRFS_SEND_C_TOTAL_DATA_SIZE);
> + if (ret < 0)
> + goto out;
> +
> + TLV_PUT_U64(sctx, BTRFS_SEND_A_SIZE, data_size);
> + ret = send_cmd(sctx);
> +
> +tlv_put_failure:
> +out:
> + return ret;
> +}
> +
> /*
> * Send a clone command to user space.
> */
> --- a/fs/btrfs/send.h
> +++ b/fs/btrfs/send.h
> @@ -87,6 +87,7 @@ enum btrfs_send_cmd {
>
> BTRFS_SEND_C_END,
> BTRFS_SEND_C_UPDATE_EXTENT,
> + BTRFS_SEND_C_TOTAL_DATA_SIZE,
Though it is a simple modification, it changes the existing send
protocol.
The unpatched receiver would fail (it has a lower value of
__BTRFS_SEND_C_MAX), so it could work even without revving the protocol.
But, it's not the cleanest way.
There's a number of defficiencies found in v1 protocol, see
https://btrfs.wiki.kernel.org/index.php/Design_notes_on_Send/Receive#Send_stream_v2_draft
I would rather see a proper v2 revision instead of relying on the fact
that current implementation will deal with the change.
> __BTRFS_SEND_C_MAX,
> };
> #define BTRFS_SEND_C_MAX (__BTRFS_SEND_C_MAX - 1)
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
