You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@opendal.apache.org by "PsiACE (via GitHub)" <gi...@apache.org> on 2026/08/18 02:44:26 UTC
[PR] feat: add experimental managed layout v0 [opendal-ofs]
PsiACE opened a new pull request, #29:
URL: https://github.com/apache/opendal-ofs/pull/29
Draft. First layer of the stacked rewrite of #26.
The original implementation was produced with GPT-5.6-sol. Grok 4.6 did this split. I reviewed the result and take responsibility for it.
Related to #26. This is not a rebase of that branch. It follows the split requested there: land an iterable layout first, then sync, then the harness.
## Stacked PRs
```
layout v0 (this PR)
└── sync
└── harness
```
## What this PR is
The experimental v0 volume format and the RFC volume locator.
- `managed/0` with a shared data-segment target. No Isolated/Pack fork.
- `ofs volume create <name> --model managed --storage <url>`
- Local names resolve through `OFS_HOME`. No remote catalog.
- One `compose(&VolumeFormat)` entry. No product Cargo features.
Layout v0 is meant to change. It is not a compatibility promise.
## What this PR is not
Sync, GC, extensions, or the behavior harness. Those land in the next two PRs.
## Validation
- `cargo x lint`
- `cargo x check`
- `cargo x test`
- `cargo x licenses`
--
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.
To unsubscribe, e-mail: commits-unsubscribe@opendal.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] feat: add experimental managed layout v0 [opendal-ofs]
Posted by "Xuanwo (via GitHub)" <gi...@apache.org>.
Xuanwo commented on PR #29:
URL: https://github.com/apache/opendal-ofs/pull/29#issuecomment-5327612717
the first PR might need to split into more pieces. For example, I want to have a quick understanding about yinyang format frist.
--
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.
To unsubscribe, e-mail: commits-unsubscribe@opendal.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] feat: define managed format v0 [opendal-yinyang]
Posted by "PsiACE (via GitHub)" <gi...@apache.org>.
PsiACE closed pull request #29: feat: define managed format v0
URL: https://github.com/apache/opendal-yinyang/pull/29
--
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.
To unsubscribe, e-mail: commits-unsubscribe@opendal.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] feat: define managed format v0 [opendal-yinyang]
Posted by "Xuanwo (via GitHub)" <gi...@apache.org>.
Xuanwo commented on PR #29:
URL: https://github.com/apache/opendal-yinyang/pull/29#issuecomment-5475351147
After separating the domain model from the v0 persistence representation, I think the core can be reduced to the following model. This is a naming and modeling proposal only; it does not require changing the current wire format.
```text
Bootstrap
FsFormat
├── FsId
├── root: NodeId
├── decodings
└── head configuration
Versioning
FsHead
├── current: FsVersionRef
├── gc_epoch: GcEpoch
└── min_retained: VersionNumber
FsVersion
├── fs: FsId
├── number: VersionNumber
├── tree: Tree
└── commits: Commit[]
Commit
├── id: CommitId
└── version: VersionNumber
Logical
Tree = OrderedMap<Path, Node>
Node
├── id: NodeId
├── generation: Generation
├── attrs: NodeAttrs
└── Dir | File
Dir
└── entries_generation: Generation
File
├── version: FileVersionId
├── content: ContentId
└── parts: FilePart[]
FilePart
├── range: FileRange
├── source_offset: u64
└── source: FileSource
FileSource
├── stored: BlobRef
└── decoded: ContentId[]
Physical
BlobRef -> immutable bytes
```
The important boundaries are:
- `Path` and `NodeId` are independent identities: rename changes the path while preserving the node.
- `Node.generation` and `Dir.entries_generation` remain separate conflict scopes.
- `FileVersionId` identifies a content publication independently from metadata-only changes and from whether the logical bytes equal an older version.
- `FilePart` is a file-range mapping; `FileSource` is the independently verifiable and decodable source unit. One source may be reused by multiple parts through different offsets.
- `Commit { id, version }` is the durable fact used for idempotent retry and lost-response detection.
- `BlobRef` is the only physical concept: a persistent, verifiable reference to a contiguous byte region in an immutable blob.
The following are useful v0 persistence or codec structures, but not core domain concepts:
```text
TreeSnapshot
TreeEditBatch
CommitBatch
FileLayer / base and patch levels
BlobLocator
framed streams
inline / continuation
compaction weights and packing targets
```
Their projection is:
```text
FsVersion.tree -> TreeSnapshot + TreeEditBatch[]
FsVersion.commits -> CommitBatch[]
File.parts -> FileExtentMap + base/patch levels + inline/continuation
BlobRef -> ObjectRef | StreamRef | SegmentRangeRef
```
This also removes `Entry` and `FileMap` from the domain model: `Entry` is just the `(Path, Node)` element of `Tree`, while the materialized file contract is simply an exact cover by `FilePart[]`. The layered file map remains a v0 persistence strategy rather than a filesystem-domain abstraction.
--
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.
To unsubscribe, e-mail: commits-unsubscribe@opendal.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org