On 24.10.2011 23:34, Christian Brunner wrote:
2011/10/24 Chris Mason<chris.mason@xxxxxxxxxx>:
On Mon, Oct 24, 2011 at 03:51:47PM -0400, Josef Bacik wrote:
On Mon, Oct 24, 2011 at 10:06:49AM -0700, Sage Weil wrote:
[adding linux-btrfs to cc]
Josef, Chris, any ideas on the below issues?
On Mon, 24 Oct 2011, Christian Brunner wrote:
Thanks for explaining this. I don't have any objections against btrfs
as a osd filesystem. Even the fact that there is no btrfs-fsck doesn't
scare me, since I can use the ceph replication to recover a lost
btrfs-filesystem. The only problem I have is, that btrfs is not stable
on our side and I wonder what you are doing to make it work. (Maybe
it's related to the load pattern of using ceph as a backend store for
qemu).
Here is a list of the btrfs problems I'm having:
- When I run ceph with the default configuration (btrfs snaps enabled)
I can see a rapid increase in Disk-I/O after a few hours of uptime.
Btrfs-cleaner is using more and more time in
btrfs_clean_old_snapshots().
In theory, there shouldn't be any significant difference between taking a
snapshot and removing it a few commits later, and the prior root refs that
btrfs holds on to internally until the new commit is complete. That's
clearly not quite the case, though.
In any case, we're going to try to reproduce this issue in our
environment.
I've noticed this problem too, clean_old_snapshots is taking quite a while in
cases where it really shouldn't. I will see if I can come up with a reproducer
that doesn't require setting up ceph ;).
This sounds familiar though, I thought we had fixed a similar
regression. Either way, Arne's readahead code should really help.
Which kernel version were you running?
[ ack on the rest of Josef's comments ]
This was with a 3.0 kernel, including all btrfs-patches from josefs
git repo plus the "use the global reserve when truncating the free
space cache inode" patch.
I'll try the readahead code.
The current readahead code is only used for scrub. I plan to extend it
to snapshot deletion in a next step, but currently I'm afraid it can't
help.
-Arne
Thanks,
Christian
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
