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.
137 tag contains a valid bit used to indicate if the tag and containing commit is
142 Here's a more complete example of metadata block containing 4 entries:
220 first bit in a commit, and when converted to little-endian, the valid bit finds
233 into a 3-bit abstract type and an 8-bit chunk field. Note that the value
234 `0x000` is invalid and not assigned a type.
240 abstract types. type1+chunk+id form a unique identifier for each tag in the
243 3. **Id (10-bits)** - File id associated with the tag. Each file in a metadata
244 block gets a unique id which is used to associate tags with that file. The
245 special value `0x3ff` is used for any tags that are not associated with a
258 Creates a new file with this id. Note that files in a metadata block
259 don't necessarily need a create tag. All a create does is move over any
260 files using this id. In this sense a create is similar to insertion into
263 The create and delete tags allow littlefs to keep files in a directory
270 any files neighboring this id similar to a deletion from an imaginary
276 Associates the id with a file name and file type.
309 Initializes the id + name as a regular file.
316 Initializes the id + name as a directory.
318 Directories in littlefs are stored on disk as a linked-list of metadata pairs,
325 Initializes the id as a superblock entry.
327 The superblock entry is a special entry used to store format-time configuration
330 The name is a bit of a misnomer. While the superblock entry serves the same
331 purpose as a superblock found in other filesystems, in littlefs the superblock
332 does not get a dedicated block. Instead, the superblock entry is duplicated
333 across a linked-list of metadata pairs rooted on the blocks 0 and 1. The last
352 The contents of the superblock entry are stored in a name tag with the
387 is encoded in a 32-bit value with the upper 16-bits containing the major
403 The superblock must always be the first entry (id 0) in a metadata pair as well
405 entry can be read from a device using offsets alone.
416 example, appending a ctz-struct replaces an inline-struct on the same file.
421 Gives the id a directory data structure.
423 Directories in littlefs are stored on disk as a linked-list of metadata pairs,
440 The pointer to the next metadata-pair in the directory is stored in a tail tag,
487 Gives the id a CTZ skip-list data structure.
490 are stored in a skip-list in reverse, with a pointer to the head of the
494 How exactly CTZ skip-lists work is a bit complicated. A full explanation can be
498 2‍_ˣ_, that block contains a pointer to block _n_-2‍_ˣ_.
514 Note that the maximum number of pointers in a block is bounded by the maximum
516 in a minimum block size of 104 bytes.
542 Attaches a user attribute to an id.
544 littlefs has a concept of "user attributes". These are small user-provided
551 There are currently no standard user attributes and a portable littlefs
578 The metadata pair's tail pointer is used in littlefs for a linked-list
580 which indicates if the following metadata pair is a part of the directory
605 can cause this linked-list to become out of sync if a power-loss were to occur.
613 2. The linked-list may contain a metadata pair with a bad block that has been
642 Provides a tail pointer that points to the next metadata pair in the
645 In this case, the next metadata pair is not a part of our current directory
651 Provides a tail pointer that points to the next metadata pair in the
664 littlefs has a concept of "global state". This is a small set of state that
665 can be updated by a commit to _any_ metadata pair in the filesystem.
667 The way this works is that the global state is stored as a set of deltas
699 In the case of moves, the move state contains a tag + metadata pair describing
701 was lost during a move, and the file exists in two different locations. If this
706 In the case of operations to the threaded linked-list, a single "sync" bit is
707 used to indicate that a modification is ongoing. If this sync flag is set, the
745 Last but not least, the CRC tag marks the end of a commit and provides a
748 The first 32-bits of the data contain a CRC-32 with a polynomial of
749 `0x04c11db7` initialized with `0xffffffff`. This CRC provides a checksum for
756 In addition, the CRC tag's chunk field contains a set of flags which can
759 tags. This is used to guarantee that unwritten storage in a metadata block
781 2. **CRC (32-bits)** - CRC-32 with a polynomial of `0x04c11db7` initialized