On 05/17/2012 01:27 PM, Christoph Hellwig wrote: > On Thu, May 17, 2012 at 09:56:15AM +0800, Liu Yuan wrote: >> This assumption seems not necessary, at least to Farm, where I/O will >> always be routed into objects in the working directory. >> >> Let outstanding IO blocks confchg will risk both dead lock and live lock. > > It also has rather direct performance consequences. > Yes, not only performance, but also useability, especially those IO for Guest OS's meta data updates, which is time-outed by Guest OS, have a very high possibility to fail and as a result, put Guest filesystem into read-only. >> I think both recovery code and any assumptions need to be revisited and >> possibly this is a long term issue. > > One question is if we should support the simple store much longer. Not > just in this regard farm has a lot of advantages, while I'm not sure > what the added benefit of the simple store is. > I'll vote for dropping it. I am not sure if Kazum has any feature to be designed on top of simple store. IMHO, dropping the support for simple store will benefit us (by redesign higher level code, such as abstracted store layer, recovery to be more oriented for Farm): 1) better modular store abstraction, which was originally designed for simply store layout (objects are tagged by epoch), but comes up with many assumptions(restrictions) 2) better recovery code logic integrated into Farm, because Farm can be easily modified to concurrent object access, partial data migration, etc. For compatibility issue, we can provide a script which translate simple store layout into Farm. Thanks, Yuan |