Lines Matching refs:blocks

53    Filesystems that don't take wear into account can easily burn through blocks
77 Here storage is divided into blocks, with each file being stored in a
78 collection of blocks. Without modifications, these filesystems are not
79 power-loss resilient, so updating a file is a simple as rewriting the blocks
258 on the filesystem. At the super-block level, littlefs is a CObW tree of blocks
303 Why two blocks? Well, logs work by appending entries to a circular buffer
305 incrementally program new data onto erased blocks, but we need to erase a full
309 We could make our logs larger than two blocks, but the next challenge is how
310 do we store references to these logs? Because the blocks themselves are erased
311 during writes, using a data structure to track these blocks is complicated.
313 pair. This has the added advantage that we can change out blocks in the
414 is where having two blocks becomes important, if we lose power we still have
597 blocks just requires adding the new block and no other blocks need to be
599 following blocks, but can reuse any blocks before it. Since most file writes
683 linked-lists. Each linked-list skips twice as many blocks as the previous,
705 littlefs uses a 32-bit word width, so our blocks can only overflow with
717 complicated. We can start with a summation that loops through all of the blocks
841 compact storage of data in COW blocks.
844 blocks come from?
852 the filesystem that is updated with free blocks. However, with power
854 help that any mistake in updating these structures can result in lost blocks
859 the free blocks on the disk. The block allocator operates much like a garbage
860 collector in a scripting language, scanning for unused blocks on demand.
883 '-------------------'----'-------------------'----'-- free blocks
896 Our block allocator needs to find free blocks efficiently. You could traverse
899 blocks per traversal.
921 allocation, we take blocks from the lookahead buffer. If the lookahead buffer
922 is empty, we scan the filesystem for more free blocks, populating our lookahead
924 blocks are allocated.
926 Here's what it might look like to allocate 4 blocks on a decently busy
927 filesystem with a 32 bit lookahead and a total of 128 blocks (512 KiB
928 of storage if blocks are 4 KiB):
931 fs blocks: fffff9fffffffffeffffffffffff0000
933 fs blocks: fffff9fffffffffeffffffffffff0000
935 fs blocks: fffffdfffffffffeffffffffffff0000
937 fs blocks: fffffffffffffffeffffffffffff0000
939 fs blocks: fffffffffffffffeffffffffffff0000
941 fs blocks: ffffffffffffffffffffffffffff0000
943 fs blocks: ffffffffffffffffffffffffffff0000
945 fs blocks: ffffffffffffffffffffffffffff0000
947 fs blocks: ffffffffffffffffffffffffffff0000
949 fs blocks: ffffffffffffffffffffffffffff8000
954 one or two passes are usually needed to find free blocks. Additionally, the
963 Wear leveling is the process of distributing wear across all blocks in the
968 1. Detection and recovery from bad blocks
969 2. Evenly distributing wear across dynamic blocks
973 Recovery from bad blocks doesn't actually have anything to do with the block
975 and evict bad blocks when they occur.
977 In littlefs, it is fairly straightforward to detect bad blocks at write time.
1174 that means that all blocks in our storage are bad, and we've reached the end of
1176 error. This is technically true, as there are no more good blocks, but as an
1219 all blocks in the storage, with the hope that no single block fails before the
1226 distribute wear over "dynamic" blocks. The can be accomplished by
1227 only considering unused blocks.
1230 distribute wear over both "dynamic" and "static" blocks. To make this work,
1231 we need to consider all blocks, including blocks that already contain data.
1235 perfectly, but it is distributed among the free blocks and greatly extends the
1246 is powered, in which case we allocate the blocks linearly, circling the device.
1309 Now that we have our building blocks out of the way, we can start looking at
1338 the CTZ skip-list, we find ourselves using a full 3 blocks. On most NOR flash
1339 with 4 KiB blocks, this is 12 KiB of overhead. A ridiculous 3072x increase.
1670 remove dir B from threaded linked-list, returning dir B to free blocks
1689 blocks in a metadata pair when the block goes bad or exceeds its allocated