Lines Matching refs:of

10 _Note that this document describes the binary on-disk format of journals only.
12 For transfer of journal data across the network there's the [Journal Export Format](JOURNAL_EXPORT_…
23 This document explains the basic structure of the file format on disk. We are
27 only ultimately authoritative description of the format, so if this document
28 and the code disagree, the code is right. That said we'll of course try hard to
31 Instead of implementing your own reader or writer for journal files we ask you
39 API our recommendation is to make use of the [Journal Export
46 you want to use as base of your project. You want our [C
53 This document assumes you have a basic understanding of the journal concepts,
54 the properties of a journal entry and so on. If not, please go and read up,
56 of journal
62 This document describes the current format of systemd 246. The documented
63 format is compatible with the format used in the first versions of the journal,
67 place instead of adopting an existing database implementation, please have a
75 * Offsets are always relative to the beginning of the file.
76 …ashlittle2()` with the first 32bit integer it returns as higher 32bit part of the 64bit value, and…
77 * All structures are aligned to 64bit boundaries and padded to multiples of 64bit
81 …nel/random/boot_id`) they belong to. They tend to be relative to the start of the boot, but aren't…
86 If any kind of corruption is noticed by a writer it should immediately rotate
91 If any kind of corruption is noticed by a reader it should try hard to handle
96 checking for alignment and range of offsets in the file, especially before
114 having been written once, with the exception of records necessary for
116 objects to the end of the file, and then links them up at front after that's
133 * A **DATA** object, which encapsulates the contents of one field of an entry, i.e. a string such a…
138 * An **ENTRY_ARRAY** object, which encapsulates a sorted array of offsets to entries, used for seek…
139 * A **TAG** object, consisting of an FSS sealing tag for all data from the beginning of the file or…
183 The first 8 bytes of Journal files must contain the ASCII characters `LPKSHHRH`.
185 If a writer finds that the **machine_id** of a file to write to does not match
193 boot id of the system.
195 The currently used part of the file is the **header_size** plus the
196 **arena_size** field of the header. If a writer needs to write to a file where
199 to a file with a header that is shorter than its own definition of the struct
203 this file. As objects are appended to the end of the file this counter is
211 counters of the objects of the specific types.
214 (see below) of the last or first entry in the file, respectively, or 0 if no
218 timestamp of the last or first entry in the file, respectively, or 0 if no
221 **tail_entry_monotonic** is the monotonic timestamp of the last entry in the
222 file, referring to monotonic time of the boot identified by **boot_id**.
224 **data_hash_chain_depth** is a counter of the deepest chain in the data hash
231 Similar, **field_hash_chain_depth** is a counter of the deepest chain in the
237 The format is supposed to be extensible in order to enable future additions of
238 features. Readers should simply skip objects of unknown types as they read
245 fail, asking for an update of the software. Writers should refuse writing if
246 there's an unknown bit flag in either of these fields.
248 The file header may be extended as new features are added. The size of the file
250 unconditionally exist in all revisions of the file format, all fields starting
275 HEADER_INCOMPATIBLE_KEYED_HASH indicates that instead of the unkeyed Jenkins
312 of sequential numbers for easy interleaving even if entries are distributed
320 in order to facilitate storage on the most basic of file systems (well, the
325 barrier after appending and initializing new objects at the end of the file,
329 the structural integrity of the file as they read it and handle invalid
330 structure gracefully. (Checking what you read is a pretty good idea out of
332 values, and that they point to valid objects, with valid sizes and of the type
341 Clients intending to show a live view of the journal should use `inotify()` for
351 fall back to simple time based polling of the files (maybe recheck every 2s).
374 The **type** field is one of the object types listed above. The **flags** field
377 the data payload is compressed with XZ/LZ4/ZSTD. If one of the
380 flag must be set for the file as well. At most one of these three bits may be
381 set. The **size** field encodes the size of the object including all its
402 `_SYSTEMD_UNIT=foobar.service`. The **hash** field is a hash value of the
404 this is the siphash24 hash value of the payload, keyed by the file ID as stored
405 in the **file_id** field of the file header. If the flag is not set it is the
406 non-keyed Jenkins hash of the payload instead. The keyed hash is preferred as
411 a hash collision happens (in a singly linked list, with an offset of 0
413 the same field name from the FIELD object of the field used.
420 includes a practically unique string). **n_entries** is a counter of the total
421 number of ENTRY objects that reference this object, i.e. the sum of all
446 field value. Example: `_SYSTEMD_UNIT`. The **hash** field is a hash value of
448 siphash24 hash of the payload, or the non-keyed Jenkins hash.
453 field name. It is the head of a singly linked list using DATA's
479 The **seqnum** field contains the sequence number of the entry, **realtime**
483 The **xor_hash** field contains a binary XOR of the hashes of the payload of
485 contents of the entry, being independent of the order of the DATA objects in
490 quickly compare the contents of two entries, and to define a well-defined order
494 The **items[]** array contains references to all DATA objects of this entry,
499 number. For continuous parts of the file written during the same boot
519 The structure of both DATA_HASH_TABLE and FIELD_HASH_TABLE objects are
521 offsets to the head and tail of the singly linked list of the DATA and FIELD
540 number of fields should be pretty static as it depends only on developers'
555 Entry Arrays are used to store a sorted array of offsets to entries. Entry
560 allocated and the **next_entry_array_offset** field of the old one pointed to
563 chain of entry arrays they should increase in size (double).
568 One chain of entry arrays links up all entries written to the journal. The
569 first entry array is referenced in the **entry_array_offset** field of the
574 by a single ENTRY the first offset of the list is stored inside the DATA object
593 intervals a tag object is appended to the file. The tag object consists of a
598 increased with each tag. When calculating the HMAC of objects header fields
601 offsets to objects added later for the purpose of linked lists and suchlike)
603 verifier has to independently check these fields for consistency of
618 offsets in the data item array of the entry.
620 Listing entries without filter is done by traversing the list of entry arrays
626 added the time cost of seeking is O(log(n)*log(n)) if n is the number of
629 When seeking or listing with one field match applied the DATA object of the
633 If multiple matches are applied, multiple chains of entry arrays should be
635 offset of the entries, advancing in one can be directly applied to the others,
637 this is O(n) where n is the number of matching entries of the "loosest" match,
639 well-known fields, where the set of possible field values tend to be closely
640 related. Checking whether an entry matches a number of matches is efficient
641 since the item array of the entry contains hashes of all data fields
642 referenced, and the number of data fields of an entry is generally small (<
650 look up the FIELD object and follow the chain of links to all DATA it includes.
654 When an entry is appended to the journal, for each of its data fields the data
657 object is added, the field hash table should be checked for the field name of
659 (and recursively all field names) of the new entry are appended and linked up
677 given the nature of log data).
679 The disk access patterns of the binary search for entries needed for seeking
685 array of entry objects should be sorted by disk offset before