> 23 янв. 2014 г., в 22:12, Andreas Rohner <andreas.rohner@xxxxxxx>: >> >>> This patch set implements a small new feature and there shouldn't be >>> any compatibility issues. It enables the GC to check how much free >>> space can be gained from cleaning a segment and if it is less than a >>> certain threshold it will abort the operation and try a different >>> segment. >> >> When you have cleaned a segment then you can use the whole one. >> So, if segment has 8 MB in size then it will be available 8 MB free space. >> The phrase "It enables the GC to check how much free space can be gained >> from cleaning a segment" really confuses me. Because I always know >> how much space I gain after cleaning every segment. I suppose that you >> mean something different. Am I correct? > > You have to move the live blocks to a new segment, so you gain only (8 > MB - live_blocks) of free space. You always will have 8 MB after cleaning (garbage collection). So, all segments are identical from the free space point of view. What does GC check? And how can GC distinguish segments on the basis of free space? All cleaned segments return 8 MB free space for further allocation. So, all used segments will be over any threshold. >>> Although no blocks need to be moved, the SUFILE entry of the >>> corresponding segment needs to be updated to avoid an infinite loop. >>> >>> This is potentially useful for all gc policies, but it is especially >>> beneficial for the timestamp policy. >> >> I completely misunderstand this statement. What do you mean? > > Well the timestamp policy always selects the oldest segment. If the > oldest segment is below the threshold it won't be cleaned. If we don't > change the timestamp it will be immediately selected again and it > probably will still be below the threshold and so on in an infinite loop. I understand your approach. But I misunderstand about what usefulness you are talking. What is it? [snip] >>> >>> The speed of the GC was tuned to the HDD. It was probably too aggressive >>> for the much faster SSD. That is probably the reason why the difference >>> in GB written and read is much higher than 20 GB. >> >> I misunderstand completely what you mean here. > > You need to be a bit more specific. These are the results of my > benchmark. The GB Written and GB Read values are calculated by simply > importing /proc/diskstats into R (You subtract the values before the > benchmark from those after the benchmark). > > The patched version writes less and reads less. Pretty simple. Here I asked about aggressiveness related to SSD. What do you mean? Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
