On So 3.Jan'10 at 2:24:25 +0900, Ryusuke Konishi wrote: > On Thu, 31 Dec 2009 10:47:18 +0100, "Carlos R. Mafra" wrote: > > > Naively I would think that the GC will always create some I/O that > > other filesystems don't have, by its very definition. Can you > > quantify by how much the current GC is writing in excess and what would > > be the acceptable numbers? > > The overhead is roughly measured as the number of copied (moved) > blocks per reclaimed segment. The following patch will print the > ratio (number of copied blocks / cleaned blocks) into syslog. Thanks for the reply and I will test your patch to see the numbers in the following days. > I don't know how much is acceptable, but at least, I think the GC > frequency should be suppressed to 0 while the partition has enough > free space, and the selection algorithm should be improved to give > priority to free segments containing less in-use blocks. Good that you mentioned it, because that is something I found a bit unusual about NILFS2. Initially I copied 100 GB into the NILFS2 partition in the external hard disk via a backup script using rsync. Then I deleted 10 GB from my $HOME and reran the script to update the backup on the NILFS2 partition. The size reported by 'df' initially increased and I had to wait around 10 hours to notice it decrease, but the decrease rate was soo slow (around 100 MB/hour or so) that I did not wait anymore and disconnected the hard disk. 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)... 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? -- 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