On Tue, 21 Jun 2011 11:18:30 -0400, Josef Bacik wrote:
On 06/21/2011 05:26 AM, Henning Rohlfs wrote:
On Tue, 21 Jun 2011 10:00:59 +0200, Sander wrote:
Henning Rohlfs wrote (ao):
- space_cache was enabled, but it seemed to make the problem
worse.
It's no longer in the mount options.
space_cache is a one time mount option which enabled space_cache.
Not
supplying it anymore as a mount option has no effect (dmesg | grep
btrfs).
I'm sure that after the first reboot after removing the flag from
the
mount options, the system was faster for a while. That must have
been a
coincidence (or just an error on my part).
No, the space cache will make your system faster _after_ having been
enabled once. The reason for this is because we have to build the
cache
the slow way at first, and then after that we can do it the fast way.
What is probably happening is your box is slowing down trying to
build
this cache. Don't mount with clear_cache unless there is a bug in
your
cache. Let it do it's thing and stuff will get faster.
I'm just reporting what I experienced. I had space_cache in the mount
options while the problem developed and removed it when the system got
too slow. After the next reboot the system was responsive for a short
time (an hour maybe - which seems to have been unrelated to the mount
option though from what you described). Now there's no difference
whatsoever between no options, space_cache and clear_cache.
To sum it up: I only played with the clear_cache option because the
system got too slow in the first place. I don't see how the problem can
be related to this option if changing it it makes no difference.
Thanks,
Henning
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
