Lines Matching refs:size
29 size in mind.
64 size or number of files. This creates a unique challenge as even presumably
180 parallel, which comes with a code size cost. They also offer no protection
239 can't avoid these costs, _but_ if we put an upper bound on the size we can at
293 storage, in the worst case a small log costs 4x the size of the original data.
357 1. If our block is not full and the program size is small enough to let us
448 increasing the size of the log and dealing with the scalability issues
514 If we let ![r] be the ratio of static space to the size of our log in bytes, we
517 ![s = r (size/n)][metadata-formula2]
519 ![d = (1 - r) (size/n)][metadata-formula3]
524 ![cost = n + n (r (size/n) / ((1-r) (size/n) + 1))][metadata-formula4]
527 size to find a multiplicative cost:
552 of 4x the original size. I imagine users would not be happy if they found
679 storage overhead? Can the number of pointers exceed the size of a block? How do
691 Because our file size is limited the word width we use to store sizes, we can
693 block. If we set the overhead of pointers equal to the block size, we get the
694 following equation. Note that both a smaller block size (![B][bigB]) and larger
699 Solving the equation for ![B][bigB] gives us the minimum block size for some
702 1. 32-bit CTZ skip-list => minimum block size of 104 bytes
703 2. 64-bit CTZ skip-list => minimum block size of 448 bytes
707 in practice, most block sizes start at 512 bytes. As long as our block size
712 head block, the size of the skip-list, the index of the head block, and our
713 offset in the head block. But it's worth noting that each size maps to a unique
714 index + offset pair. So in theory we can store only a single pointer and size.
716 However, calculating the index + offset pair from the size is a bit
718 up until our given size. Let ![B][bigB] be the block size in bytes, ![w] be the
720 ![N][bigN] be the file size in bytes:
751 equation for file size:
771 Now we can find both our block index and offset from a size in _O(1)_, letting
772 us store CTZ skip-lists with only a pointer and size.
919 a brute force traversal. Instead of a bitmap the size of storage, we keep track
920 of a small, fixed-size bitmap called the lookahead buffer. During block
955 performance of the allocator can be optimized by adjusting the block size or
956 size of the lookahead buffer, trading either write granularity or RAM for
1233 As a tradeoff for code size and complexity, littlefs (currently) only provides
1302 life of a device simply by increasing the size of storage. And if more
1426 have a ~4x storage cost, so if our file is smaller than 1/4 the block size,
1470 Once the file exceeds 1/4 the block size, we switch to a CTZ skip-list. This
1472 the file grows in size.
1914 disk. For this reason, it's very important that we keep the size of global