From: Jens Axboe <axboe@fb.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
Jeff Moyer <jmoyer@redhat.com>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
<linux-block@vger.kernel.org>, <calvinowens@fb.com>,
Christoph Hellwig <hch@lst.de>,
Andreas Dilger <adilger@dilger.ca>
Subject: Re: [PATCH 0/11] Update version of write stream ID patchset
Date: Fri, 18 Mar 2016 10:37:13 -0700 [thread overview]
Message-ID: <56EC3CC9.1060404@fb.com> (raw)
In-Reply-To: <yq1io0kbjcb.fsf@sermon.lab.mkp.net>
On 03/17/2016 07:39 PM, Martin K. Petersen wrote:
>>>>>> "Jens" == Jens Axboe <axboe@fb.com> 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
next prev parent reply other threads:[~2016-03-18 17:37 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 16:10 [PATCH 0/11] Update version of write stream ID patchset Jens Axboe
2016-03-04 16:10 ` [PATCH 01/11] idr: make ida_simple_remove() return an error Jens Axboe
2016-03-04 16:10 ` [PATCH 02/11] block: add support for carrying a stream ID in a bio Jens Axboe
2016-03-04 16:10 ` [PATCH 03/11] Add support for per-file/inode stream ID Jens Axboe
[not found] ` <CAJVOszBXU-qQENcOGG8pWeARwoWL2G3gNJ0H2uNPjXkiVa8S+Q@mail.gmail.com>
2016-03-04 20:35 ` Jens Axboe
2016-03-04 16:10 ` [PATCH 04/11] Add system call for setting inode/file write " Jens Axboe
2016-03-04 16:10 ` [PATCH 05/11] wire up system call for x86/x86-64 Jens Axboe
2016-03-04 16:10 ` [PATCH 06/11] Add support for bdi tracking of stream ID Jens Axboe
2016-03-04 16:10 ` [PATCH 07/11] direct-io: add support for write stream IDs Jens Axboe
2016-03-04 16:10 ` [PATCH 08/11] Add stream ID support for buffered mpage/__block_write_full_page() Jens Axboe
2016-03-04 16:10 ` [PATCH 09/11] btrfs: add support for write stream IDs Jens Axboe
2016-03-04 20:44 ` Chris Mason
2016-03-04 20:45 ` Jens Axboe
2016-03-04 16:10 ` [PATCH 10/11] xfs: add support for buffered writeback stream ID Jens Axboe
2016-03-04 16:10 ` [PATCH 11/11] ext4: add support for write stream IDs Jens Axboe
2016-03-04 19:42 ` [PATCH 0/11] Update version of write stream ID patchset Jeff Moyer
2016-03-04 20:34 ` Jens Axboe
2016-03-04 21:01 ` Jeff Moyer
2016-03-04 21:06 ` Jens Axboe
2016-03-04 22:03 ` Jeff Moyer
2016-03-04 22:13 ` Jens Axboe
2016-03-05 20:48 ` Martin K. Petersen
2016-03-08 21:56 ` Jens Axboe
2016-03-17 23:43 ` Dan Williams
2016-03-18 0:18 ` Jens Axboe
2016-03-18 2:39 ` Martin K. Petersen
2016-03-18 17:37 ` Jens Axboe [this message]
2016-03-18 17:56 ` Dan Williams
2016-03-06 6:13 ` Andreas Dilger
2016-03-06 13:03 ` Martin K. Petersen
2016-03-06 16:08 ` Boaz Harrosh
2016-03-06 20:51 ` Shaun Tancheff
2016-03-07 15:41 ` Martin K. Petersen
2016-03-07 15:34 ` Martin K. Petersen
2016-03-06 22:42 ` Andreas Dilger
2016-03-07 15:52 ` Martin K. Petersen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56EC3CC9.1060404@fb.com \
--to=axboe@fb.com \
--cc=adilger@dilger.ca \
--cc=calvinowens@fb.com \
--cc=dan.j.williams@intel.com \
--cc=hch@lst.de \
--cc=jmoyer@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.