Re: fsck performance.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux