linux-ext4 - Re: [PATCH 00/12] jbd2 optimization and bug fixes

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 11 Feb 2013 16:52:59 +0100
From:	Jan Kara <jack@...e.cz>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 00/12] jbd2 optimization and bug fixes

On Sat 09-02-13 16:53:40, Ted Tso wrote:
> I've been recently looking at journalling code in ext4, and it's clear
> that no one has really been through this code in a while.  It's easy to
> find some easy optimization.
> 
> Some general rules of thumb that developers should keep in mind when
> making changes to ext4:
> 
> 1) It's important to minimize the amount of time that a handle is held
> active, since a journal commit can't be closed until all handles have
> been stopped.  In the ideal world, disk reads and memory allocations
> should be done *before* calling ext4_journal_start().
>
> 2) It's important that number of credits needed for a particular handle
> be large enough; otherwise it's possible that we run out of space in the
> journal without being able to finish the handle.
>
> 3)  It's also important that we not overestimate then number of credits
> needed, since otherwise we might close a transaction too early --- and
> in particular, the process which starts the transaction commit process
> will tend to suffer the greatest amount of latency.
  True but it's not too bad - we give back the credits we didn't use once
the current handle is dropped. But if there are many handles open in
parallel or if the overestimate is really huge, it will have visible
effects. So I agree it's good to keep the estimate as close as resonably
possible to reality.

> Currently enabling quotas cause the number of credits required to
> balloon significantly.  Most of the time we need nowhere the number of
> credits which we reserve, so there's opportunity to optimize things.
> (For example, we could make sure create the quota record is created in a
> seprate transaction.)
  So write(2) and similar calls are already optimized. You are right that
create(2) or unlink(2) still overestimate needed credits only due to
remotely possible worst case.

								Honza
-- 
Jan Kara <jack@...e.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html