On Sat, Apr 18, 2015 at 08:45:19AM +0200, Matias Bjorling wrote:
The reason it shouldn't be under the a single block device, is that a target
should be able to provide a global address space.
That allows the address
space to grow/shrink dynamically with the disks. Allowing a continuously
On Sat, Apr 18, 2015 at 08:45:19AM +0200, Matias Bjorling wrote:
snip
The reason it shouldn't be under the a single block device, is that a target
should be able to provide a global address space.
That allows the address
space to grow/shrink dynamically with the disks. Allowing a continuously
On Sat, Apr 18, 2015 at 08:45:19AM +0200, Matias Bjorling wrote:
> The low level drivers will be NVMe and vendor's own PCI-e drivers. It's very
> generic in their nature. Each driver would duplicate the same work. Both
> could have normal and open-channel drives attached.
I didn't say the work
Den 17-04-2015 kl. 19:46 skrev Christoph Hellwig:
On Fri, Apr 17, 2015 at 10:15:46AM +0200, Matias Bj?rling wrote:
Just the prep/unprep, or other pieces as well?
All of it - it's functionality that lies logically below the block
layer, so that's where it should be handled.
In fact it should
On Sat, Apr 18, 2015 at 08:45:19AM +0200, Matias Bjorling wrote:
The low level drivers will be NVMe and vendor's own PCI-e drivers. It's very
generic in their nature. Each driver would duplicate the same work. Both
could have normal and open-channel drives attached.
I didn't say the work
Den 17-04-2015 kl. 19:46 skrev Christoph Hellwig:
On Fri, Apr 17, 2015 at 10:15:46AM +0200, Matias Bj?rling wrote:
Just the prep/unprep, or other pieces as well?
All of it - it's functionality that lies logically below the block
layer, so that's where it should be handled.
In fact it should
On Fri, Apr 17, 2015 at 10:15:46AM +0200, Matias Bj?rling wrote:
> Just the prep/unprep, or other pieces as well?
All of it - it's functionality that lies logically below the block
layer, so that's where it should be handled.
In fact it should probably work similar to the mtd subsystem - that is
On 04/17/2015 08:34 AM, Christoph Hellwig wrote:
On Wed, Apr 15, 2015 at 02:34:40PM +0200, Matias Bj??rling wrote:
Allow users to hook into prep/unprep functions just before an IO is
dispatched to the device driver. This is necessary for request-based
logic to take place at upper layers.
I
On Wed, Apr 15, 2015 at 02:34:40PM +0200, Matias Bj??rling wrote:
> Allow users to hook into prep/unprep functions just before an IO is
> dispatched to the device driver. This is necessary for request-based
> logic to take place at upper layers.
I don't think any of this logic belongs into the
On Wed, Apr 15, 2015 at 02:34:40PM +0200, Matias Bj??rling wrote:
Allow users to hook into prep/unprep functions just before an IO is
dispatched to the device driver. This is necessary for request-based
logic to take place at upper layers.
I don't think any of this logic belongs into the block
On 04/17/2015 08:34 AM, Christoph Hellwig wrote:
On Wed, Apr 15, 2015 at 02:34:40PM +0200, Matias Bj??rling wrote:
Allow users to hook into prep/unprep functions just before an IO is
dispatched to the device driver. This is necessary for request-based
logic to take place at upper layers.
I
On Fri, Apr 17, 2015 at 10:15:46AM +0200, Matias Bj?rling wrote:
Just the prep/unprep, or other pieces as well?
All of it - it's functionality that lies logically below the block
layer, so that's where it should be handled.
In fact it should probably work similar to the mtd subsystem - that is
Allow users to hook into prep/unprep functions just before an IO is
dispatched to the device driver. This is necessary for request-based
logic to take place at upper layers.
Signed-off-by: Matias Bjørling
---
block/blk-mq.c | 28 ++--
include/linux/blk-mq.h | 1
Allow users to hook into prep/unprep functions just before an IO is
dispatched to the device driver. This is necessary for request-based
logic to take place at upper layers.
Signed-off-by: Matias Bjørling m...@bjorling.me
---
block/blk-mq.c | 28 ++--
14 matches
Mail list logo
