linux-kernel - Re: [PATCH] reiserfs: eliminate minimum window size for bitmap searching

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:	Tue, 22 Aug 2006 20:38:48 -0400
From:	Jeff Mahoney <jeffm@...e.com>
To:	Andrew Morton <akpm@...l.org>
Cc:	David Masover <ninja@...phack.com>,
	Linus Torvalds <torvalds@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	ReiserFS List <reiserfs-list@...esys.com>,
	Mike Benoit <ipso@...ppymail.ca>
Subject: Re: [PATCH] reiserfs: eliminate minimum window size for bitmap searching

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Morton wrote:
> I can see that the bigalloc code as-is is pretty sad, but this is a scary
> patch.  It has the potential to cause people significant performance
> problems way, way ahead in the future.
> 
> For example, suppose userspace is growing two files concurrently.  It could
> be that the bigalloc code would cause one file's allocation cursor to
> repeatedly jump far away from the second.  ie: a beneficial side-effect. 
> Without bigalloc that side-effect is lost and the two files blocks end up
> all intermingled.
>
> I don't know if that scenario is realistic, but I bet there are similar
> accidental oddities which can occur as a result of this change.
> 
> But what are they?

Bigalloc doesn't cause that effect one way or the other. You'll end up
with blocks still intermingled, just in 32 block[1] chunks. It doesn't
throw the cursor way out, just until the next 32 block free window.
Another thread writing will do the same thing, and the blocks can end up
getting intermingled in the same manner on a different part of the disk.

The behavior you're describing can only be caused by bad hinting: Two
files that are placed too close to each other. This patch changes the
part of the allocator that is *only* responsible for finding the free
bits. Where it should start looking for them is a decision made earlier
in determine_search_start().

This patch just reverts the change that Chris and I submitted ages ago
as part of a number of block allocator enhancements, not as a bug fix. I
think I traced it to the 2.5 days, but I can't find that particular
email. Neither of us anticipated the problem that MythTV users are
hitting with it. Reverting it just makes that part of the allocator
behave similarly to the ext[23] allocator where it just collects
available blocks from a starting point. For every day use, I don't think
performance should be terribly affected, and it definitely fixes the
pathological case that the MythTV users were seeing.

- -Jeff

[1]: For simplicity, I'll continue to reference 32 blocks as the chunk
size. In reality, it can be anything up to 32 blocks.

- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFE66OXLPWxlyuTD7IRApXFAJ9bUsrtfmRC2kOMMWcCel4BZq6/SgCfTcsV
rS6dvKc6MowiAY+r/0Jhp5A=
=MwOb
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/