On 08/21/2012 12:07 AM, Christoph Hellwig wrote: > Another thing that sprang into mind is that instead of the formal > recovery enable/disable we should simply always delay recovery, that > is only do recovery after every N seconds if changes happened. > Especially in the cases of whole racks going up/down or upgrades that > dramatically reduces the number of epochs required, and thus reduces > the recovery overhead. > > I didn't actually have time to look into the implementation implications > of this yet, it's just high level thoughs.
I think negatively to delay recovery all the time. It is useful to delay recovery in some time window for maintenance or operational purposes, so I think the idea only to delay recovery manually at some controlled window is useful, but if we extend this to all the running time, it will bring cluster to a less safe state (if not dangerous) at any point. (we only upgrade cluster/maintain individual node only at some time, not all the time, no?) Trading data reliability is always the last resort for a distributed system, which highlights data reliability compared to single data instance in local disk. -- thanks, Yuan -- sheepdog mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/sheepdog
