wip: turbo-analyze
This commit is contained in:
10
README.md
10
README.md
@@ -218,7 +218,7 @@ is `home_len`. The same logic applies to all the `stringdata` fields: there is
|
||||
a way to calculate their relative position from the length of the fields before
|
||||
them.
|
||||
|
||||
PackedUser employs two "simple" compression techniques:
|
||||
PackedUser employs two data-oriented compression techniques:
|
||||
- shells are often shared across different users, see the "Shells" section.
|
||||
- `name` is frequently a suffix of `home`. For example, `/home/vidmantas` and
|
||||
`vidmantas`. In this case storing both name and home is wasteful. Therefore
|
||||
@@ -331,10 +331,10 @@ will be pointing to a number `n ∈ [0,N-1]`, regardless whether the value was i
|
||||
the initial dictionary. Therefore one must always confirm, after calculating
|
||||
the hash, that the key matches what's been hashed.
|
||||
|
||||
`idx_*` sections are of type `[]u32` and are pointing to the respective
|
||||
`Groups` and `Users` entries (from the beginning of the respective section).
|
||||
Since User and Group records are 8-byte aligned, the actual offset to the
|
||||
record is acquired by right-shifting this value by 3 bits.
|
||||
`idx_*` sections are of type `[]u32` and are pointing from `hash(key)` to the
|
||||
respective `Groups` and `Users` entries (from the beginning of the respective
|
||||
section). Since User and Group records are 8-byte aligned, the actual offset to
|
||||
the record is acquired by right-shifting this value by 3 bits.
|
||||
|
||||
Database file structure
|
||||
-----------------------
|
||||
|
||||
Reference in New Issue
Block a user