From: Jeff Moyer <jmoyer@redhat.com>
To: Jens Axboe <axboe@fb.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
<ming.l@ssi.samsung.com>, <david@fromorbit.com>
Subject: Re: [PATCH RFC v2] Support for write stream IDs
Date: Wed, 25 Mar 2015 12:05:21 -0400 [thread overview]
Message-ID: <x498uel12ri.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <1427296070-8472-1-git-send-email-axboe@fb.com> (Jens Axboe's message of "Wed, 25 Mar 2015 09:07:43 -0600")
Jens Axboe <axboe@fb.com> writes:
> One of the things that exacerbates write amplification on flash
> based devices is that fact that data with different lifetimes get
> grouped together on media. Currently we have no interface that
> applications can use to separate different types of writes. This
> patch set adds support for that.
>
> The kernel has no knowledge of what stream ID is what. The idea is
> that writes with identical stream IDs have similar life times, not
> that stream ID 'X' has a shorter lifetime than stream ID 'X+1'.
And presumably the device also has no knowledge of what stream ID is
what, right?
> There are basically two interfaces that could be used for this. One
> is fcntl, the other is fadvise. This patchset uses fadvise, with a
> new POSIX_FADV_STREAMID hint. The 'offset' field is used to pass
> the relevant stream ID. Switching to fcntl (with a SET/GET_STREAMID)
> would be trivial.
>
> The patchset wires up the block parts, adds buffered and O_DIRECT
> support, and modifies btrfs/xfs too. It should be trivial to extend
> this to all other file systems, I just used xfs and btrfs for testing.
>
> No block drivers are wired up yet. Patches are against current -git.
This proposal leaves lot to the reviewer's imagination. Is there any
research in this area you can point to?
At a high level, are you sure you've got the right interface? I would
think data lifetime would be tied to the file. If that's the case, it
might be possible to not export this to userspace at all, and simply
make it work under the covers. After all, what prevents multiple
applications from using the same stream id at the same time?
Cheers,
Jeff
next prev parent reply other threads:[~2015-03-25 16:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 15:07 [PATCH RFC v2] Support for write stream IDs Jens Axboe
2015-03-25 15:07 ` [PATCH 1/7] block: add support for carrying a stream ID in a bio Jens Axboe
2015-04-09 22:46 ` Andreas Dilger
2015-04-18 19:53 ` Jens Axboe
2015-03-25 15:07 ` [PATCH 2/7] Add support for per-file stream ID Jens Axboe
2015-04-09 9:30 ` Dmitry Monakhov
2015-04-09 16:28 ` Jens Axboe
2015-04-09 23:22 ` Andreas Dilger
2015-04-18 19:51 ` Jens Axboe
2015-03-25 15:07 ` [PATCH 3/7] direct-io: add support for write stream IDs Jens Axboe
2015-03-25 15:07 ` [PATCH 4/7] Add stream ID support for buffered mpage/__block_write_full_page() Jens Axboe
2015-03-25 22:42 ` Ming Lin-SSI
2015-03-25 23:08 ` Jens Axboe
2015-03-25 15:07 ` [PATCH 5/7] btrfs: add support for write stream IDs Jens Axboe
2015-03-25 16:00 ` Chris Mason
2015-03-25 15:07 ` [PATCH 6/7] xfs: add support for buffered writeback stream ID Jens Axboe
2015-03-25 15:07 ` [PATCH 7/7] ext4: add support for write stream IDs Jens Axboe
2015-03-26 20:34 ` Ming Lin-SSI
2015-03-26 20:39 ` Jens Axboe
2015-03-25 16:05 ` Jeff Moyer [this message]
2015-03-25 16:46 ` [PATCH RFC v2] Support " 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=x498uel12ri.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=axboe@fb.com \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.l@ssi.samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).