Opened at 2010-06-29T00:52:26Z
Last modified at 2015-12-07T15:15:13Z
#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
comment:2 follow-up: ↓ 3 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.
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.
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
Replying to davidsarah:
This doc is fixed by wiki:SftpFrontend?action=diff&version=49&old_version=46 .