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

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

 



On Fri, Mar 18, 2016 at 10:37 AM, Jens Axboe <axboe@xxxxxx> wrote:
> On 03/17/2016 07:39 PM, Martin K. Petersen wrote:
>>>>>>>
>>>>>>> "Jens" == Jens Axboe <axboe@xxxxxx> writes:
>>
>>
>> Jens> You are not missing anything, that's exactly how it is intended,
>> Jens> and that's how the interface is designed as well. If you want to
>> Jens> tie extra meaning to this for specific drivers or transports,
>> Jens> that's fine, and there's nothing that prevents that from
>> Jens> happening. As it stands, and as it is proposed, it's just a write
>> Jens> tag/stream ID that we can set on a file or inode, and have passed
>> Jens> to the driver. Nothing more, nothing less.
>>
>> Yep. I'm fine with having the option of letting applications request an
>> ID from the kernel and being able to tag I/Os. But it is also imperative
>> that we are able to tag all remaining I/Os automatically. Hashing inode
>> and device/partition is fine, it does not have to be particularly
>> clever.
>>
>> There are several types of non-flash storage in the pipeline that depend
>> on being able to identify blocks to disjoint LBA ranges as belonging to
>> the same "file". So as long as we don't go down the 10-channel flash
>> controller rat hole I'm perfectly happy...
>
>
> So where do we go from here? Seems to me like the core parts we all agree
> on, what do we do about the user interface? I can split the patchset into 2
> so we can get the core bits merged, and start further discussion on the
> interface part, if we need to.

I think the ability to set a stream-id on an inode is interesting, but
the use cases we went through for enabling host-hinted SSHDs [1] found
that a good amount of benefit could be had by specifying per-process
stream-ids.

It seems in the inode case we're worried about communicating permanent
placement hints to the controller, while in the per-process hint we
can communicate some amount of temporal and access pattern based
differentiation.

[1]: https://lkml.org/lkml/2014/10/29/805
--
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