#1105 new defect

allow uncoordinated reads concurrent with writes of a mutable file or directory locally

Reported by: davidsarah Owned by:
Priority: major Milestone: undecided
Component: code-mutable Version: 1.7.0
Keywords: docs fuse sftp integrity reliability Cc:
Launchpad Bug:

Description (last modified by daira)

In the fix to #265 in Tahoe v1.1, MutableFileNodes were made to serialize writes to a given mutable file or directory by a single gateway / storage client.

As mentioned in ticket:265#comment:4, this does not apply to concurrent reads and writes -- the read may fail rather than obtaining some snapshot of the file or directory.

Clients using filesystem-like interfaces such as SFTP or FUSE may not expect such failures. At the time of writing, the SFTP documentation at wiki:SftpFrontend incorrectly claims that readers will get a snapshot of the file. (For mutable files, this problem applies directly to the file; for immutable files it applies to the parent directory when that is mutable.)

Change History (10)

comment:1 in reply to: ↑ description Changed at 2010-06-29T01:00:46Z by davidsarah

Replying to davidsarah:

At the time of writing, the SFTP documentation at wiki:SftpFrontend incorrectly claims that readers will get a snapshot of the file. (For mutable files, this problem applies directly to the file; for immutable files it applies to the parent directory when that is mutable.)

This doc is fixed by wiki:SftpFrontend?action=diff&version=47&old_version=46 .

Version 0, edited at 2010-06-29T01:00:46Z by davidsarah (next)

comment:2 follow-up: Changed at 2010-06-29T01:25:31Z by zooko

Is it clear to readers of wiki:SftpFrontend that "concurrent" accesses through a single gateway will get serialized? Should it be?

comment:3 in reply to: ↑ 2 Changed at 2010-06-29T01:49:26Z by davidsarah

Replying to zooko:

Is it clear to readers of wiki:SftpFrontend that "concurrent" accesses through a single gateway will get serialized? Should it be?

When sshfs is used, there should be a single sshfs mount: wiki:SftpFrontend?action=diff&version=50&old_version=49

I don't want to make statements about serialization in the docs that are stronger than what is actually implemented. I think wiki:SftpFrontend is now accurate, even if it doesn't quite give the full story.

Last edited at 2010-06-29T01:50:48Z by davidsarah (previous) (diff)

comment:4 Changed at 2010-10-24T16:38:48Z by davidsarah

  • Keywords integrity added

comment:5 Changed at 2011-07-23T00:08:57Z by davidsarah

  • Keywords drop-upload added

This improvement would be useful for the drop-upload feature, because you can't really avoid the possibility of concurrent reads and writes on the upload directory if you want to be able to read it while it is still active.

comment:6 Changed at 2011-08-03T23:15:04Z by davidsarah

  • Summary changed from allow uncoordinated reads and writes of a mutable file or directory locally to allow uncoordinated reads concurrent with writes of a mutable file or directory locally

comment:7 Changed at 2015-06-01T16:11:09Z by daira

  • Keywords magic-folder added

Add magic-folder keyword to all drop-upload tickets.

comment:8 Changed at 2015-10-27T01:32:50Z by daira

  • Description modified (diff)

This does not affect the intended Magic Folder design, since a client should not read its own DMD concurrently with writing it. It reads its own DMD on start-up, and other clients' DMDs on each scan, but it should not write its own DMD until after the start-up scan.

However, I'm not sure that this is this is not currently implemented correctly. Filed #2553 to track it.

Last edited at 2015-10-30T09:15:39Z by daira (previous) (diff)

comment:9 Changed at 2015-10-30T00:53:59Z by daira

  • Keywords reliability added; drop-upload removed

comment:10 Changed at 2015-12-07T15:15:13Z by daira

  • Keywords magic-folder removed
Note: See TracTickets for help on using tickets.