At Wed, 08 Aug 2012 13:45:09 +0800,
Liu Yuan wrote:
>
> On 08/07/2012 09:11 PM, MORITA Kazutaka wrote:
> > + /* retrieve_object_from_snap fails while farm_end_recover is
> > + * ongoing because the trunk object is not created yet.
> > + * Let's get the sha1 value from omap in that case.*/
> > + if (!buffer) {
> > + unsigned char *sha1;
> > + struct sha1_file_hdr h;
> > +
> > + sha1 = get_sha1_from_omap(oid);
> > + if (sha1)
> > + buffer = sha1_file_read(sha1, &h);
> > +
> > + dprintf("retrieve object %"PRIx64" with omap, %s\n",
> > + oid, buffer ? "succeed" : "fail");
> > + }
> > if (!buffer)
> > return SD_RES_NO_OBJ;
> > memcpy(iocb->buf, buffer, iocb->length);
>
> This patch might work, but we don't handle partial read_working_object
> gracefully: we simply return NULL and try to get sha1 from omap as a
> workaround.
>
> I'd suggest following fix:
> in trunk_file_write_recovery()
> 1. generate sha1 for all the stale oid, remove all the stale oid from
> the trunk_active_list and splice to a temp remove tree
> 2 write trunk sha1
> 3 if success, then remove all the object from working directory.
>
> In this way, we don't need expose omap outside trunk and no need to
> modify the logic of farm_read().
Agreed, that's a better approach.
Thanks,
Kazutaka
--
sheepdog mailing list
[email protected]
http://lists.wpkg.org/mailman/listinfo/sheepdog
