From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
Ian.Campbell@citrix.com, lidongyang@novell.com,
owen.smith@citrix.com, paul.durrant@citrix.com, pasik@iki.fi
Cc: konrad.wilk@oracle.com
Subject: [PATCH 1 of 1] interface: BLKIF_OP_TRIM -> BLKIF_OP_DISCARD
Date: Mon, 10 Oct 2011 13:50:11 -0400 [thread overview]
Message-ID: <d17ab29f2f9ad29a7b8a.1318269011@localhost6.localdomain6> (raw)
In-Reply-To: <patchbomb.1318269010@localhost6.localdomain6>
[-- Attachment #1: Type: text/plain, Size: 5231 bytes --]
# HG changeset patch
# User Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
# Date 1318268906 14400
# Node ID d17ab29f2f9ad29a7b8af02d6f17de7f112a9723
# Parent 72f339bc600d7a9629d3f9eb8a279fbf8be25b12
interface: BLKIF_OP_TRIM -> BLKIF_OP_DISCARD
The name 'trim' is specific to the ATA discard implementation.
The name 'scsi unmap' is specific to the SCSI discard implementation.
We should really use a generic name - and the name 'discard'
looks to be the most generic of them all.
CC: lidongyang@novell.com
CC: owen.smith@citrix.com
CC: Pasi Kärkkäinen <pasik@iki.fi>
CC: JBeulich@novell.com
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
diff -r 72f339bc600d -r d17ab29f2f9a xen/include/public/io/blkif.h
--- a/xen/include/public/io/blkif.h Mon Oct 10 11:21:51 2011 +0100
+++ b/xen/include/public/io/blkif.h Mon Oct 10 13:48:26 2011 -0400
@@ -82,26 +82,37 @@
*/
#define BLKIF_OP_RESERVED_1 4
/*
- * Recognised only if "feature-trim" is present in backend xenbus info.
- * The "feature-trim" node contains a boolean indicating whether trim
- * requests are likely to succeed or fail. Either way, a trim request
+ * Recognised only if "feature-discard" is present in backend xenbus info.
+ * The "feature-discard" node contains a boolean indicating whether trim
+ * (ATA) or unmap (SCSI) - conviently called discard requests are likely
+ * to succeed or fail. Either way, a discard 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!
- *
- * Trim operation is a request for the underlying block device to mark
- * extents to be erased. 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 be returned. More information about trim operations at:
+ * or not it is worthwhile for the frontend to attempt discard requests.
+ * If a backend does not recognise BLKIF_OP_DISCARD, it should *not*
+ * create the "feature-discard" node!
+ *
+ * Discard operation is a request for the underlying block device to mark
+ * extents to be erased. However, discard does not guarantee that the blocks
+ * will be erased from the device - it is just a hint to the device
+ * controller that these blocks are no longer in use. What the device
+ * controller does with that information is left to the controller.
+ * Discard operations are passed with sector_number as the
+ * sector index to begin discard operations at and nr_sectors as the number of
+ * sectors to be discarded. The specified sectors should be discarded if the
+ * underlying block device supports trim (ATA) or unmap (SCSI) operations,
+ * or a BLKIF_RSP_EOPNOTSUPP should be returned.
+ * More information about trim/unmap operations at:
* http://t13.org/Documents/UploadedDocuments/docs2008/
* e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc
+ * http://www.seagate.com/staticfiles/support/disc/manuals/
+ * Interface%20manuals/100293068c.pdf
+ * We also provide three extra XenBus options to the discard operation:
+ * 'discard-granularity' - Max amount of sectors that can be discarded.
+ * 'discard-alignment' - 4K, 128K, etc aligment on sectors to erased.
+ * 'discard-secure' - whether the discard can also securely erase data.
*/
-#define BLKIF_OP_TRIM 5
-
+#define BLKIF_OP_DISCARD 5
/*
* Maximum scatter/gather segments per request.
* This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
@@ -134,18 +145,21 @@ struct blkif_request {
typedef struct blkif_request blkif_request_t;
/*
- * Cast to this structure when blkif_request.operation == BLKIF_OP_TRIM
- * sizeof(struct blkif_request_trim) <= sizeof(struct blkif_request)
+ * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD
+ * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request)
*/
-struct blkif_request_trim {
- uint8_t operation; /* BLKIF_OP_TRIM */
+struct blkif_request_discard {
+ uint8_t operation; /* BLKIF_OP_DISCARD */
uint8_t reserved; /* */
blkif_vdev_t handle; /* same as for read/write requests */
uint64_t id; /* private guest value, echoed in resp */
blkif_sector_t sector_number;/* start sector idx on disk */
uint64_t nr_sectors; /* number of contiguous sectors to trim */
+ /* ignored if 'discard-secure=0' */
+#define BLKIF_OP_DISCARD_FLAG_SECURE (1<<1)
+ uint32_t flag;
};
-typedef struct blkif_request_trim blkif_request_trim_t;
+typedef struct blkif_request_discard blkif_request_discard_t;
struct blkif_response {
uint64_t id; /* copied from request */
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-10-10 17:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-10 17:50 [PATCH 0 of 1] Patch to alter BLKIF_OP_TRIM to BLKIF_OP_DISCARD (v2) Konrad Rzeszutek Wilk
2011-10-10 17:50 ` Konrad Rzeszutek Wilk [this message]
2011-10-10 19:58 ` [PATCH 1 of 1] interface: BLKIF_OP_TRIM -> BLKIF_OP_DISCARD Konrad Rzeszutek Wilk
2011-10-11 18:27 ` Konrad Rzeszutek Wilk
2011-10-12 10:08 ` Jan Beulich
2011-10-12 10:40 ` Ian Campbell
2011-10-12 15:22 ` Konrad Rzeszutek Wilk
-- strict thread matches above, loose matches on Subject: below --
2011-08-31 3:40 [PATCH 0 of 1] Patch to alter BLKIF_OP_TRIM to BLKIF_OP_DISCARD (v1) Konrad Rzeszutek Wilk
2011-08-31 3:40 ` [PATCH 1 of 1] interface: BLKIF_OP_TRIM -> BLKIF_OP_DISCARD Konrad Rzeszutek Wilk
2011-08-31 4:17 ` Li Dongyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d17ab29f2f9ad29a7b8a.1318269011@localhost6.localdomain6 \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=lidongyang@novell.com \
--cc=owen.smith@citrix.com \
--cc=pasik@iki.fi \
--cc=paul.durrant@citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).