Lines Matching refs:and

24 making this available primarily to allow review and provide documentation. Note
28 and the code disagree, the code is right. That said we'll of course try hard to
29 keep this document up-to-date and accurate.
34 these files. It provides you with full access to the files, and will not
35 withhold any data. If you find a limitation, please ping us and we might add
42 format is much simpler to parse, but complete and accurate. Due to its
50 instead! This document is primarily for your entertainment and education.
54 the properties of a journal entry and so on. If not, please go and read up,
59 usually don't), and the same field might have multiple values assigned within
64 but received various compatible and incompatible additions since.
74 * All offsets, sizes, time values, hashes (and most other numeric values) are 64bit unsigned intege…
76 …he first 32bit integer it returns as higher 32bit part of the 64bit value, and the second one uses…
77 * All structures are aligned to 64bit boundaries and padded to multiples of 64bit
78 * The format is designed to be read and written via memory mapping using multiple mapped windows.
87 the file and start a new one. No further writes should be attempted to the
95 A reader should verify all offsets and other data as it reads it. This includes
96 checking for alignment and range of offsets in the file, especially before
99 A reader must interleave rotated and corrupted files as good as possible and
102 All fields marked as "reserved" must be initialized with 0 when writing and be
116 objects to the end of the file, and then links them up at front after that's
133 …a booboo.` but possibly including large or binary data, and always prefixed by the field name and …
186 the machine it is running on it should immediately rotate the file and start a
189 When journal file is first created the **file_id** is randomly and uniquely
198 immediately rotate the file and start a new one. If a writer is asked to write
200 Header, it shall immediately rotate the file and start a new one.
213 **tail_entry_seqnum** and **head_entry_seqnum** contain the sequential number
217 **tail_entry_realtime** and **head_entry_realtime** contain the wallclock
298 STATE_OFFLINE it should immediately rotate the file and start a new one,
301 After and before the state field is changed, `fdatasync()` should be executed on
308 entry (starting at 1) and are unique among all files which carry the same
313 among several files, such as the system journal and many per-user journals.
321 most basic ones that provide us with `mmap()` that is), and allow good
323 via `fdatasync()` should be enforced is after and before changing the **state**
325 barrier after appending and initializing new objects at the end of the file,
326 and before linking them up in the earlier objects.
329 the structural integrity of the file as they read it and handle invalid
332 values, and that they point to valid objects, with valid sizes and of the type
333 and hash value expected. All code must be written with the fact in mind that a
334 file with inconsistent structure might just be inconsistent temporarily, and
336 should only be linked up (and hence visible to readers) after it was
348 Note that inotify will not work on network file systems if reader and writer
375 currently knows three flags: OBJECT_COMPRESSED_XZ, OBJECT_COMPRESSED_LZ4 and
376 OBJECT_COMPRESSED_ZSTD. It is only valid for DATA objects and indicates that
382 headers and payload.
401 field name, a `=` and the field data. Example:
424 The **payload[]** field contains the field name and date unencoded, unless
476 An ENTRY object binds several DATA objects together into one log entry, and
480 the realtime timestamp, and **monotonic** the monotonic timestamp for the boot
487 `HEADER_INCOMPATIBLE_KEYED_HASH` flag set (and thus siphash24 the otherwise
490 quickly compare the contents of two entries, and to define a well-defined order
491 between two entries that otherwise have the same sequence numbers and
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
522 objects, respectively. DATA's and FIELD's next_hash_offset field are used to
525 Each file contains exactly one DATA_HASH_TABLE and one FIELD_HASH_TABLE
535 and create a new one.
556 arrays are strictly sorted by offsets on disk, and hence by their timestamps
557 and sequence numbers (with some restrictions, see above).
560 allocated and the **next_entry_array_offset** field of the old one pointed to
562 list. To optimize allocation and seeking, as entry arrays are appended to a
601 offsets to objects added later for the purpose of linked lists and suchlike)
607 encountered the HMAC should be verified and restarted. The tag object sequence
609 partially protected by the HMAC (i.e. seqnum and epoch is included, the tag
630 match is first identified, and then its data entry array chain traversed. The
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.
656 it should be appended and added to the data hash table. When a data field's data
658 the data field, and a field object be added if necessary. After all data fields
659 (and recursively all field names) of the new entry are appended and linked up
660 in the hashtables, the entry object should be appended and linked up too.
665 Before writing an object, time and disk space limits should be checked and
673 The hash tables for looking up fields and data should be quickly in the memory
674 cache and not hurt performance. All entries and entry arrays are ordered
675 strictly by time on disk, and hence should expose an OK access pattern on
688 between the previous and current entry when reading and hence should expose an