[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190522102530.GK17019@quack2.suse.cz>
Date: Wed, 22 May 2019 12:25:30 +0200
From: Jan Kara <jack@...e.cz>
To: 'Christoph Hellwig' <hch@...radead.org>
Cc: Jan Kara <jack@...e.cz>, kanchan <joshi.k@...sung.com>,
linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
linux-nvme@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, prakash.v@...sung.com,
anshul@...sung.com,
"Martin K. Petersen" <martin.petersen@...cle.com>
Subject: Re: [PATCH v5 0/7] Extend write-hint framework, and add write-hint
for Ext4 journal
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@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists