linux-ext4 - Re: question about writeback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 14 Mar 2019 19:02:56 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Ross Zwisler <zwisler@...gle.com>
Cc:     Dave Chinner <david@...morbit.com>, linux-ext4@...r.kernel.org,
        Jan Kara <jack@...e.com>, Jens Axboe <axboe@...nel.dk>,
        linux-block@...r.kernel.org, Ross Zwisler <zwisler@...nel.org>
Subject: Re: question about writeback

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