Re: [PATCH 0/11] Update version of write stream ID patchset

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

 



On 03/06/2016 03:03 PM, Martin K. Petersen wrote:
>>>>>> "Andreas" == Andreas Dilger <adilger@xxxxxxxxx> writes:
> 
> Andreas,
> 
> Andreas> What are your thoughts on reserving a small number of the
> Andreas> stream ID values for filesystem metadata (e.g. the first 31
> Andreas> since 0 == unused)?
> 
> The stream ID address space might be 16-bit but the devices currently
> being discussed can only handle a few concurrently open streams (4, 8,
> 16).
> 

So I can't for the life of me understand what is the use of all this.

If what Jens said at beginning for data grouping than what is it at all
got to do with open and close of anything? Really?

Does it make any sense to you? I mean with multy-queue with HW channels
for every CPU, parallel IO, and poling because even interrupts are too
slow, you want me to cram everything and serialize it on 4 open/close
streams?

Either I'm completely missing something. Or please please explain
what is going on. How does 4 stream make any sense in today's NvME
HW? How does open/close anything make any sense?

On the surface it looks like someone is smoking something really
bad.

> Discussions are ongoing about whether the devices should be able to
> implicitly close a stream based on LRU or something similar when the hw
> max is reached. But as it stands you have to explicitly close an
> existing stream with a separate command when the max is reached.
> Otherwise a write with a previously unused stream ID will fail.
> 

?? (see smoking above ;-) )

> I.e. there is a significant cost to switching between stream IDs and
> thus I am afraid the current stuff isn't well suited to having a fine
> grained tagging approach like the one you are proposing.
> 

So again who cares for anything that hurts performance? Why would
I want to use anything that has "significant cost" at all?

Thanks
Boaz

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[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