From: "Theodore Ts'o" <tytso@mit.edu>
To: Ross Zwisler <zwisler@google.com>
Cc: Jan Kara <jack@suse.cz>, Ross Zwisler <zwisler@chromium.org>,
linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Fletcher Woodruff <fletcherw@google.com>,
Justin TerAvest <teravest@google.com>
Subject: Re: [PATCH 2/3] jbd2: introduce jbd2_inode dirty range scoping
Date: Thu, 20 Jun 2019 13:22:08 -0400 [thread overview]
Message-ID: <20190620172208.GB4650@mit.edu> (raw)
In-Reply-To: <20190620150911.GA4488@google.com>
On Thu, Jun 20, 2019 at 09:09:11AM -0600, Ross Zwisler wrote:
> We could definitely keep separate dirty ranges for each of the current and
> next transaction. I think the case where you would see a difference would be
> if you had multiple transactions in a row which grew the dirty range for a
> given jbd2_inode, and then had a random I/O workload which kept dirtying pages
> inside that enlarged dirty range.
>
> I'm not sure how often this type of workload would be a problem. For the
> workloads I've been testing which purely append to the inode, having a single
> dirty range per jbd2_inode is sufficient.
My inclination would be to keep things simple for now, unless we have
a real workload that tickles this. In the long run I'm hoping to
remove the need to do writebacks from the journal thread altogether,
by always updating the metadata blocks *after* the I/O completes,
instead of before we submit the I/O.
- Ted
next prev parent reply other threads:[~2019-06-20 17:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-19 17:21 [PATCH 0/3] Add dirty range scoping to jbd2 Ross Zwisler
2019-06-19 17:21 ` [PATCH 1/3] mm: add filemap_fdatawait_range_keep_errors() Ross Zwisler
2019-06-20 9:25 ` Jan Kara
2019-06-19 17:21 ` [PATCH 2/3] jbd2: introduce jbd2_inode dirty range scoping Ross Zwisler
2019-06-20 11:04 ` Jan Kara
2019-06-20 15:09 ` Ross Zwisler
2019-06-20 17:22 ` Theodore Ts'o [this message]
2019-06-19 17:21 ` [PATCH 3/3] ext4: use " Ross Zwisler
2019-06-20 11:15 ` Jan Kara
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=20190620172208.GB4650@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=fletcherw@google.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=teravest@google.com \
--cc=viro@zeniv.linux.org.uk \
--cc=zwisler@chromium.org \
--cc=zwisler@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.