From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: Kent Overstreet From: "Martin K. Petersen" In-Reply-To: <20150811033851.GA28533@kmo-pixel> (Kent Overstreet's message of "Mon, 10 Aug 2015 19:38:51 -0800") References: <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> <1439230696.26458.6.camel@ssi> <20150811024154.GA26351@redhat.com> <20150811033851.GA28533@kmo-pixel> Date: Tue, 11 Aug 2015 13:49:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Cc: Mike Snitzer , Ming Lei , device-mapper development , Christoph Hellwig , Alasdair Kergon , Lars Ellenberg , Philip Kelleher , Christoph Hellwig , Nitin Gupta , Ming Lin , Oleg Drokin , Al Viro , Ming Lin , Jens Axboe , axboe@fb.com, Andreas Dilger , "Martin K. Petersen" , Geoff Levand , Jiri Kosina , lkml , Jim Paris , Minchan Kim , Joe Thornber , Dongsu Park , drbd-user@lists.linbit.com Subject: Re: [Drbd-dev] [PATCH v5 01/11] block: make generic_make_request handle arbitrarily sized bios List-Id: "*Coordination* of development, patches, contributions -- *Questions* \(even to developers\) go to drbd-user, please." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>>>> "Kent" == Kent Overstreet writes: Kent> This kind of logic really doesn't belong in dm Well it does in this case since the thinp personality actually provisions and unprovisions space. But there is a difference between what dm thinp acts on for its own internal provisioning purposes and what it passes down the stack. I am really against dropping information anywhere along the path. We don't round off read/write requests either. The queue limits were meant as hints to mkfs.* so that on-disk data structures could be laid out in an aligned and storage friendly way. I never intended for the hints to affect runtime behavior. Kent> IMO though it belongs in the driver - if a discard needs to be Kent> dropped because it's too small and the hardware can't do it, that Kent> should be the driver's responsibility. I agree except I really don't want to lop off anything unless the device locks up if we send it partial blocks. There was an array that had problems a while back but I believe they have been fixed. The fundamental premise should be that we pass as comprehensive information as we can. And the device can then decide to ignore all or parts of the request. That's fundamentally how things work at the protocol level in both SCSI and SATA. I don't see any reason why the Linux I/O stack should behave in a different manner. -- Martin K. Petersen Oracle Linux Engineering