storage servers should report if the filesystem containing shares has been unmounted #1943

New Issue

tahoe-lafs · 2013-04-13T02:53:42Z

daira commented

2013-04-13 02:53:42 +00:00

A storage server might have its shares directory in a filesystem mounted from a removable disk. In that case, there is no indication of whether the disk has been removed; the server still appears to be connected.

A storage server might have its `shares` directory in a filesystem mounted from a removable disk. In that case, there is no indication of whether the disk has been removed; the server still appears to be connected.

tahoe-lafs added the

labels 2013-04-13 02:53:42 +00:00

tahoe-lafs added this to the undecided milestone 2013-04-13 02:53:42 +00:00

RedEmerald commented

2013-04-13 03:11:40 +00:00

As expected, The tahoe storage node fails to return shares when the drive is unplugged.

Also as expected, if you try to upload a file, the storage server is skipped (assuming there are enough servers to make tahoe "happy").

And finally, once the external drive is reattached, shares are immediately retrievable and new shares are uploaded without issue.

Considering all of the above, this really is just a UI fix although it will probably require some code changes to make the node report it's status.

As expected, The tahoe storage node fails to return shares when the drive is unplugged. Also as expected, if you try to upload a file, the storage server is skipped (assuming there are enough servers to make tahoe "happy"). And finally, once the external drive is reattached, shares are immediately retrievable and new shares are uploaded without issue. Considering all of the above, this really is just a UI fix although it will probably require some code changes to make the node report it's status.

gdt commented

2013-04-13 13:04:33 +00:00

I wouldn't call it a "UI" fix (tahoe has an odd culture of expecting a filesystem to be used by a human instead of by a computer (WUI)).

I'd call this ticket a specific case of the more general issue of fault handling and monitoring. An unmounted fs is not so different from one with bad permissions. The point is probably that if the server thinks it can't store shares (because it did some access(2)-like check, or because it tried and failed), then it needs to report that in the introducer protocol. It can still be online but without read access to shares it should have, or without write access, and this is useful information both to humans and programmatic clients.

It makes my head hurt to think about the proper behavior of doing repair when there is a server that says it has shares but can't get to them right now. I'd say this should be treated the same as the server not being present, for starters.

I wouldn't call it a "UI" fix (tahoe has an odd culture of expecting a filesystem to be used by a human instead of by a computer (WUI)). I'd call this ticket a specific case of the more general issue of fault handling and monitoring. An unmounted fs is not so different from one with bad permissions. The point is probably that if the server thinks it can't store shares (because it did some access(2)-like check, or because it tried and failed), then it needs to report that in the introducer protocol. It can still be online but without read access to shares it should have, or without write access, and this is useful information both to humans and programmatic clients. It makes my head hurt to think about the proper behavior of doing repair when there is a server that says it has shares but can't get to them right now. I'd say this should be treated the same as the server not being present, for starters.

Sign in to join this conversation.