linux-ext4 - Re: fsck performance.

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:	Sun, 20 Feb 2011 14:34:06 -0500
From:	Ted Ts'o <tytso@....edu>
To:	Rogier Wolff <R.E.Wolff@...Wizard.nl>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: fsck performance.

On Sun, Feb 20, 2011 at 12:09:31PM -0500, Ted Ts'o wrote:
> 
> Ah, you're using tdb.  Tdb can be really slow.  It's been on my todo
> list to replace tdb with something else, but I haven't gotten around
> to it.

Hmm... after taking a quick look at the TDB sources, why don't you try
this.  In lib/ext2fs/icount.c and e2fsck/dirinfo.c, try replacing the
flag TDB_CLEAR_IF_FIRST with TDB_NOLOCK | TDB_NOSYNC.  i.e., try
replacing:

	icount->tdb = tdb_open(fn, 0, TDB_CLEAR_IF_FIRST,
			       O_RDWR | O_CREAT | O_TRUNC, 0600);

with:

	icount->tdb = tdb_open(fn, 0, TDB_NOLOCK | TDB_NOSYNC,
			       O_RDWR | O_CREAT | O_TRUNC, 0600);

Could you let me know what this does to the performance of e2fsck with
scratch files enabled?

Oh, and BTW, it would be useful if you tried configuring
tests/test_config so that it sets E2FSCK_CONFIG with a test
e2fsck.conf that enables the scratch files somewhere in tmp, and then
run the regression test suite with these changes.

If they work, and it solves the performance problem, let me know and
send me patches.  If we can figure out some way of improving the
performance without needing to replace tdb, that would be great...

     		       	   	 	   - Ted
--
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