On Sat, 2 Jan 2010 21:44:17 +0100, "Carlos R. Mafra" wrote: > The partition has 150 GB, so perhaps NILFS2 thinks that there > is "enough free space" and did not care too much about > deleting the old data. But I thought that what would matter > most is the protection_period from /etc/nilfs_cleanerd.conf (3600)... No, no, I meant the current GC of NILFS2 does not see how much free space is left. It just monotonically works unless user changes GC parameters with a HUP signal. > I must have understood it incorrectly, because I thought that after > 3600 secs after deleting those 10 GB the partition would shrink to 90 GB > "quickly" (like in 1-2 hours). Than after those 1-2 hours my old > data would be forever gone. > > So that was my odd feeling about NILFS2. I would not necessarily > say that it is a "problem" because if one is not using an external > hard disk then eventually there will be enough time to clean things > up, but it feels like it could be better. I have even read some > emails from the archives where people had problems with a full > partition even though they knew they had free space. > > To test it a bit more, I increased nsegments_per_clean to 12, > decreased protection_period to 60 and cleaning_interval to 2, > but now the cleanerd was using like 15% of CPU and it was not > cleaning the data much faster (I don't remember the numbers). > > So what is more important to NILFS2, the notion of "free space > left" or the protection_period setting? "free space left" should be cared, but the current GC does not as I mentioned above. So, the protection_period setting is the most important. The next is GC speed given by cleaning_interval and nsegments_per_clean (tweaking cleaning_interval seems preferable because increasing nsegments_per_clean causes a burst of memory allocation). Cheers, Ryusuke Konishi -- 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
