From: Jan Kara <jack@suse.cz>
To: 'Christoph Hellwig' <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>, kanchan <joshi.k@samsung.com>,
linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
linux-nvme@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org, prakash.v@samsung.com,
anshul@samsung.com,
"Martin K. Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH v5 0/7] Extend write-hint framework, and add write-hint for Ext4 journal
Date: Wed, 22 May 2019 12:25:30 +0200 [thread overview]
Message-ID: <20190522102530.GK17019@quack2.suse.cz> (raw)
In-Reply-To: <20190521082846.GA11024@infradead.org>
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 <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2019-05-22 10:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190425112347epcas2p1f7be48b8f0d2203252b8c9dd510c1b61@epcas2p1.samsung.com>
2019-04-25 11:19 ` [PATCH v5 0/7] Extend write-hint framework, and add write-hint for Ext4 journal Kanchan Joshi
[not found] ` <CGME20190425112351epcas2p209fdb12872bdcdcb11afd7b6e196b85e@epcas2p2.samsung.com>
2019-04-25 11:19 ` [PATCH v5 1/7] fs: introduce write-hint start point for in-kernel hints Kanchan Joshi
[not found] ` <CGME20190425112355epcas2p11e197c8fc33698feb7150d1f4148407e@epcas2p1.samsung.com>
2019-04-25 11:19 ` [PATCH v5 2/7] block: increase stream count for in-kernel use Kanchan Joshi
[not found] ` <CGME20190425112358epcas1p13da4f182241366c309cb2c76df3fb048@epcas1p1.samsung.com>
2019-04-25 11:19 ` [PATCH v5 3/7] block: introduce API to register stream information with block-layer Kanchan Joshi
[not found] ` <CGME20190425112400epcas1p26e7634f95a185a83c31470006d291161@epcas1p2.samsung.com>
2019-04-25 11:19 ` [PATCH v5 4/7] block: introduce write-hint to stream-id conversion Kanchan Joshi
[not found] ` <CGME20190425112403epcas1p13006198cda351a08c8403c2b85c9f102@epcas1p1.samsung.com>
2019-04-25 11:20 ` [PATCH v5 5/7] nvme: register stream info with block layer Kanchan Joshi
[not found] ` <CGME20190425112406epcas1p4a54b2c5d15ae42a53ff3c206cf7a7892@epcas1p4.samsung.com>
2019-04-25 11:20 ` [PATCH v5 6/7] fs: introduce APIs to enable passing write-hint with buffer-head Kanchan Joshi
[not found] ` <CGME20190425112408epcas2p2ddba9fdf175645dd2647da191eac5e1c@epcas2p2.samsung.com>
2019-04-25 11:20 ` [PATCH v5 7/7] fs/ext4,jbd2: add support for sending write-hint with journal Kanchan Joshi
2019-05-10 5:31 ` [PATCH v5 0/7] Extend write-hint framework, and add write-hint for Ext4 journal kanchan
2019-05-10 17:02 ` Christoph Hellwig
2019-05-17 5:31 ` kanchan
2019-05-20 14:27 ` 'Christoph Hellwig'
2019-05-21 8:25 ` Jan Kara
2019-05-21 8:28 ` 'Christoph Hellwig'
2019-05-22 10:25 ` Jan Kara [this message]
2019-06-26 12:47 ` kanchan
2019-06-28 7:25 ` 'Christoph Hellwig'
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=20190522102530.GK17019@quack2.suse.cz \
--to=jack@suse.cz \
--cc=anshul@samsung.com \
--cc=hch@infradead.org \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=prakash.v@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).