Open GoogleCodeExporter opened 8 years ago
Original comment by daniel.r...@gmail.com
on 14 May 2008 at 6:47
Stephane, can you update us on this? According to your post
http://groups.google.com/group/zumastor/msg/d2acb62302350b49
mounting with noatime and doubling cache size to 256MB helped
greatly in an initial test. Is it still helping in more realistic
tests?
Original comment by daniel.r...@gmail.com
on 15 May 2008 at 8:15
To really fix this, we'll need to change the snapshot delete code
so it processes I/O while doing deletes.
Daniel P. has volunteered to tackle that for release 0.10.
Original comment by daniel.r...@gmail.com
on 15 May 2008 at 11:07
Hi Daniel, to answer your question in a previous comment, I'm not under the
impression that increasing the cache size to 256 MB helped a lot. As I had
mentionned
earlier, I had to wipe out the snapstore, and it's not as full as it was before
yet,
but deleting a snapshot already takes about 25 seconds. Here's a ddsnap output
with
Jiaying patch for displaying the metadata usage:
Snapshot store block size = 4096; 11,962,287 of 13,107,200 chunks free
Origin size: 102,395,543,552 bytes
Write density: 0
Creation time: Mon May 12 18:31:19 2008
Snap Creation time Usecnt Prio Chunks Unshared Shared
0 Mon May 12 15:00:54 2008 1 0 357796 36597 321199
9 Tue May 13 00:00:01 2008 1 0 355304 33838 321466
7 Wed May 14 00:00:12 2008 1 0 346879 37292 309587
5 Thu May 15 00:00:13 2008 1 0 321111 66198 254913
1 Thu May 15 22:00:18 2008 1 0 220450 33382 187068
2 Thu May 15 23:00:18 2008 1 0 220365 33333 187032
3 Fri May 16 00:00:17 2008 1 0 220247 33326 186921
4 Fri May 16 01:00:13 2008 1 0 220154 33319 186835
16 Fri May 16 02:00:13 2008 1 0 220067 33323 186744
6 Fri May 16 03:00:13 2008 1 0 219955 33321 186634
15 Fri May 16 04:00:12 2008 1 0 219859 33309 186550
8 Fri May 16 05:00:12 2008 1 0 219757 33307 186450
14 Fri May 16 06:00:12 2008 1 0 219663 33326 186337
10 Fri May 16 07:01:15 2008 1 0 175708 33464 142244
11 Fri May 16 08:00:22 2008 1 0 138155 33350 104805
12 Fri May 16 09:00:20 2008 1 0 137995 33351 104644
13 Fri May 16 10:00:28 2008 1 0 18436 4214 14222
totals 1136551 578250 558301
Metadata usage: 34,250,752 bytes
I beleive noatime had a great impact on usability as I haven't experienced yet
hangings, but I'm not using the machine interactively as heavily as I was
before when
every now and then vim/zsh... would hang and I'd look at the clock and it was
xx:00.
In any case, I'd consider using noatime as being a workaround rather than a
solution
as it's trading one feature (access time on files) for another (snapshots).
Original comment by s.chaze...@gmail.com
on 16 May 2008 at 9:15
Yes, noatime is a workaround (though it'll be a common one).
Mounting with atime is a good way to convert a read-only
stress test into a read-write stress test :-)
We plan to address this bug for real in release 0.10.
Original comment by daniel.r...@gmail.com
on 16 May 2008 at 12:47
Original issue reported on code.google.com by
s.chaze...@gmail.com
on 13 May 2008 at 4:25