Re: [Xen-devel] [PATCH 2/2] pvops/blkif: Add trim operation interface

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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