Arvados

Issues seem to be:

• Generating conflicts with self (longstanding bug #11553)
• Replacing collection entry with a new collection entry, but they have the same uuid, gets a new inode, old inode goes away, so then getpwd() errors out
• collection_record not updated with new one (this might be a straightforward omission)

"contents" response is returning past collections versions?

aws s3 sync --endpoint=https://collections.ce8i5.arvadosapi.com s3://ce8i5-4zz18-pe56veug61jpmds/ .

18719-fuse-fixes @ 97ace0ab8a33f488715909ba1058c790aeb0900b

Addresses the following bugs:

• group.contents appears to include previous version snapshots. Because the previous version typically has the same name as the head version, the snapshot ends up replacing the head in the directory listing.
• websockets also sends out a creation event for the snapshot. It appears that websockets currently doesn't provide enough of the collection record to be able to distinguish between a new collection and a snapshot of a past version (and FUSE wasn't aware of snapshots anyway). This produces a similar problem where the snapshot ends up replacing the head version because they have the same name.
• When triggering live updates based on websocket events, it would try to update a collection to a specific portable data hash, but this also ran into the issue of confusing the snapshot with the head version.
• when running update(), or on flush() after the user made a change to the collection, it did not update the internal copy of the collection record with the copy it got back from the update operation, as a result the special ".arvados#collection" was always stale
• When multiple files are being flushed at once, the commit_all() part of flush() can overlap, which can result in double attempts to delete a buffer block

Fixes:

• Filter snapshots from group.contents response
• Only invalidate directories based on websocket events (to be updated on next access), stop trying to be clever about applying incremental changes or updating to specific PDHs
• Change collection_record_file to use a callback, the callback flushes and then gets the latest collection record from Collection object
• Be more strategic about when to invalidate the collection_record_file
• Looking up ".arvados#collection" invalidates it and forces a refresh
• If a buffer block doesn't exist and we try to delete it, don't throw an error

developer-run-tests: #2899

Peter Amstutz wrote:

18719-fuse-fixes @ 97ace0ab8a33f488715909ba1058c790aeb0900b

Addresses the following bugs:

• group.contents appears to include previous version snapshots. Because the previous version typically has the same name as the head version, the snapshot ends up replacing the head in the directory listing.
• websockets also sends out a creation event for the snapshot. It appears that websockets currently doesn't provide enough of the collection record to be able to distinguish between a new collection and a snapshot of a past version (and FUSE wasn't aware of snapshots anyway). This produces a similar problem where the snapshot ends up replacing the head version because they have the same name.
• When triggering live updates based on websocket events, it would try to update a collection to a specific portable data hash, but this also ran into the issue of confusing the snapshot with the head version.
• when running update(), or on flush() after the user made a change to the collection, it did not update the internal copy of the collection record with the copy it got back from the update operation, as a result the special ".arvados#collection" was always stale
• When multiple files are being flushed at once, the commit_all() part of flush() can overlap, which can result in double attempts to delete a buffer block

Fixes:

• Filter snapshots from group.contents response
• Only invalidate directories based on websocket events (to be updated on next access), stop trying to be clever about applying incremental changes or updating to specific PDHs
• Change collection_record_file to use a callback, the callback flushes and then gets the latest collection record from Collection object
• Be more strategic about when to invalidate the collection_record_file
• Looking up ".arvados#collection" invalidates it and forces a refresh
• If a buffer block doesn't exist and we try to delete it, don't throw an error

developer-run-tests: #2899

I did some manual testing and this version is definitely more reliable.

Just one note:

• in services/fuse/arvados_fuse/__init__.py around line 480 a whole section of code is commented out, should it just be removed?

LGTM otherwise. Thanks for the new comments!