Re: ReiserFS problems

[Jeff Mahoney <jeffm@suse.com>]

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

|> We've noticed horrible slowdowns when the filesystem is > 90% full. It
|> turns out that when a block group is more than 90% full reiserfs will
|> prefer a different block group. i.e. it is ALWAYS switching block
|> groups when the whole disk is > 90% full. Something like that. When we
|> report something like that it's always: Ah, yes, that's an old bug
|> we've fixed it. Use patch.....
|>
| I don't think you reported that to me.....
|
| Jeff, give me an opinion on this....

The skip_busy algorithm works like so:

If the filesystem is less than 95% full, the allocator tries to be a bit
smarter and leaves 10% of the bitmap free for future allocations to
avoid fragmentation. If the bitmap being examined has 10% or less free
space, it's skipped. *UNLESS* the file doing the allocation already has
an interest in that bitmap, as determined by the allocator getting
passed a non-zero offset into the bitmap.

If it finds no bitmaps that are more than 10% free or the filesystem is
| 95% full, it restarts the search at the initial hint and ignores the
10% rule.

In short;
1) Find a block in the current bitmap if the file's last block was
allocated there.
2) If there aren't any, or there is no stake, search until a bitmap that
is > 10% free is found, but only from the initial search point to the
end of the disk - without wrapping around.
3) If there aren't any, try to find any free block from the initial
search point until the end of the disk
4) If there aren't any, start at the beginning of the disk and search up
to the initial search point.

The idea is that allocations that can be kept contiguous should be. Once
the allocation ends up being outside of the local bitmap, then the disk
is already seeking, so it doesn't matter if it seeks a bit more if it
can find another chunk where it can find contiguous allocation.

All these searches are streamlined by making find_*_zero_bit do as
little work as possible. For each bitmap, the offset of the first zero
bit is kept as well as how many free bits there are. This makes it
trivial to skip bitmaps that have < 10% free, as well as not force the
allocator to scan entire bitmaps to find that the last bit is the zero bit.

So, yes, when the filesystem approaches 95% full, and there are only new
files being created, the *initial* allocations will scatter themselves.
This is by design so that the subsequent allocations for each of those
files will be able to be contiguous with the original allocation.

What is the workload that is producing the horrible slowdowns?

- -Jeff

- --
jeffm@suse.com
jeffm@csh.rit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/MUvoLPWxlyuTD7IRArpkAJ9MThFNeVzmEIONDDlypsALv70dTACgj7xo
EJVh5oDQWqfsG9RH9lcFtO4=
=ZcoM
-----END PGP SIGNATURE-----