[ https://issues.apache.org/jira/browse/HDDS-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184936#comment-17184936 ]
Marton Elek commented on HDDS-4097: ----------------------------------- > S3, does allow creating files and directories with the same name and also it > does not follow/check any filesystem semantics. So, if we want object-store > semantics, this flag provides a fall back. So, I think we still need this, as > We cannot make 100% AWS S3 compatibility. Can you please add more information about this?. In current Ozone we guarantee 100% AWS compatibility and HCFS compatiblity at the same time. This is one of the biggest selling point (in addition to the scalability). If I understood well with this approach we either provider 100% AWS compatibility *OR* proper file system semantics. I think before the implementation it should be explained in more details 1. why is it impossible to provie AWS compatibility (what is the exact case, what the other options, etc.) 2. what is the use case of turning on this settings and why is it required Or (with repeating my previous comment): bq. Why do we need that specific settings at all? IF we can provide 100% AWS s3 compatibility with the new approach why is it required to be optional? Do you see any disadvantage of the new approach? *I would prefer to keep 100% AWS compatibility even with the new approach, unless we have very strong arguments why is it impossible* bq. Prefix table work changes the format it stores the key, but to break the path in to components still we need to normalize path when Thanks to explain it. I got it. > S3/Ozone Filesystem inter-op > ---------------------------- > > Key: HDDS-4097 > URL: https://issues.apache.org/jira/browse/HDDS-4097 > Project: Hadoop Distributed Data Store > Issue Type: New Feature > Reporter: Bharat Viswanadham > Assignee: Bharat Viswanadham > Priority: Major > Attachments: Ozone FileSystem Paths Enabled.docx, Ozone filesystem > path enabled.xlsx > > > This Jira is to implement changes required to use Ozone buckets when data is > ingested via S3 and use the bucket/volume via OzoneFileSystem. Initial > implementation for this is done as part of HDDS-3955. There are few API's > which have missed the changes during the implementation of HDDS-3955. > Attached design document which discusses each API, and what changes are > required. > Excel sheet has information about each API, from what all interfaces the OM > API is used, and what changes are required for the API to support > inter-operability. > Note: The proposal for delete/rename is still under discussion, not yet > finalized. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: ozone-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: ozone-issues-h...@hadoop.apache.org