bharatviswa504 commented on a change in pull request #1411: URL: https://github.com/apache/hadoop-ozone/pull/1411#discussion_r485817494
########## File path: hadoop-hdds/docs/content/design/s3_hcfs.md ########## @@ -67,45 +66,100 @@ To solve the performance problems of the directory listing / rename, [HDDS-2939] [HDDS-4097](https://issues.apache.org/jira/browse/HDDS-4097) is created to normalize the key names based on file-system semantics if `ozone.om.enable.filesystem.paths` is enabled. But please note that `ozone.om.enable.filesystem.paths` should always be turned on if S3 and HCFS are both used which means that S3 and HCFS couldn't be used together with normalization. -## Goals +# Goals + + * Out of the box Ozone should support both S3 and HCFS interfaces without any settings. (It's possible only for the regular, fs compatible key names) + * As 100% compatibility couldn't be achieved on both side we need a configuration to set the expectations for incompatible key names + * Default behavior of `o3fs` and `ofs` should be as close to `s3a` as possible (when s3 compatibilty is prefered) + +# Possible cases to support + +There are two main aspects of supporting both `ofs/o3fs` and `s3` together: + + 1. `ofs/o3fs` require to create intermediate directory entries (for exapmle `/a/b` for the key `/b/c/c`) + 2. Special file-system incompatible key names require special attention + +The second couldn't be done with compromise. + + 1. We either support all key names (including non fs compatible key names), which means `ofs/o3fs` can provide only a partial view + 2. Or we can normalize the key names to be fs compatible (which makes it possible to create inconsistent S3 keys) + +HDDS-3955 introduced `ozone.om.enable.filesystem.paths`, with this setting we will have two possible usage pattern: + +| ozone.om.enable.filesystem.paths= | true | false +|-|-|-| +| create itermediate dirs | YES | NO | +| normalize key names from `ofs/o3fs` | YES | NO +| force to normalize key names of `s3` interface | YES (1) | NO +| `s3` key `/a/b/c` available from `ofs/o3fs` | YES | NO +| `s3` key `/a/b//c` available from `ofs/o3fs` | YES | NO +| `s3` key `/a/b//c` available from `s3` | AWS S3 incompatibility | YES + +(1): Under implementation - * Out of the box Ozone should support both S3 and HCFS interfaces without any settings. (It's possible only for the regular path) - * As 100% compatibility couldn't be achieved on both side we need a configuration to set the expectations in case of incompatible key names - * Default behavior of `o3fs` and `ofs` should be as close to `s3a` as possible +This proposal suggest to use a 3rd option where 100% AWS compatiblity is guaranteed in exchange of a limited `ofs/o3fs` view: Review comment: We also have another way right, an existing bucket can be exposed created via CLI to be exposed to S3, what semantics that bucket will get? >For buckets created via FS interface, the FS semantics will always take precedence Buckets creation is possible via only OFS, what about O3fs? >If the global setting is enabled, then the value of the setting at the time of bucket creation is sampled and that takes >effect for the lifetime of the bucket. A bucket created via Shell, when global flag (assuming ozone.om.enable.filesystem.paths=true), they will follow FS semantics and with slight S3 incompatibility. So, a bucket created via Shell, when global flag (assuming ozone.om.enable.filesystem.paths=false), they will follow S3 semantics and with broken FS semantics or completely disallow. Written from my understanding, as I have not got the complete context of the proposal. I might be missing somethings here. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: ozone-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: ozone-issues-h...@hadoop.apache.org
