From: Jens Axboe <axboe@fb.com>
To: Peter Zijlstra <peterz@infradead.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Jeff Moyer <jmoyer@redhat.com>, <linux-kernel@vger.kernel.org>,
<linux-fsdevel@vger.kernel.org>, <adilger@dilger.ca>,
<david@fromorbit.com>
Subject: Re: [PATCH v2] Support for write stream IDs
Date: Wed, 6 May 2015 11:25:05 -0600 [thread overview]
Message-ID: <554A4E71.2020401@fb.com> (raw)
In-Reply-To: <20150506142624.GM17717@twins.programming.kicks-ass.net>
On 05/06/2015 08:26 AM, Peter Zijlstra wrote:
> On Tue, May 05, 2015 at 06:09:18PM -0400, Martin K. Petersen wrote:
>>>>>>> "Jens" == Jens Axboe <axboe@fb.com> writes:
>>
>> Jens> I'm not trying to make a shortcut. I deliberately do not want to
>> Jens> make ID generation/assignment part of the kernel. There's no
>> Jens> reason that can't exist outside of the kernel, in a libstreamid or
>> Jens> similar.
>>
>> That just perpetuates the broken model, though. Why wouldn't we want to
>> have stream ids readily available inside the kernel to tag journals,
>> filesystem metadata, data migration, who knows what?
>
>> The only sensible solution is for the kernel to manage the stream
>> IDs. And for them to be plentiful. The storage device is free to ignore
>> them, do LRU or whatever it pleases to manage them if it has an internal
>> limit on number of open streams, etc.
>
> I agree; one of the primary tasks of an operating system kernel is
> arbitrage and control of hardware resources.
Sure, that's what the kernel does, but the problem here includes that
the IDs space and generation is currently being done by the device. So
it's not a simple as divvying out an open space of resources.
--
Jens Axboe
next prev parent reply other threads:[~2015-05-06 17:25 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 20:02 [PATCH v2] Support for write stream IDs Jens Axboe
2015-05-05 20:02 ` [PATCH 1/7] block: add support for carrying a stream ID in a bio Jens Axboe
2015-05-05 20:02 ` [PATCH 2/7] Add support for per-file/inode stream ID Jens Axboe
2015-05-05 20:09 ` Christoph Hellwig
2015-05-05 20:02 ` [PATCH 3/7] direct-io: add support for write stream IDs Jens Axboe
2015-05-05 20:02 ` [PATCH 4/7] Add stream ID support for buffered mpage/__block_write_full_page() Jens Axboe
2015-05-05 20:02 ` [PATCH 5/7] btrfs: add support for write stream IDs Jens Axboe
2015-05-05 20:03 ` [PATCH 6/7] xfs: add support for buffered writeback stream ID Jens Axboe
2015-05-05 20:03 ` [PATCH 7/7] ext4: add support for write stream IDs Jens Axboe
2015-05-05 20:07 ` [PATCH v2] Support " Christoph Hellwig
2015-05-05 20:12 ` Jens Axboe
2015-05-05 20:20 ` Christoph Hellwig
2015-05-05 20:31 ` Jens Axboe
2015-05-05 20:43 ` Christoph Hellwig
2015-05-05 20:50 ` Christoph Hellwig
2015-05-05 20:51 ` Jeff Moyer
2015-05-05 21:05 ` Jens Axboe
2015-05-05 21:39 ` Martin K. Petersen
2015-05-05 21:48 ` Jens Axboe
2015-05-05 22:09 ` Martin K. Petersen
2015-05-06 14:26 ` Peter Zijlstra
2015-05-06 17:25 ` Jens Axboe [this message]
2015-05-06 16:50 ` Boaz Harrosh
2015-05-06 17:21 ` Jens Axboe
2015-05-07 19:19 ` Martin K. Petersen
2015-05-08 18:48 ` Jens Axboe
2015-05-12 2:50 ` Martin K. Petersen
-- strict thread matches above, loose matches on Subject: below --
2015-04-18 20:03 Jens Axboe
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=554A4E71.2020401@fb.com \
--to=axboe@fb.com \
--cc=adilger@dilger.ca \
--cc=david@fromorbit.com \
--cc=jmoyer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=peterz@infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox