> On Feb. 23, 2013, 11:57 p.m., Benjamin Hindman wrote: > > src/slave/status_update_manager.cpp, line 451 > > <https://reviews.apache.org/r/8837/diff/3/?file=259980#file259980line451> > > > > Why? Isn't this just good archive information to have (and possibly > > show)?
My main intention here (and with this review) is to curb the growth of meta directories. For example for an executor with 1000s of completed tasks, it would be wasteful for recovery to go through them, because its not going to use that info for recovery. Recovery is mainly interested in "non-terminal" states (of tasks, executors, frameworks) to be able to re-concile. Ideally, I want to delete a task directory (when it reaches a terminal state and all updates are acked), an executor directory (when its terminated), framework directory (framework is shutdown) etc. This would make recovery fast and have a small memory footprint for the recovered state. Thoughts? - Vinod ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8837/#review16992 ----------------------------------------------------------- On Feb. 19, 2013, 8:09 p.m., Vinod Kone wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8837/ > ----------------------------------------------------------- > > (Updated Feb. 19, 2013, 8:09 p.m.) > > > Review request for mesos, Benjamin Hindman and Ben Mahler. > > > Description > ------- > > Currently we only gc task meta directories. > > TODO: gc'ing executor directories. this is tricky because of the async nature > status updates manager. > > > Diffs > ----- > > src/slave/slave.cpp d4721c3eb51db87278d05f6fbe2eadb8a3a9b4dd > src/slave/status_update_manager.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/8837/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Vinod Kone > >
