Re: ReiserFS problems

[Hans Reiser <reiser@namesys.com>]

Jeff Mahoney wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hans Reiser wrote:
> | Jeff Mahoney wrote:
> |
> |> -----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.
> |
> |
> | Define this unless clause more fully please.
> |
> |>
> |>
> |> 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
> |
> |
> | stake?
>
> The "unless" and "stake" mean the same thing. When the block allocator
> is given a hint for a file, it's the last block allocated already for
> that file

and when it is a new file?  surely we still use the left neighbor in the 
tree as the hint....?


It seems that Rogiers problems are due to not using this code that you 
wrote at all.....

> . So, the search starts at the bitmap and offset specified by
> the hint. If there is a block available after that position, but still
> in that bitmap, it's used; regardless of the 10% rule.
>
> Once we move out of that bitmap, the skip busy algorithm is applied,
> which aims to keep bitmaps at least 10% free when possible so that
> future allocations may have blocks local to the last allocation 
> available.
>
> The algorithm is only as good as the hint passed to it. It doesn't try
> to be smart about placement other than implementing the above algorithm.
>
> - -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/MnYGLPWxlyuTD7IRAriBAKCBi4j1YvWmndTrQsqDAZex/HFSMACdFMrV
> octG4Hi4ipGEKXUxoiWkFwo=
> =J/Pn
> -----END PGP SIGNATURE-----
>
>
>


-- 
Hans