Large file fsm checkpointing

This page is Deprecated

This page has been subsumed by Object Chunking and Garbage Collection

FSM Checkpointing

For all of the FSMS, checkpointing is useful as a sort of heartbeat to show that a process is still working on something. If this heartbeat isn't updated after a certain period of time, some garbage collection might take place.

GET

The only conceivable checkpointing the GET FSM could do is check in that it's still reading a file so that delete processes could wait until it's reasonable likely that no more actors are reading the blocks.

PUT

The PUT FSM should checkpoint occasionally to show which blocks have been written, for garbage collection purposes (in case the writing proc dies). That being said, are we going to have to check all the blocks anyway because the writer might not have updated the manifest after writing its last few blocks?

DELETE

The DELETE FSM benefits from checkpointing as it goes, particularly when there are multiple delete procs running at once. This might be an optimization we take advantage of at first, one of the delete actors could notice that a block was already deleted by another actor and go ahead and remove it from its list of blocks.