Lines Matching refs:a
20 - littlefs is a block-based filesystem. The disk is divided into an array of
24 representing a null block address.
27 block size), littlefs also uses a program block size and read block size.
35 Metadata pairs form the backbone of littlefs and provide a system for
36 distributed atomic updates. Even the superblock is stored in a metadata pair.
38 As their name suggests, a metadata pair is stored in two blocks, with one block
39 providing a backup during erase cycles in case power is lost. These two blocks
40 are not necessarily sequential and may be anywhere on disk, so a "pointer" to a
43 On top of this, each metadata block behaves as an appendable log, containing a
49 The high-level layout of a metadata block is fairly simple:
82 Each metadata block contains a 32-bit revision count followed by a number of
83 commits. Each commit contains a variable number of metadata entries followed
84 by a 32-bit CRC.
99 issues. Uses a CRC-32 with a polynomial of `0x04c11db7` initialized
102 Entries themselves are stored as a 32-bit tag followed by a variable length
103 blob of data. But exactly how these tags are stored is a little bit tricky.
136 Here's a more complete example of metadata block containing 4 entries:
190 1. Each tag contains a valid bit used to indicate if the tag and containing
199 erased. We don't know the order bits will be programmed in a program block,
204 optional forward-CRC (FCRC). An FCRC contains a checksum of some amount of
230 If the FCRC is missing or the checksum does not match, we must assume a
261 first bit in a commit, and when converted to little-endian, the valid bit finds
274 into a 3-bit abstract type and an 8-bit chunk field. Note that the value
275 `0x000` is invalid and not assigned a type.
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
285 block gets a unique id which is used to associate tags with that file. The
286 special value `0x3ff` is used for any tags that are not associated with a
299 Creates a new file with this id. Note that files in a metadata block
300 don't necessarily need a create tag. All a create does is move over any
301 files using this id. In this sense a create is similar to insertion into
304 The create and delete tags allow littlefs to keep files in a directory
311 any files neighboring this id similar to a deletion from an imaginary
317 Associates the id with a file name and file type.
350 Initializes the id + name as a regular file.
357 Initializes the id + name as a directory.
359 Directories in littlefs are stored on disk as a linked-list of metadata pairs,
366 Initializes the id as a superblock entry.
368 The superblock entry is a special entry used to store format-time configuration
371 The name is a bit of a misnomer. While the superblock entry serves the same
372 purpose as a superblock found in other filesystems, in littlefs the superblock
373 does not get a dedicated block. Instead, the superblock entry is duplicated
374 across a linked-list of metadata pairs rooted on the blocks 0 and 1. The last
393 The contents of the superblock entry are stored in a name tag with the
428 is encoded in a 32-bit value with the upper 16-bits containing the major
444 The superblock must always be the first entry (id 0) in a metadata pair as well
446 entry can be read from a device using offsets alone.
457 example, appending a ctz-struct replaces an inline-struct on the same file.
462 Gives the id a directory data structure.
464 Directories in littlefs are stored on disk as a linked-list of metadata pairs,
481 The pointer to the next metadata-pair in the directory is stored in a tail tag,
528 Gives the id a CTZ skip-list data structure.
531 are stored in a skip-list in reverse, with a pointer to the head of the
535 How exactly CTZ skip-lists work is a bit complicated. A full explanation can be
539 2‍_ˣ_, that block contains a pointer to block _n_-2‍_ˣ_.
555 Note that the maximum number of pointers in a block is bounded by the maximum
557 in a minimum block size of 104 bytes.
583 Attaches a user attribute to an id.
585 littlefs has a concept of "user attributes". These are small user-provided
592 There are currently no standard user attributes and a portable littlefs
619 The metadata pair's tail pointer is used in littlefs for a linked-list
621 which indicates if the following metadata pair is a part of the directory
646 can cause this linked-list to become out of sync if a power-loss were to occur.
654 2. The linked-list may contain a metadata pair with a bad block that has been
683 Provides a tail pointer that points to the next metadata pair in the
686 In this case, the next metadata pair is not a part of our current directory
692 Provides a tail pointer that points to the next metadata pair in the
705 littlefs has a concept of "global state". This is a small set of state that
706 can be updated by a commit to _any_ metadata pair in the filesystem.
708 The way this works is that the global state is stored as a set of deltas
740 In the case of moves, the move state contains a tag + metadata pair describing
742 was lost during a move, and the file exists in two different locations. If this
747 In the case of operations to the threaded linked-list, a single "sync" bit is
748 used to indicate that a modification is ongoing. If this sync flag is set, the
786 Last but not least, the CRC tag marks the end of a commit and provides a
789 The first 32-bits of the data contain a CRC-32 with a polynomial of
790 `0x04c11db7` initialized with `0xffffffff`. This CRC provides a checksum for
797 In addition, the CRC tag's chunk field contains a set of flags which can
800 tags. This is used to guarantee that unwritten storage in a metadata block
822 2. **CRC (32-bits)** - CRC-32 with a polynomial of `0x04c11db7` initialized
831 Added in lfs2.1, the optional FCRC tag contains a checksum of some amount of
833 that we only ever program erased bytes, even if a previous commit failed due
836 When programming a commit, the FCRC size must be at least as large as the
841 If the FCRC is missing or the checksum does not match, we must assume a
863 when erased. Like the CRC tag, this uses a CRC-32 with a polynomial of