From: "Theodore Ts'o" <tytso@mit.edu>
To: Ross Zwisler <zwisler@google.com>
Cc: Dave Chinner <david@fromorbit.com>,
linux-ext4@vger.kernel.org, Jan Kara <jack@suse.com>,
Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org, Ross Zwisler <zwisler@kernel.org>
Subject: Re: question about writeback
Date: Thu, 14 Mar 2019 19:02:56 -0400 [thread overview]
Message-ID: <20190314230256.GD6482@mit.edu> (raw)
In-Reply-To: <CAGRrVHxhBbMX9W9OmftUPDq5R4koJNjJDDy2xPDF073GTVo6jw@mail.gmail.com>
On Thu, Mar 14, 2019 at 02:37:55PM -0600, Ross Zwisler wrote:
> > So perhaps the caller should be waiting on a specific range to bound
> > the wait (e.g. isize as the end of the wait) rather than using the
> > default "keep going until the end of file is reached" semantics?
>
> The call to __filemap_fdatawait_range() is happening via the jdb2 code:
>
> jbd2_journal_commit_transaction()
> journal_finish_inode_data_buffers()
> filemap_fdatawait_keep_errors()
> __filemap_fdatawait_range(end = LLONG_MAX)
I think jbd2 needs to call a new filemap_fdatawait_range_keep_errors()
(to be defined in mm/filemap.c).
> Would it have to be an extending write? Or could it work the same if
> you have one thread just moving forward through a very large file,
> dirtying pages, and the __filemap_fdatawait_range() call will just
> keep finding new pages as it moves forward through the big file?
No, that case is fine because we'll eventually make our way to the end
of the file and stop.
In the long term I want to get rid of data=ordered mode (while still
avoids the stale data problem) without going through all of this hair
so we don't have to call filemap_fdatawait from the commit thread.
The real problem is that ext2/3 allocates blocks, updates the inode
metadata, and then writes the data blocks out. What we need to do is
to swap the 2nd and 3rd steps....
- Ted
next prev parent reply other threads:[~2019-03-14 23:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-14 20:03 question about writeback Ross Zwisler
2019-03-14 20:18 ` Dave Chinner
2019-03-14 20:37 ` Ross Zwisler
2019-03-14 23:02 ` Theodore Ts'o [this message]
2019-03-18 11:38 ` Jan Kara
2019-03-18 22:54 ` Ross Zwisler
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=20190314230256.GD6482@mit.edu \
--to=tytso@mit.edu \
--cc=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=jack@suse.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=zwisler@google.com \
--cc=zwisler@kernel.org \
/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).