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.
--
Jens Axboe
--
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
