On Wed, Nov 1, 2017 at 1:24 PM, David Disseldorp <ddiss@xxxxxxx> wrote:
> RBD devices are currently incorrectly initialised with the block queue
> discard_alignment set to the underlying RADOS object size.
>
> As per Documentation/ABI/testing/sysfs-block:
> The discard_alignment parameter indicates how many bytes the beginning
> of the partition is offset from the internal allocation unit's natural
> alignment.
>
> Correcting the discard_alignment parameter from the RADOS object size to
> zero has no effect on how discard requests are propagated through the
> block layer - @alignment in __blkdev_issue_discard() remains zero.
> However, it does fix the UNMAP granularity alignment value advertised
> to SCSI initiators via the Block Limits VPD.
>
> Signed-off-by: David Disseldorp <ddiss@xxxxxxx>
> ---
> drivers/block/rbd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
> index b640ad8a6d20..cd4c65843f77 100644
> --- a/drivers/block/rbd.c
> +++ b/drivers/block/rbd.c
> @@ -4423,7 +4423,7 @@ static int rbd_init_disk(struct rbd_device *rbd_dev)
> /* enable the discard support */
> queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, q);
> q->limits.discard_granularity = segment_size;
> - q->limits.discard_alignment = segment_size;
> + q->limits.discard_alignment = 0;
> blk_queue_max_discard_sectors(q, segment_size / SECTOR_SIZE);
> blk_queue_max_write_zeroes_sectors(q, segment_size / SECTOR_SIZE);
Hi David,
Yeah, discard_alignment == discard_granularity seems bogus. The name
is misleading too, but that probably comes from SBC, which talks about
OPTIMAL UNMAP GRANULARITY and UNMAP GRANULARITY ALIGNMENT.
0 is the default -- let's just drop discard_alignment assignment?
Also, you quoted <disk>/<partition>/discard_alignment description, but
this is about <disk>/discard_alignment. This had me confused for
a moment.
Thanks,
Ilya
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
