1
0
mirror of https://github.com/ostreedev/ostree.git synced 2025-01-10 05:18:30 +03:00

Merge pull request from agners/doc-updates

Doc updates
This commit is contained in:
OpenShift Merge Robot 2020-04-24 14:07:52 +02:00 committed by GitHub
commit a05c99d933
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 22 additions and 11 deletions

View File

@ -22,8 +22,9 @@ where file/content objects are checksummed and managed individually.
The `archive` format simply gzip-compresses each content object.
Metadata objects are stored uncompressed. This means that it's easy
to serve via static HTTP. Note: this format used to be called `archive-z2`
for historical reasons.
to serve via static HTTP. Note: the repo config file still uses the
historical term `archive-z2` as mode. But this essentially indicates
the modern `archive` format.
When you commit new content, you will see new `.filez` files appearing
in `objects/`.

View File

@ -31,13 +31,16 @@ regenerate it from source code.
A dirtree contains a sorted array of (filename, checksum)
pairs for content objects, and a second sorted array of
(filename, dirtree checksum, dirmeta checksum), which are
subdirectories.
subdirectories. These type of objects are stored as files
ending with `.dirtree` in the objects directory.
### Dirmeta objects
In git, tree objects contain the metadata such as permissions
for their children. But OSTree splits this into a separate
object to avoid duplicating extended attribute listings.
These type of objects are stored as files ending with `.dirmeta`
in the objects directory.
### Content objects
@ -45,7 +48,13 @@ Unlike the first three object types which are metadata, designed to be
`mmap()`ed, the content object has a separate internal header and
payload sections. The header contains uid, gid, mode, and symbolic
link target (for symlinks), as well as extended attributes. After the
header, for regular files, the content follows.
header, for regular files, the content follows. These parts toghether
form the SHA256 hash for content objects. The content type objects in
this format exist only in `archive` OSTree repositories. Today the
content part is gzip'ed and the objects are stored as files ending
with `.filez` in the objects directory. Because the SHA256 hash is
formed over the uncompressed content, these files do not match the
hash they are named as.
The OSTree data format intentionally does not contain timestamps. The reasoning
is that data files may be downloaded at different times, and by different build
@ -73,20 +82,21 @@ designed to be the source of a "hardlink farm", where each operating
system checkout is merely links into it. If you want to store files
owned by e.g. root in this mode, you must run OSTree as root.
The `bare-user` is a later addition that is like `bare` in that files
are unpacked, but it can (and should generally) be created as
The `bare-user` mode is a later addition that is like `bare` in that
files are unpacked, but it can (and should generally) be created as
non-root. In this mode, extended metadata such as owner uid, gid, and
extended attributes are stored but not actually applied.
extended attributes are stored in extended attributes under the name
`user.ostreemeta` but not actually applied.
The `bare-user` mode is useful for build systems that run as non-root
but want to generate root-owned content, as well as non-root container
systems.
There is a variant to the `bare-user` mode called `bare-user-only`. Unlike
The `bare-user-only` mode is a variant to the `bare-user` mode. Unlike
`bare-user`, neither ownership nor extended attributes are stored. These repos
are meant to to be checked out in user mode (with the `-U` flag), where this
information is not applied anyway. The main advantage of `bare-user-only` is
that repos can be stored on filesystems which do not support extended
attributes, such as tmpfs.
information is not applied anyway. Hence this mode may loose metadata.
The main advantage of `bare-user-only` is that repos can be stored on
filesystems which do not support extended attributes, such as tmpfs.
In contrast, the `archive` mode is designed for serving via plain
HTTP. Like tar files, it can be read/written by non-root users.