Changes between Initial Version and Version 1 of Ticket #999, comment 26


Ignore:
Timestamp:
2011-09-02T01:47:22Z (13 years ago)
Author:
davidsarah
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #999, comment 26

    initial v1  
    11Review of [attachment:backends-configuration-docs.darcs.patch]:
    22
    3 ``s3.rst``:
     3{{{s3.rst}}}:
    44* Add a short introduction saying what S3 is and why anyone might want to use it.
    55
    66* It's a bit inconsistent that the value of the backend option is uppercase "S3", but the other option names are lowercase "s3_*". Also, I would make it "s3.*", since that's similar to the use of "." to group other related options.
    77
    8 * Should the ``s3_url`` option include the scheme name, i.e. defaulting to ``http://s3.amazonaws.com`` ? We might want to support https in future (although there would be more to configure if we check certificates).
     8* Should the {{{s3_url}}} option include the scheme name, i.e. defaulting to {{{http://s3.amazonaws.com}}} ? We might want to support https in future (although there would be more to configure if we check certificates).
    99
    10 * In the description of ``s3_max_space``, copy the paragraph starting "This string contains a number" from ``disk.rst`` rather than referring to it.
     10* In the description of {{{s3_max_space}}}, copy the paragraph starting "This string contains a number" from {{{disk.rst}}} rather than referring to it.
    1111
    1212* {{{"enabling ``s3_max_space`` causes an extra S3 usage query to be sent for each share upload, causing the upload process to run slightly slower and incur more S3 request charges."}}}
    1313
    14   Each space query could be amortized over several uploads, using an estimate of the used space in-between. (That wouldn't be accurate if there are several storage servers accessing the same bucket, but it would be accurate enough if the maximum number of such servers is limited.) Even if we don't implement that right away, I'm not sure that this performance issue needs to go in ``s3.rst``.
     14  Each space query could be amortized over several uploads, using an estimate of the used space in-between. (That wouldn't be accurate if there are several storage servers accessing the same bucket, but it would be accurate enough if the maximum number of such servers is limited.) Even if we don't implement that right away, I'm not sure that this performance issue needs to go in {{{s3.rst}}}.
    1515
    1616``disk.rst``:
    1717* "Storing Shares in local filesystem" -> "Storing Shares on a Local Filesystem"
    1818
    19 * use ``backend = disk``, and say that it is the default.
     19* use {{{backend = disk}}}, not {{{backend = local filesystem}}}, and say that it is the default.
    2020
    21 ``configuration.rst``:
     21{{{configuration.rst}}}:
    2222* "Clients will be unaware of what backend is used by the server." -> "Clients need not be aware of which backend is used by a server."
    2323