[Qemu-devel] sheepdog's "CoQueue overlapping_queue;"

[Qemu-devel] sheepdog's "CoQueue overlapping_queue;"

[Paolo Bonzini]

I am curious about why overlapping_queue is required for sheepdog.
Overlapping requests have unspecified outcome so the CoQueue is not
necessary as long as the server doesn't crash or return an error.

Hitoshi, could you clarify this point for me?

Thanks,

Paolo

Re: [Qemu-devel] sheepdog's "CoQueue overlapping_queue;"

[Hitoshi Mitake]

[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

On Mon, Apr 4, 2016 at 10:04 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:

> I am curious about why overlapping_queue is required for sheepdog.
> Overlapping requests have unspecified outcome so the CoQueue is not
> necessary as long as the server doesn't crash or return an error.
>
> Hitoshi, could you clarify this point for me?
>

The CoQueue is required because the sheepdog server can return an error in
a case of overlapping requests. For handling copy on write and discard, the
sheepdog server interprets requests that incur metadata (inode) update. It
is required for garbage collecting unused objects efficiently. When
reference of the metadata is updated (x -> y in a case of COW, x -> 0 in a
case of discard), the server reclaims the old x object. If two or more
requests try to update the reference of x, only first one request will be
able to cause reclamation of x successfully. Second (or later) one's
reclamation will fail because the x is already reclaimed by the first one.

This client side serialization is required because of the design of
sheepdog. sheepdog doesn't have a dedicated metadata servers that can
provide transactional update of metadata (e.g. HDFS has this kind of
metadata server). So the clients need to serialize updates for avoiding
inconsistent metadata update.

(Technically, sheepdog does transactional update of metadata in a case of
virtual disk creation. It is based on virtual synchrony so the update can
be transactional even without centralized metadata management component)

Thanks,
Hitoshi


> Thanks,
>
> Paolo
>
>

[-- Attachment #2: Type: text/html, Size: 2154 bytes --]