[tahoe-lafs-trac-stream] [tahoe-lafs] #1838: Add StorageLocation hint to Storage Server

[tahoe-lafs]

#1838: Add StorageLocation hint to Storage Server
------------------------------+------------------------------
     Reporter:  PRabahy       |      Owner:  davidsarah
         Type:  enhancement   |     Status:  new
     Priority:  normal        |  Milestone:  undecided
    Component:  code-storage  |    Version:  1.9.2
   Resolution:                |   Keywords:  storage location
Launchpad Bug:                |
------------------------------+------------------------------
Description changed by zooko:

Old description:

> I'm new to Tahoe, so sorry if I don't use all the correct terminology.
>
> I believe that the Storage Server could be enhanced to announce a hint to
> where it stores its data. This will allow a Client to more intelligently
> choose which Storage Servers it chooses to trust with its data (#467,
> #573).
>
> On [wiki:ServerSelection] it looks like Brian already thought about this:
> "I'd love to be able to get stronger diversity among hosts, racks, or
> data centers, but I don't yet know how to get that and get the properties
> listed above, while keeping the filecaps small."
>
> My ideas that when a Client first connects to a Storage Server, the
> Storage Server can respond with a special string that describes where it
> believe that it is storing the data it receives. For example, any server
> that is using the S3 backend (#999) could reply "S3" while any server
> using the Google Drive backend (#1831) could reply "Google". A datacenter
> admin could set all of their servers to reply "ABC_DataCenter".
>
> These hints would be non-authoritative because any Storage Server could
> easily lie about where it is storing the data, but even if all Storage
> Server were lying it would be no worse than today. The rogue Storage
> Servers could collude to say they were all using the same storage
> location, but then the Client would just avoid using more than one of the
> rogue servers. The rouge Storage Servers could also collude to say the
> were all using different storage locations (even though the were in the
> same location), but that simply trick the client back into the current
> behavior.
>
> Finally, by adhering to a convention and parsing the string, a hierarchy
> of locations could be made. For example a company has 2 data centers so
> they set the hint for their servers as "ABC_DC1_RACK1", "ABC_DC1_RACK2",
> "ABC_DC2_RACK1", "ABC_DC2_RACK2", etc. (Related discussion https://tahoe-
> lafs.org/pipermail/tahoe-dev/2009-April/001555.html)

New description:

 I'm new to Tahoe, so sorry if I don't use all the correct terminology.

 I believe that the Storage Server could be enhanced to announce a hint to
 where it stores its data. This will allow a Client to more intelligently
 choose which Storage Servers it chooses to trust with its data (#467,
 #573).

 On [wiki:ServerSelection] it looks like Brian already thought about this:
 "I'd love to be able to get stronger diversity among hosts, racks, or data
 centers, but I don't yet know how to get that and get the properties
 listed above, while keeping the filecaps small."

 My ideas that when a Client first connects to a Storage Server, the
 Storage Server can respond with a special string that describes where it
 believe that it is storing the data it receives. For example, any server
 that is using the S3 backend (#999) could reply "S3" while any server
 using the Google Drive backend (#1831) could reply "Google". A datacenter
 admin could set all of their servers to reply "ABC_DataCenter".

 These hints would be non-authoritative because any Storage Server could
 easily lie about where it is storing the data, but even if all Storage
 Server were lying it would be no worse than today. The rogue Storage
 Servers could collude to say they were all using the same storage
 location, but then the Client would just avoid using more than one of the
 rogue servers. The rouge Storage Servers could also collude to say the
 were all using different storage locations (even though the were in the
 same location), but that simply trick the client back into the current
 behavior.

 Finally, by adhering to a convention and parsing the string, a hierarchy
 of locations could be made. For example a company has 2 data centers so
 they set the hint for their servers as "ABC_DC1_RACK1", "ABC_DC1_RACK2",
 "ABC_DC2_RACK1", "ABC_DC2_RACK2", etc. (Related discussion [//pipermail
 /tahoe-dev/2009-April/001555.html])

--

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