[tahoe-lafs-trac-stream] [tahoe-lafs] #1566: if a stored share has a corrupt header, other shares held by that server for the file should still be accessible to clients

[tahoe-lafs]

#1566: if a stored share has a corrupt header, other shares held by that server
for the file should still be accessible to clients
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  warner
  davidsarah             |     Status:  new
         Type:  defect   |  Milestone:  1.10.0
     Priority:  major    |    Version:  1.9.0b1
    Component:  code-    |   Keywords:  corruption preservation storage
  storage                |  design-review-needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by davidsarah):

 * keywords:  corruption preservation storage => corruption preservation
     storage design-review-needed
 * owner:  davidsarah => warner
 * status:  assigned => new
 * milestone:  undecided => 1.10.0


Comment:

 Replying to [comment:3 warner]:
 > I think the server should not report anything to the client about shares
 with corrupt headers. It should file a local corruption report (as if the
 remote client had called {{{remote_advise_corrupt_share()}}}, but with a
 flag that shows this was discovered locally, and probably in a part of the
 share that the client wouldn't be able to read anyways).
 >
 > I'd be ok with reporting "nope, no shares here" if all shares are
 corrupt, rather than returning an error. I don't think the client is in a
 good position to do much with information about shares that are so corrupt
 that it can't even see part of their contents (which is what header
 corruption would mean). The only interaction I can think of is how the
 client might try to repair this file: they can't replace the corrupt-
 header share (the server admin will need to delete it locally), they can't
 modify it's contents, so they ought to just put a new copy somewhere else.
 They'll probably try to put a new copy on this server, which it needs to
 refuse (refusal doesn't always mean no-space-available, although the
 client might have bugs which makes it interpret refusal that way).

 Good, that's essentially what I'd implemented in
 [5477/ticket999-S3-backend]. Please review! (I think that changeset is
 understandable independently of the other pluggable-backends changes.
 Comments particularly wanted on the behaviour when attempting to write
 shares with corrupted headers.)

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1566#comment:4>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage