Re: [PATCH 11/11] nvme: add support for streams and directives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 16, 2017 at 01:41:36PM -0600, Jens Axboe wrote:
> But honestly, I simply don't care too much about it, for a few reasons:
> 
> 1) I don't know of anyone that uses name spaces to split up a device,
>    except for places where the want integrity on one and not the other.
>    And I haven't even seen that.
> 
> 2) If you do have multiple name spaces, you get some data separation
>    through that. Or not, depending on the device.
> 
> In any case, we'll just have to divide up the streams. Right now we just
> allocate 4 in a first-come first-serve basis. If you have more name
> spaces than streams/4, then some name spaces don't get streams. We could
> make this more fair and do:

Or just not reserve streams for exclusive use of the namespace and
use them directly from the global pool.  Especially if you ever want
to use streams with shared disk filesystems or databases you'd have
to do that anyway.  And due to our hardcoded streams values that
will in fact work nicely.  And it would get rid of the lazy setup
code as well.

> > "If the host issues a Dataset Management command to deallocate logical
> >  blocks that are associated with a stream, it should specify a starting
> >  LBA and length that is aligned to and in multiples of the Stream
> >  Granularity Size"
> 
> Do we use that internally?

I don't understand the comment.  If we issue a deallocate (discard)
we should align it to the Stream Granularity Size as exposed by the
device, easy enough.  While we're at it we should probably also
expose the Stream Write Size as io_min and the Stream Granularity Size
as io_opt in our I/O topology information while at it.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux