At Fri, 24 Aug 2012 12:44:05 +0800,
Liu Yuan wrote:
>
> I am also in favor of simple implementation. I think a dedicated .stale
> directory idea could also apply to Farm. So How about following approach:
>
> merge simple store into Farm, then it actually run the code as
> current simple store. That is, use .stale only for recovery and
> trunk & snap for snapshot objects.
It is a good idea to refine the farm backend store too, but simple
store should be added as another driver, I think. The simple driver
would become a good tutorial to introduce new drivers.
>
> By modularizing Farm, we can share one code base for better development
> and won't lose features that Farm provides. Trunk & snap design looks
I think we can share the code even if we add simple store as another
driver. For example:
==
static int farm_read(uint64_t oid, struct siocb *iocb)
{
return simple_read(oid, iocb);
}
static int farm_write(uint64_t oid, struct siocb *iocb, int create)
{
int ret;
ret = simple_write(oid, iocb, create);
if (ret == SD_RES_SUCCESS)
trunk_update_entry(oid);
return ret;
}
==
I'd like to see farm implementation on top of the simple store rather
than merging simple store code into farm.
Thanks,
Kazutaka
> complicated for now, but it is actually useful as a building block for
> future more advanced features, for e.g, we can store all read-only base
> VDI objects as sha1 objects to enjoy the data reduction. (From our
> internal usage of Sheepdog, we observe a heavy use of 'template', so
> this reduction could be rather promising).
--
sheepdog mailing list
sheepdog@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/sheepdog
