Lines Matching refs:tag
102 Entries themselves are stored as a 32-bit tag followed by a variable length
106 this without duplicating the space for each tag, neighboring entries have their
115 | tag ~A |---> xor -> tag A | tag ~A |---> xor -> 0xffffffff
121 | tag AxB |---> xor -> tag B | tag AxB |---> xor -> tag A
127 | tag BxC |---> xor -> tag C | tag BxC |---> xor -> tag B
130 | | | | tag C
140 .-| revision count | tag ~A | \
145 | | tag AxB | data B | <--. |
149 | | | tag BxC | | <-.| |
154 | | tag CxCRC | CRC | || /
156 | | tag CRCxA' | data A' | || \
160 | | | tag CRCxA' | | || |
164 | | tag CRCxA'' | data A'' | <---. \
168 | | | tag A''xD | | < ||| |
172 | | | tag Dx| |||| |
188 Two things to note before we get into the details around tag encoding:
190 1. Each tag contains a valid bit used to indicate if the tag and containing
193 At the end of each commit, the valid bit of the previous tag is XORed
194 with the lowest bit in the type field of the CRC tag. This allows
195 the CRC tag to force the next commit to fail the valid bit test if it
239 global state. Even the CRCs used to mark the end of commits get their own tag.
241 Because of this, the tag format contains some densely packed information. Note
262 itself in byte 4. We could restructure the tag to store the valid bit lower,
264 complicated than just storing the tag in big-endian.
269 Metadata tag fields:
271 1. **Valid bit (1-bit)** - Indicates if the tag is valid.
273 2. **Type3 (11-bits)** - Type of the tag. This field is broken down further
277 1. **Type1 (3-bits)** - Abstract type of the tag. Groups the tags into
281 abstract types. type1+chunk+id form a unique identifier for each tag in the
284 3. **Id (10-bits)** - File id associated with the tag. Each file in a metadata
290 `0x3ff` indicates that this tag has been deleted.
300 don't necessarily need a create tag. All a create does is move over any
310 Deletes the file with this id. An inverse to create, this tag moves over
322 The chunk field in this tag indicates an 8-bit file type which can be one of
325 Currently, the name tag must precede any other tags associated with the id and
328 Layout of the name tag:
331 tag data
352 How each file is stored depends on its struct tag, which is described below.
361 the directory is stored in the struct tag, which is described below.
393 The contents of the superblock entry are stored in a name tag with the
394 superblock type and an inline-struct tag. The name tag contains the magic
395 string "littlefs", while the inline-struct tag contains version and
398 Layout of the superblock name tag and inline-struct tag:
401 tag data
409 tag data
478 The dir-struct tag contains only the pointer to the first metadata-pair in the
481 The pointer to the next metadata-pair in the directory is stored in a tail tag,
484 Layout of the dir-struct tag:
487 tag data
507 case, the file data is stored directly in the tag's data area.
509 Layout of the inline-struct tag:
512 tag data
559 Layout of the CTZ-struct tag:
562 tag data
590 the chunk field, and the user attribute itself can be found in the tag's data.
595 Layout of the user-attr tag:
598 tag data
661 Layout of the tail tag:
664 tag data
740 In the case of moves, the move state contains a tag + metadata pair describing
741 the source of the ongoing move. If this tag is non-zero, that means that power
750 reliably. The exact cases to check for are described above in the tail tag.
755 tag data
786 Last but not least, the CRC tag marks the end of a commit and provides a
791 all metadata since the previous CRC tag, including the CRC tag itself. For
797 In addition, the CRC tag's chunk field contains a set of flags which can
803 Layout of the CRC tag:
806 tag data
831 Added in lfs2.1, the optional FCRC tag contains a checksum of some amount of
844 Layout of the FCRC tag:
847 tag data
859 1. **FCRC size (32-bits)** - Number of bytes after this commit's CRC tag's
862 2. **FCRC (32-bits)** - CRC of the bytes after this commit's CRC tag's padding
863 when erased. Like the CRC tag, this uses a CRC-32 with a polynomial of