V5 series, towards extending write-hint/streams infrastructure for
kernel-components, and adding support for sending write-hint with Ext4/JBD2 journal.
Here is the history/changelog -
Changes since v4:
- Removed write-hint field from request. bi_write_hint in bio is used for
merging checks now.
- Modified write-hint-to-stream conversion logic. Now, kernel hints are mapped
to upper range of stream-ids, while user-hints continue to remain mapped to
lower range of stream-ids.
Changes since v3:
- Correction in grouping related changes into patches
- Rectification in commit text at places
Changes since v2:
- Introduce API in block layer so that drivers can register stream info. Added
new limit in request queue for this purpose.
- Block layer does the conversion from write-hint to stream-id.
- Stream feature is not disabled anymore if device reports less streams than
a particular number (which was set as 4 earlier).
- Any write-hint beyond reported stream-count turn to 0.
- New macro "WRITE_LIFE_KERN_MIN" can be used as base by kernel mode components.
Changes since v1:
- introduce four more hints for in-kernel use, as recommended by Dave chinner
& Jens axboe. This isolates kernel-mode hints from user-mode ones.
- remove mount-option to specify write-hint, as recommended by Jan kara &
Dave chinner. Rather, FS always sets write-hint for journal. This gets ignored
if device does not support stream.
- Removed code-redundancy for write_dirty_buffer (Jan kara's review comment)
V4 patch:
https://lkml.org/lkml/2019/4/17/870
V3 patch:
https://marc.info/?l=linux-block&m=155384631909082&w=2
V2 patch:
https://patchwork.kernel.org/cover/10754405/
V1 patch:
https://marc.info/?l=linux-fsdevel&m=154444637519020&w=2
Kanchan Joshi (7):
fs: introduce write-hint start point for in-kernel hints
block: increase stream count for in-kernel use
block: introduce API to register stream information with block-layer
block: introduce write-hint to stream-id conversion
nvme: register stream info with block layer
fs: introduce APIs to enable passing write-hint with buffer-head
fs/ext4,jbd2: add support for sending write-hint with journal
block/blk-core.c | 29 ++++++++++++++++++++++++++++-
block/blk-merge.c | 4 ++--
block/blk-settings.c | 12 ++++++++++++
drivers/nvme/host/core.c | 23 ++++++-----------------
fs/buffer.c | 18 ++++++++++++++++--
fs/ext4/ext4_jbd2.h | 1 +
fs/ext4/super.c | 2 ++
fs/jbd2/commit.c | 11 +++++++----
fs/jbd2/journal.c | 3 ++-
fs/jbd2/revoke.c | 3 ++-
include/linux/blkdev.h | 8 ++++++--
include/linux/buffer_head.h | 3 +++
include/linux/fs.h | 2 ++
include/linux/jbd2.h | 8 ++++++++
14 files changed, 97 insertions(+), 30 deletions(-)
--
2.7.4
On Tue 21-05-19 01:28:46, 'Christoph Hellwig' wrote:
> On Tue, May 21, 2019 at 10:25:28AM +0200, Jan Kara wrote:
> > performance benefits for some drives. After all you can just think about it
> > like RWH_WRITE_LIFE_JOURNAL type of hint available for the kernel...
>
> Except that it actuallys adds a parallel insfrastructure. A
> RWH_WRITE_LIFE_JOURNAL would be much more palatable, but someone needs
> to explain how that is:
>
> a) different from RWH_WRITE_LIFE_SHORT
The problem I have with this is: What does "short" mean? What if
userspace's notion of short differs from the kernel notion? Also the
journal block lifetime is somewhat hard to predict. It depends on the size
of the journal and metadata load on the filesystem so there's big variance.
So all we really know is that all journal blocks are the same.
> b) would not apply to a log/journal maintained in userspace that works
> exactly the same
Lifetime of userspace journal/log may be significantly different from the
lifetime of the filesystem journal. So using the same hint for them does
not look like a great idea?
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Wed, Jun 26, 2019 at 06:17:29PM +0530, kanchan wrote:
> Christoph,
> May I know if you have thoughts about what Jan mentioned below?
As said I fundamentally disagree with exposting the streams mess at
the block layer. I have no problem with setting a hint on the journal,
but I do object to exposting the streams mess even more.