[ 
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

Reply via email to