[tahoe-lafs-trac-stream] [tahoe-lafs] #1869: pluggable backends: serialize backend operations on a shareset

[tahoe-lafs]

#1869: pluggable backends: serialize backend operations on a shareset
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  davidsarah
  davidsarah             |     Status:  assigned
         Type:  defect   |  Milestone:  1.11.0
     Priority:  normal   |    Version:  cloud-branch
    Component:  code-    |   Keywords:  cloud-backend storage shareset
  storage                |  cache
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by davidsarah):

 * status:  new => assigned


Old description:

> The following issue needs to be fixed before the pluggable backends code
> is merged to trunk (#1819). Before pluggable backends, operations that
> access share storage were synchronous, and so two or more such operations
> could not run concurrently. This is important because clients make the
> assumption of serializability for accesses to a mutable share on a given
> server (if they are the only such client, which is implied by the Prime
> Coordination Directive).
>
> Now that backend operations are asynchronous, they can run concurrently.
> That needs to be fixed. Note that operations on different sharesets do
> ''not'' need to be serializable with respect to each other (that would
> impose unnecessary delays).
>
> The simplest way to implement this is probably to have a weak cache
> mapping storage indices to ShareSet objects, so that there can only be
> one ShareSet object per actual shareset, and then use a deferred queue in
> the ShareSet object to serialize operations. I'm not sure exactly where
> the cache should go yet.

New description:

 The following issue needs to be fixed before the pluggable backends code
 is merged to trunk (#1819). Before pluggable backends, operations that
 access share storage were synchronous, and so two or more such operations
 could not run concurrently. This is important because clients make the
 assumption of serializability for accesses to a mutable share on a given
 server (if they are the only such client, which is implied by the Prime
 Coordination Directive).

 Now that backend operations are asynchronous, they can run concurrently.
 That needs to be fixed. Note that operations on different sharesets do
 ''not'' need to be serializable with respect to each other. (That would
 impose unnecessary delays.)

 The simplest way to implement this is probably to have a weak cache
 mapping storage indices to !ShareSet objects, so that there can only be
 one !ShareSet object per actual shareset, and then use a deferred queue in
 the !ShareSet object to serialize operations. I'm not sure exactly where
 the cache should go yet.

--

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1869#comment:1>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage