Lines Matching refs:find
441 3. If our block is full of entries _and_ we can't find any garbage, then what?
515 find an alternative representation of the number of static and dynamic entries:
527 size to find a multiplicative cost:
663 We can find the runtime complexity by looking at the path to any block from
682 To find the storage overhead, we can look at the data structure as multiple
730 the [On-Line Encyclopedia of Integer Sequences (OEIS)][oeis], I managed to find
750 Now we can substitute into our original equation to find a more efficient
765 equation to find the offset. We run into a bit of a problem with integer
771 Now we can find both our block index and offset from a size in _O(1)_, letting
896 Our block allocator needs to find free blocks efficiently. You could traverse
954 one or two passes are usually needed to find free blocks. Additionally, the
980 correctly. If we find that the data on disk does not match the copy we have in
992 nothing prevents us from triggering a COW operation as soon as we find a bad
1172 We may find that the new block is also bad, but hopefully after repeating this
1173 cycle we'll eventually find a new block where a write succeeds. If we don't,
1338 the CTZ skip-list, we find ourselves using a full 3 blocks. On most NOR flash
1486 like what you find on other filesystems.
1995 If, after building our global state during mount, we find information