On 2010-09-28 06:58, James Bottomley wrote: > On Mon, 2010-09-27 at 13:23 -0400, Mike Snitzer wrote: >> On Mon, Sep 27 2010 at 12:54pm -0400, >> Jens Axboe <jaxboe@xxxxxxxxxxxx> wrote: >> >>> On 2010-09-28 01:41, Martin K. Petersen wrote: >>>> Mike Snitzer reported that he has access to a device that supports thin >>>> provisioning but does not use the Block Limits VPD page to indicate >>>> discard granularity. Instead it reports a huge (1MB) physical block >>>> size. That caused a bit of fallout in the topology stack which assumed a >>>> physical block size of 4KiB or less. >>> >>> Fixing the overflow aside, I question the validity of setting the physical >>> block size to something larger than PAGE_SIZE as there's no way that that >>> could really work in the current kernel. >>> >>> I would suggest doing something similar as we do with other 'invalid' >>> settings that we cannot honor, print a warning and drop the queue >>> limits to PAGE_SIZE. >> >> I'm inclined to agree. Doesn't make a whole lot of sense. >> >> But could this cap of PAGE_SIZE be enforced with a follow-on patch? Or >> would you rather see it be dealt with in a single revised 2/2 patch? > > It's up to Jens, but I'd prefer, unless there's a very good reason, that > the patches we put into the kernel be right first time around, since > that generates a cleaner history and a better example should anyone go > looking for one in the tree. Yes, from a correctness point of view it doesn't matter, but when people go looking up fixes for whatever reason, it's much better to include such a fix in the original patch so it's not missed. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
