HDDS-4333. [OEP] Support append operation

[smengcl]

Generated-by: Codex (GPT-6 Astra), Claude Code (Fable 5.1)

What changes were proposed in this pull request?

Add an Ozone Enhancement Proposal for FileSystem.append() support in OzoneFS (ofs:// and o3fs://), as hadoop-hdds/docs/content/design/append.md plus four diagrams. This is a design doc for discussion only. No code changes.

Summary of the proposal:

• Reopen a closed file for a single appender. Existing blocks stay immutable and appended bytes go to newly allocated blocks, so no old block or closed container is reopened.
• Ownership is an append session recorded on the committed and open records in the existing OM tables, with a renewable lease, fencing of stale sessions, and explicit retry and recovery behavior. No new append table and no general block reference counting.
• RATIS and RATIS Streaming keep their existing hflush/hsync behavior. EC append publishes on close only.
• FSO is supported. LEGACY is included if its adaptations stay small. OBJECT_STORE buckets reject filesystem append.
• Snapshots keep reading their captured lengths, and deletion reclaims only the blocks that no snapshot references.
• Gated by an OM layout feature and ozone.om.append.enabled, disabled by default.

Out of scope: truncate, concat, random writes, concurrent appenders, native S3 or object append, EC hflush/hsync.

The doc also covers rename and other namespace operations during an open append, quota accounting, performance considerations, alternatives, the implementation sequence, and a validation plan. It builds on the earlier design in #1515, which was closed without merging.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-4333

How was this patch tested?

Docs only, no tests.

🤖 Generated with Claude Code

[Copilot]

Copilot wasn't able to review any files in this pull request. Check if the Files changed in this pull request are included in default exclusions.