mirror of
https://github.com/ostreedev/ostree.git
synced 2025-01-10 05:18:30 +03:00
commit
a05c99d933
docs/manual
@ -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/`.
|
||||
|
@ -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.
|
||||
|
Loading…
Reference in New Issue
Block a user