On Mon, 2015-08-10 at 12:22 -0400, Martin K. Petersen wrote: > >>>>> "Mike" == Mike Snitzer <snitzer@xxxxxxxxxx> writes: > > Mike> Shouldn't we also be using MAX_BIO_SECTORS in > Mike> blkdev_issue_write_same (instead of UINT_MAX >> 9)? > > The granularity of WRITE SAME is always 1 logical block and there is no > reason to round it down to the next power of two. > > +/* > + * Ensure that max discard sectors doesn't overflow bi_size and hopefully > + * it is of the proper granularity as long as the granularity is a power > + * of two. > + */ > +#define MAX_DISCARD_SECTORS ((1U << 31) >> 9) > + > > That's fine for SATA since we're already capping at 2TB minus change. > But it means we'll be capping unnecessarily on SCSI. And larger range > counts are impending in SATA as well. > > So this goes back to my original comment: The only place there can be a > discard granularity is for SCSI UNMAP. And consequently, we should only > enforce alignment and granularity when that code path is taken in sd.c. > > I'm OK with Ming's patch series in general. Let's leave the discard cap > at UINT_MAX and I'll twiddle the rest in SCSI. Just to make sure I didn't misunderstand it. Did you mean still use (UINT_MAX >> 9) in blkdev_issue_discard()? req_sects = min_t(sector_t, nr_sects, UINT_MAX >> 9); instead of: req_sects = min_t(sector_t, nr_sects, MAX_DISCARD_SECTORS); But that doesn't work for dm-thinp. See Kent's suggestion to use 1<<31. https://www.redhat.com/archives/dm-devel/2015-August/msg00053.html > > Reviewed-by: Martin K. Petersen <martin.petersen@xxxxxxxxxx> > Thanks! -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
