One checkpoint doesn't get GC'd
Hi,
I have strange problem: one checkpoint doesn't get garbage-collected, in spite of subsequent checkpoints getting GC'd just alright.
for example:
1170140 2011-10-14 09:34:17 cp - 50 379222 1171655 2011-10-14 14:43:14 cp - 1345 379479 1171663 2011-10-14 14:45:06 cp - 54 379480 1171664 2011-10-14 14:45:17 cp - 51 379479
(...)
A few hours ago there were much more checkpoints between 1170140 and 1171655 and they all got GC'd as expected -- but not the 1170140 itself.
For reference,
kernel: 3.1.0 (stock)
nilfs-utils: 2.1.0-rc1
Cheers,
Signature · 12 lines
dexen deVries [[[↓][→]]] ``As my friend Jacob Gabrielson once put it, advocating Object-Oriented Programming is like advocating Pants-Oriented Clothing.'' -- Steve Yegge, in http://steve-yegge.blogspot.com/2006/03/execution-in- kingdom-of-nouns.html -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): 201111141351.50798.dexen.devries-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Hi dexen,
Quoted 7 lines · dexen deVries
Hi,
I have strange problem: one checkpoint doesn't get garbage-collected, in spite of subsequent checkpoints getting GC'd just alright.
for example:
Quoted 8 lines
1170140 2011-10-14 09:34:17 cp - 50 379222 1171655 2011-10-14 14:43:14 cp - 1345 379479 1171663 2011-10-14 14:45:06 cp - 54 379480 1171664 2011-10-14 14:45:17 cp - 51 379479(...)
A few hours ago there were much more checkpoints between 1170140 and 1171655 and they all got GC'd as expected -- but not the 1170140 itself.
This may happen since garbage collection of nilfs is done for each disk segment instead of checkpoint.
If GC did not reclaim any blocks for a checkpoint, the checkpoint will survive transiently.
Try nilfs-clean command to check if the checkpoint is actually orphan or not. The command triggers one pass GC, and this would actually sweep unused checkpoints. When using this command, you may give the following protection period option to shorten it:
$ sudo nilfs-clean -p 60
Thanks,
Ryusuke Konishi
Quoted 4 lines
For reference,
kernel: 3.1.0 (stock)
nilfs-utils: 2.1.0-rc1
Quoted 14 lines
Cheers,
Signature · 12 lines
dexen deVries [[[↓][→]]] ``As my friend Jacob Gabrielson once put it, advocating Object-Oriented Programming is like advocating Pants-Oriented Clothing.'' -- Steve Yegge, in http://steve-yegge.blogspot.com/2006/03/execution-in- kingdom-of-nouns.html -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Ryusuke,
Quoted 5 lines · On Tuesday 15 of November 2011 17:11:02 you wrote:
This may happen since garbage collection of nilfs is done for each disk segment instead of checkpoint.
If GC did not reclaim any blocks for a checkpoint, the checkpoint will survive transiently.
Thanks for clarification. I've always assumed that GC just removes checkpoints in natural order; good to see it's smarter than that ;-)
The CP got GC'd recently alright.
Cheers,
Signature · 12 lines
dexen deVries [[[↓][→]]] ``As my friend Jacob Gabrielson once put it, advocating Object-Oriented Programming is like advocating Pants-Oriented Clothing.'' -- Steve Yegge, in http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html