Re: Does nilfs2 do any in-place writes?

[Andreas Rohner <andreas.rohner-hi6Y0CQ0nG0@public.gmane.org>]

On 2014-01-19 00:08, Vyacheslav Dubeyko wrote:
> I think that it is very desirable to share patches for the review on early
> stages because it is possible to achieve a valuable results by means of
> open and continuos discussion. So, you are welcome to share your
> vision and your patches.

Good I will prepare my patches.

> As I remember, I had made many remarks about your approach and about
> your code last time. So, I hope that you rework your approach significantly.

Yes it is basically a complete rewrite.

>> [1] https://www.dropbox.com/s/3ued8g5xaktnpbq/replay_parallel_ssd_line.pdf
> 
> To be honest, I completely misunderstand this diagram. It is hard to understand
> it without additional description, from my point of view.

Yes you are probably right about that. It is generated from a GC log
file. For every GC operation I print out the number of live blocks. For
example if the GC cleans a segment and 90% of the blocks in it are live,
then 90% of the blocks need to be moved to a new segment. Moving blocks
is undesirable and therefore I call that "inefficient". In this example
the efficiency would be 10%. So 10% would then become one point in the
graph at time 0. The goal of every cleaning policy is to find segments
with as few live blocks as possible. So efficiency is basically the
percentage of dead blocks. Maybe I should label it differently...

The vertical dashed lines mark the time, when the benchmark finished.
The GC still runs on for some time after that until it reaches the
max_clean_segments threshold.

The graph shows, that the cost-benefit and greedy policies are better at
finding segments with a lot of dead blocks. So less blocks need to be
moved to new segments and the benchmark finishes in less than half the time.

Best regards,
Andreas Rohner
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html