On Fri, Jan 14, 2011 at 04:44:27PM +0000, owen.smith@xxxxxxxxxx wrote:
> From: Owen Smith <owen.smith@xxxxxxxxxx>
>
> Patches xen.git, on branch xen/next-2.6.32
>
> Trim operation is a request for the underlying block device to mark
> extents to be erased. Add the operation code and ring data structure
> to the interface, and a stub response to the blkback device.
>
> Trim operations are passed with sector_number as the sector index to
> begin trim operations at and nr_sectors as the number of sectors to
> be trimmed. The specified sectors should be trimmed if the underlying
> block device supports trim operations, or a BLKIF_RSP_EOPNOTSUPP should
Ok, so this code just returns EOPNOTSUPP. Is there a forthcomming patch for
supporting the trim operation?
> be returned. More information about trim operations at;
> http://t13.org/Documents/UploadedDocuments/docs2008/
> e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
>
> Signed-off-by: Owen Smith <owen.smith@xxxxxxxxxx>
> ---
> drivers/xen/blkback/blkback.c | 7 +++++++
> include/xen/interface/io/blkif.h | 17 +++++++++++++++++
> 2 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/xen/blkback/blkback.c b/drivers/xen/blkback/blkback.c
> index b45b21f..03cb8f6 100644
> --- a/drivers/xen/blkback/blkback.c
> +++ b/drivers/xen/blkback/blkback.c
> @@ -367,6 +367,13 @@ static int do_block_io_op(blkif_t *blkif)
> blkif->st_wr_req++;
> dispatch_rw_block_io(blkif, &req, pending_req);
> break;
> + case BLKIF_OP_TRIM:
> + /* respond with BLKIF_RSP_EOPNOTSUPP to reduce logging
> + * from default case */
> + make_response(blkif, req.id, req.operation,
> + BLKIF_RSP_EOPNOTSUPP);
> + free_req(pending_req);
> + break;
> default:
> /* A good sign something is wrong: sleep for a while to
> * avoid excessive CPU consumption by a bad guest. */
> diff --git a/include/xen/interface/io/blkif.h
> b/include/xen/interface/io/blkif.h
> index 61e523a..2ae8840 100644
> --- a/include/xen/interface/io/blkif.h
> +++ b/include/xen/interface/io/blkif.h
> @@ -43,6 +43,17 @@ typedef uint64_t blkif_sector_t;
> * create the "feature-barrier" node!
> */
> #define BLKIF_OP_WRITE_BARRIER 2
> +/*
> + * Recognised only if "feature-trim" is present in backend xenbus info.
> + * The "feature-trim" node contains a boolean indicating whether barrier
> + * requests are likely to succeed or fail. Either way, a trim request
> + * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by
> + * the underlying block-device hardware. The boolean simply indicates whether
> + * or not it is worthwhile for the frontend to attempt trim requests.
> + * If a backend does not recognise BLKIF_OP_TRIM, it should *not*
> + * create the "feature-trim" node!
> + */
> +#define BLKIF_OP_TRIM 5
>
> /*
> * Maximum scatter/gather segments per request.
> @@ -61,6 +72,11 @@ struct blkif_request_rw {
> } seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
> };
>
> +struct blkif_request_trim {
> + blkif_sector_t sector_number;
> + uint64_t nr_sectors;
> +};
> +
> struct blkif_request {
> uint8_t operation; /* BLKIF_OP_??? */
> uint8_t nr_segments; /* number of segments */
> @@ -68,6 +84,7 @@ struct blkif_request {
> uint64_t id; /* private guest value, echoed in resp */
> union {
> struct blkif_request_rw rw;
> + struct blkif_request_trim trim;
> } u;
> };
>
> --
> 1.5.6.5
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home