One checkpoint doesn't get GC'd

One checkpoint doesn't get GC'd

[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:
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,
-- 
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: One checkpoint doesn't get GC'd

[Ryusuke Konishi]

Hi dexen,
On Mon, 14 Nov 2011 13:51:50 +0100, dexen deVries wrote:
> 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.

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


> For reference,
> kernel: 3.1.0 (stock)
> nilfs-utils: 2.1.0-rc1
>
> Cheers,
> -- 
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: One checkpoint doesn't get GC'd

[dexen deVries]

Hi Ryusuke,


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,
-- 
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html