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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 20 Jun 2019 13:22:08 -0400 From: "Theodore Ts'o" <tytso@....edu> To: Ross Zwisler <zwisler@...gle.com> Cc: Jan Kara <jack@...e.cz>, Ross Zwisler <zwisler@...omium.org>, linux-kernel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, Andreas Dilger <adilger.kernel@...ger.ca>, Jan Kara <jack@...e.com>, linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, Fletcher Woodruff <fletcherw@...gle.com>, Justin TerAvest <teravest@...gle.com> Subject: Re: [PATCH 2/3] jbd2: introduce jbd2_inode dirty range scoping 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
Powered by blists - more mailing lists