Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754266AbbHJQXl (ORCPT ); Mon, 10 Aug 2015 12:23:41 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:42658 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751940AbbHJQXi (ORCPT ); Mon, 10 Aug 2015 12:23:38 -0400 To: Mike Snitzer Cc: Ming Lin , axboe@fb.com, Christoph Hellwig , "Martin K. Petersen" , device-mapper development , Ming Lei , Christoph Hellwig , Alasdair Kergon , Lars Ellenberg , Philip Kelleher , Kent Overstreet , Nitin Gupta , Ming Lin , Oleg Drokin , Al Viro , Jens Axboe , Andreas Dilger , Geoff Levand , Jiri Kosina , lkml , Jim Paris , Minchan Kim , Dongsu Park , drbd-user@lists.linbit.com, Joe Thornber Subject: Re: [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios From: "Martin K. Petersen" Organization: Oracle Corporation References: <20150731213831.GA16464@redhat.com> <1438412290.26596.14.camel@hasee> <20150801163356.GA21478@redhat.com> <1439099990.7880.0.camel@hasee> <20150809064128.GB2436@infradead.org> <1439103347.7880.3.camel@hasee> <20150809070128.GA25739@infradead.org> <1439104707.7880.8.camel@hasee> <20150810150216.GA22719@redhat.com> Date: Mon, 10 Aug 2015 12:22:07 -0400 In-Reply-To: <20150810150216.GA22719@redhat.com> (Mike Snitzer's message of "Mon, 10 Aug 2015 11:02:17 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1384 Lines: 36 >>>>> "Mike" == Mike Snitzer 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. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/