Re: [PATCH 05/14] block: Deprecate the use of the term sector in the context of block integrity
On 7/25/2014 11:34 PM, Martin K. Petersen wrote: The protection interval is not necessarily tied to the logical block size of a block device. Stop using the terms sector and sectors. Going forward we will use the term seed to describe the initial reference tag value for a given I/O. Interval will be used to describe the portion of the data buffer that a given piece of protection information is associated with. Signed-off-by: Martin K. Petersen martin.peter...@oracle.com Looks good to me, Reviewed-by: Sagi Grimberg sa...@mellanox.com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] block: Deprecate the use of the term sector in the context of block integrity
On 8/6/2014 4:32 PM, Sagi Grimberg wrote: On 7/25/2014 11:34 PM, Martin K. Petersen wrote: The protection interval is not necessarily tied to the logical block size of a block device. Stop using the terms sector and sectors. Going forward we will use the term seed to describe the initial reference tag value for a given I/O. Interval will be used to describe the portion of the data buffer that a given piece of protection information is associated with. Signed-off-by: Martin K. Petersen martin.peter...@oracle.com Looks good to me, Reviewed-by: Sagi Grimberg sa...@mellanox.com Following this patch we should modify scsi layer to compute with interval instead of sector_size. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] block: Deprecate the use of the term sector in the context of block integrity
Looks good, Reviewed-by: Christoph Hellwig h...@lst.de -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] block: Deprecate the use of the term sector in the context of block integrity
On 5/29/2014 6:28 AM, Martin K. Petersen wrote:
The protection interval is not necessarily tied to the logical block
size of a block device. Stop using the terms sector and sectors.
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
---
block/bio-integrity.c | 46 +-
block/blk-integrity.c | 10 +-
drivers/scsi/sd_dif.c | 46 +++---
include/linux/blkdev.h | 6 +++---
4 files changed, 52 insertions(+), 56 deletions(-)
diff --git a/block/bio-integrity.c b/block/bio-integrity.c
index e06b3c807eef..c52a8fd98706 100644
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -191,29 +191,25 @@ bool bio_integrity_enabled(struct bio *bio)
EXPORT_SYMBOL(bio_integrity_enabled);
/**
- * bio_integrity_hw_sectors - Convert 512b sectors to hardware ditto
+ * bio_integrity_intervals - Return number of integrity intervals for a bio
* @bi: blk_integrity profile for device
- * @sectors: Number of 512 sectors to convert
+ * @sectors: Size of the bio in 512-byte sectors
*
* Description: The block layer calculates everything in 512 byte
- * sectors but integrity metadata is done in terms of the hardware
- * sector size of the storage device. Convert the block layer sectors
- * to physical sectors.
+ * sectors but integrity metadata is done in terms of the data integrity
+ * interval size of the storage device. Convert the block layer sectors
+ * to the appropriate number of integrity intervals.
*/
-static inline unsigned int bio_integrity_hw_sectors(struct blk_integrity *bi,
- unsigned int sectors)
+static inline unsigned int bio_integrity_intervals(struct blk_integrity *bi,
+ unsigned int sectors)
{
- /* At this point there are only 512b or 4096b DIF/EPP devices */
- if (bi-sector_size == 4096)
- return sectors = 3;
-
- return sectors;
+ return sectors (ilog2(bi-interval) - 9);
}
Now that protection information interval does not necessarily match the
sector_size, should this routine
protect against bogus bi-interval (e.g. fail if bi-interval
sector_size for example)? Not sure
if this check is really needed here, but it might be useful to have
(although protection interval
is still effectively sector_size).
static inline unsigned int bio_integrity_bytes(struct blk_integrity *bi,
unsigned int sectors)
{
- return bio_integrity_hw_sectors(bi, sectors) * bi-tuple_size;
+ return bio_integrity_intervals(bi, sectors) * bi-tuple_size;
}
/**
@@ -227,25 +223,25 @@ static int bio_integrity_generate_verify(struct bio *bio,
int operate)
struct blk_integrity_exchg bix;
struct bio_vec *bv;
struct bio_integrity_payload *bip = bio_integrity(bio);
- sector_t sector;
- unsigned int sectors, ret = 0, i;
+ sector_t seed;
+ unsigned int intervals, ret = 0, i;
void *prot_buf = page_address(bip-bip_vec-bv_page) +
bip-bip_vec-bv_offset;
if (operate)
- sector = bio-bi_iter.bi_sector;
+ seed = bio-bi_iter.bi_sector;
else
- sector = bip-bip_iter.bi_sector;
+ seed = bip-bip_iter.bi_sector;
bix.disk_name = bio-bi_bdev-bd_disk-disk_name;
- bix.sector_size = bi-sector_size;
+ bix.interval = bi-interval;
bio_for_each_segment_all(bv, bio, i) {
void *kaddr = kmap_atomic(bv-bv_page);
bix.data_buf = kaddr + bv-bv_offset;
bix.data_size = bv-bv_len;
bix.prot_buf = prot_buf;
- bix.sector = sector;
+ bix.seed = seed;
if (operate)
bi-generate_fn(bix);
@@ -257,9 +253,9 @@ static int bio_integrity_generate_verify(struct bio *bio,
int operate)
}
}
- sectors = bv-bv_len / bi-sector_size;
- sector += sectors;
- prot_buf += sectors * bi-tuple_size;
+ intervals = bv-bv_len / bi-interval;
+ seed += intervals;
+ prot_buf += intervals * bi-tuple_size;
kunmap_atomic(kaddr);
}
@@ -300,17 +296,17 @@ int bio_integrity_prep(struct bio *bio)
unsigned long start, end;
unsigned int len, nr_pages;
unsigned int bytes, offset, i;
- unsigned int sectors;
+ unsigned int intervals;
bi = bdev_get_integrity(bio-bi_bdev);
q = bdev_get_queue(bio-bi_bdev);
BUG_ON(bi == NULL);
BUG_ON(bio_integrity(bio));
- sectors = bio_integrity_hw_sectors(bi, bio_sectors(bio));
+ intervals = bio_integrity_intervals(bi, bio_sectors(bio));
/* Allocate kernel buffer for protection data */
- len = sectors * bi-tuple_size;
+ len
Re: [PATCH 05/14] block: Deprecate the use of the term sector in the context of block integrity
On 7/3/2014 12:35 PM, Sagi Grimberg wrote:
On 5/29/2014 6:28 AM, Martin K. Petersen wrote:
The protection interval is not necessarily tied to the logical block
size of a block device. Stop using the terms sector and sectors.
Signed-off-by: Martin K. Petersen martin.peter...@oracle.com
---
block/bio-integrity.c | 46
+-
block/blk-integrity.c | 10 +-
drivers/scsi/sd_dif.c | 46
+++---
include/linux/blkdev.h | 6 +++---
4 files changed, 52 insertions(+), 56 deletions(-)
diff --git a/block/bio-integrity.c b/block/bio-integrity.c
index e06b3c807eef..c52a8fd98706 100644
--- a/block/bio-integrity.c
+++ b/block/bio-integrity.c
@@ -191,29 +191,25 @@ bool bio_integrity_enabled(struct bio *bio)
EXPORT_SYMBOL(bio_integrity_enabled);
/**
- * bio_integrity_hw_sectors - Convert 512b sectors to hardware ditto
+ * bio_integrity_intervals - Return number of integrity intervals
for a bio
* @bi:blk_integrity profile for device
- * @sectors:Number of 512 sectors to convert
+ * @sectors:Size of the bio in 512-byte sectors
*
* Description: The block layer calculates everything in 512 byte
- * sectors but integrity metadata is done in terms of the hardware
- * sector size of the storage device. Convert the block layer sectors
- * to physical sectors.
+ * sectors but integrity metadata is done in terms of the data
integrity
+ * interval size of the storage device. Convert the block layer
sectors
+ * to the appropriate number of integrity intervals.
*/
-static inline unsigned int bio_integrity_hw_sectors(struct
blk_integrity *bi,
-unsigned int sectors)
+static inline unsigned int bio_integrity_intervals(struct
blk_integrity *bi,
+ unsigned int sectors)
{
-/* At this point there are only 512b or 4096b DIF/EPP devices */
-if (bi-sector_size == 4096)
-return sectors = 3;
-
-return sectors;
+return sectors (ilog2(bi-interval) - 9);
}
Now that protection information interval does not necessarily match
the sector_size, should this routine
protect against bogus bi-interval (e.g. fail if bi-interval
sector_size for example)? Not sure
if this check is really needed here, but it might be useful to have
(although protection interval
is still effectively sector_size).
For v1 scsi_transfer_length should also be modified to use protection
interval.
Sagi.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] block: Deprecate the use of the term sector in the context of block integrity
On Wed, May 28, 2014 at 11:28:39PM -0400, Martin K. Petersen wrote: The protection interval is not necessarily tied to the logical block size of a block device. Stop using the terms sector and sectors. This does more than just renaming symbols, so it needs a better description or even better splitting into separate patches. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/14] block: Deprecate the use of the term sector in the context of block integrity
Christoph == Christoph Hellwig h...@infradead.org writes: Christoph On Wed, May 28, 2014 at 11:28:39PM -0400, Martin K. Petersen wrote: The protection interval is not necessarily tied to the logical block size of a block device. Stop using the terms sector and sectors. Christoph This does more than just renaming symbols, so it needs a Christoph better description or even better splitting into separate Christoph patches. The only thing I see that does more than a rename is the interval calculation tweak. I'll put that in a separate patch. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
