yandrey321 commented on PR #11328: URL: https://github.com/apache/ozone/pull/11328#issuecomment-5878649969
> I'm not sure about this one. This PR basically depends on the assumption that only request executes at a time. However, we are planning to move away to parallel execution framework, in which case this could break: https://issues.apache.org/jira/browse/HDDS-11898 Master is safe at these five FSO writers only because the whole body runs under the bucket write lock — it is serialized, not concurrency-safe. Under HDDS-11897 they have to be revisited either way, and the epic already owns that: the design doc scopes Phase 1 to OBS ("the refactoring of the transaction processing in the OBS bucket does not affect the FSO bucket"), and "Implement the FSO granular locking" is its own later item. So this PR doesn't add migration work that wasn't already on that list. One input for that item, from doing this work. The proposed OBS table is per-key (WriteLock: Key Name, rename WriteLock: sort(Key Name1, Key Name 2)), which is sufficient because both are flat-key predicates. FSO has two that aren't key predicates at all: rename's OMFileRequest.verifyToDirIsASubDirOfFromDirectory — a relationship over the directory tree. A concurrent rename can invalidate it after the check and leave a directory as its own ancestor. delete's OMFileRequest.hasChildren — a range predicate over the subtree. A concurrent create can add a child after the scan, and the delete orphans it. Both need a lock covering a subtree/prefix rather than a key, independent of this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
