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

New Issue

tahoe-lafs · 2010-06-29T00:52:26Z

davidsarah commented

2010-06-29 00:52:26 +00:00

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 /tahoe-lafs/trac-2024-07-25/issues/5327#comment:-1, 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.)

In the fix to #265 in Tahoe v1.1, `MutableFileNode`s were made to serialize writes to a given mutable file or directory by a *single* gateway / storage client. As mentioned in [/tahoe-lafs/trac-2024-07-25/issues/5327](/tahoe-lafs/trac-2024-07-25/issues/5327)#[comment:-1](/tahoe-lafs/trac-2024-07-25/issues/1105#issuecomment--1), 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](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.)

tahoe-lafs added the

labels 2010-06-29 00:52:26 +00:00

tahoe-lafs added this to the undecided milestone 2010-06-29 00:52:26 +00:00

davidsarah commented

2010-06-29 01:00:46 +00:00

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=49&old_version=46 .

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/6167): > At the time of writing, the SFTP documentation at [wiki/SftpFrontend](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](wiki/SftpFrontend)?action=diff&version=49&old_version=46 .

zooko commented

2010-06-29 01:25:31 +00:00

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

Is it clear to readers of [wiki/SftpFrontend](wiki/SftpFrontend) that "concurrent" accesses through a single gateway will get serialized? Should it be?

davidsarah commented

2010-06-29 01:49:26 +00:00

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.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/1105#issuecomment-78345): > Is it clear to readers of [wiki/SftpFrontend](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](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](wiki/SftpFrontend) is now accurate, even if it doesn't quite give the full story.

davidsarah commented

2011-07-23 00:08:57 +00:00

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.

tahoe-lafs changed title 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

2011-08-03 23:15:04 +00:00

daira commented

2015-06-01 16:11:09 +00:00

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

daira commented

2015-10-27 01:32:50 +00:00

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.

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.

Sign in to join this conversation.