checker / repair agent #450

New Issue

warner · 2008-06-03T05:22:12Z

warner commented

2008-06-03 05:22:12 +00:00

Our old roadmap.txt had "Checker/Repairer steps 1.5/2/3" as "maintain file manifest, centralized chekcer/repair-agent, nodes also check their own files".

The idea was that, as a first step, nodes should simply keep track of their "manifest": a list of all the files that they wanted to keep alive. Files that cease to be on this list should be deleted (see #449).

Once we have this list, we can use it to decide what files we want to check/verify/repair. Passing the list to a centralized agent would offload the work from the clients (also allowing them to go offline for extended periods of time). This interacts strongly with #119 (lease expiration / deletion / filechecking / quotas).

We could have a central agent check up on files, or have the client node do it, or both.

Our old roadmap.txt had "Checker/Repairer steps 1.5/2/3" as "maintain file manifest, centralized chekcer/repair-agent, nodes also check their own files". The idea was that, as a first step, nodes should simply keep track of their "manifest": a list of all the files that they wanted to keep alive. Files that cease to be on this list should be deleted (see #449). Once we have this list, we can use it to decide what files we want to check/verify/repair. Passing the list to a centralized agent would offload the work from the clients (also allowing them to go offline for extended periods of time). This interacts strongly with #119 (lease expiration / deletion / filechecking / quotas). We could have a central agent check up on files, or have the client node do it, or both.