packaging
/
ostree
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #2083 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
parent 66527efcb8 ce5dfadbd7
commit a05c99d933
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 22 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
docs/manual/formats.md
View File

@ -22,8 +22,9 @@ where file/content objects are checksummed and managed individually.
The `archive` format simply gzip-compresses each content object. The `archive` format simply gzip-compresses each content object.
Metadata objects are stored uncompressed. This means that it's easy 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` to serve via static HTTP. Note: the repo config file still uses the
for historical reasons. 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 When you commit new content, you will see new `.filez` files appearing
in `objects/`. in `objects/`.

28
docs/manual/repo.md
View File

@ -31,13 +31,16 @@ regenerate it from source code.
A dirtree contains a sorted array of (filename, checksum) A dirtree contains a sorted array of (filename, checksum)
pairs for content objects, and a second sorted array of pairs for content objects, and a second sorted array of
(filename, dirtree checksum, dirmeta checksum), which are (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 ### Dirmeta objects
In git, tree objects contain the metadata such as permissions In git, tree objects contain the metadata such as permissions
for their children. But OSTree splits this into a separate for their children. But OSTree splits this into a separate
object to avoid duplicating extended attribute listings. object to avoid duplicating extended attribute listings.
These type of objects are stored as files ending with `.dirmeta`
in the objects directory.
### Content objects ### 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 `mmap()`ed, the content object has a separate internal header and
payload sections. The header contains uid, gid, mode, and symbolic payload sections. The header contains uid, gid, mode, and symbolic
link target (for symlinks), as well as extended attributes. After the 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 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 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 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. 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 The `bare-user` mode is a later addition that is like `bare` in that
are unpacked, but it can (and should generally) be created as 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 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 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 but want to generate root-owned content, as well as non-root container
systems. 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 `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 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 information is not applied anyway. Hence this mode may loose metadata.
that repos can be stored on filesystems which do not support extended The main advantage of `bare-user-only` is that repos can be stored on
attributes, such as tmpfs. filesystems which do not support extended attributes, such as tmpfs.
In contrast, the `archive` mode is designed for serving via plain In contrast, the `archive` mode is designed for serving via plain
HTTP. Like tar files, it can be read/written by non-root users. HTTP. Like tar files, it can be read/written by non-root users.