Currently it is possible that we would receive, and dispatch to FDB, requests which we could predict will cause transaction conflicts. Multiple updates to an inode, or writes to the same area of a file.
We should consider implementing a locking scheme on our side, whereby we maintain inode-level locks to serialize these operations.
The necessary data structure wouldn't be totally trivial; we'd need some sort of weakly held map from inodes to dynamically created locks, which is itself locked, so that competing processes don't attempt to both create the lock for a given inode at the same time. (Remember to release the lock on the outer structure before attempting to take the lock you really want.)
Currently it is possible that we would receive, and dispatch to FDB, requests which we could predict will cause transaction conflicts. Multiple updates to an inode, or writes to the same area of a file.
We should consider implementing a locking scheme on our side, whereby we maintain inode-level locks to serialize these operations.
The necessary data structure wouldn't be totally trivial; we'd need some sort of weakly held map from inodes to dynamically created locks, which is itself locked, so that competing processes don't attempt to both create the lock for a given inode at the same time. (Remember to release the lock on the outer structure before attempting to take the lock you really want.)