[
https://issues.apache.org/jira/browse/HDDS-4097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17183281#comment-17183281
]
Marton Elek commented on HDDS-4097:
-----------------------------------
Thanks to explain it [~bharat]. I am closer now, but still have some questions:
bq. >> 1. What does it mean from compatibility point of view? Will it work
exactly the same way as Amazon S3? Does it mean that we start to support a
different semantic when ozone.om.enable.filesystem.paths is turned on?
bq. > Yes, when ozone.om.enable.filesystem.paths, paths are treated as
filesystem paths, so we check file system semantics and normalize the path.
Does it mean that turning on`ozone.om.enable.filesystem.paths` breaking AWS s3
compatibility?
bq. (And also planning to make this bucket level property, instead of
cluster-wide, not yet finalized)
This bucket level settings sounds very cool.
bq. Related to 1 + 2. Is it possible to create the intermediate "dir" keys but
remove them from the list when listed from S3?
bq. Yes, it can be. But right now when this property is enabled, we show all
intermediate directories also. Arpit Agarwal brought a point that if we don;t
show intermediate keys, and when user tries to create a key with that
intermediate path it will fail, and the user will be confused intermediate
paths are not shown, and the user is not able to create a key.
bq. From usability point of view, we can show intermediate dirs. Do you see any
advantage or any other favorable points in hiding those when list operation? We
can revisit this if required.
I am fine to show them on o3fs/o3/ofs interfaces, but I would prefer to keep
the 100% AWS S3 compatibility. If it means that we need to hide the
intermediate directories *from s3 output* we might need that change.
bq. Not sure, what is meant here. Any more info will help to answer the
question.
Prefix table effort creates prefixes for each parent directories (AFAIK). Do we
need this code after a working prefix table? Will this concept be changed after
using prefix table?
And one more question:
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?
Seems to be harder to test both of the approaches...
> 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
