Lines Matching refs:commit
56 | | | +-- 1st commit
63 | | | +-- 2nd commit
69 | | | +-- 3rd commit
83 commits. Each commit contains a variable number of metadata entries followed
88 aligned to our program block size. This means each commit may have padding for
147 | | | | +-- 1st commit
159 | | +-------------------+----| || +-- 2nd commit
169 | |---------+-------------------+ | |||| +-- 3rd commit
191 commit is valid. After XORing, this bit should always be zero.
193 At the end of each commit, the valid bit of the previous tag is XORed
195 the CRC tag to force the next commit to fail the valid bit test if it
198 2. The valid bit alone is not enough info to know if the next commit has been
200 so it's possible that the next commit had an attempted program that left the
203 To ensure we only ever program erased bytes, each commit can contain an
205 bytes in the next commit at the time it was erased.
212 | | +---. +-- current commit
223 | | | | +-- next commit
231 commit was attempted but failed due to power-loss.
261 first bit in a commit, and when converted to little-endian, the valid bit finds
707 can be updated by a commit to _any_ metadata pair in the filesystem.
787 Last but not least, the CRC tag marks the end of a commit and provides a
793 the first commit, this includes the revision count for the metadata block.
796 larger to pad the commit to the next program-aligned boundary.
821 any tags in the next commit.
833 bytes in the next commit at the time it was erased. This allows us to ensure
834 that we only ever program erased bytes, even if a previous commit failed due
837 When programming a commit, the FCRC size must be at least as large as the
843 commit was attempted but failed due to power-loss.
860 1. **FCRC size (32-bits)** - Number of bytes after this commit's CRC tag's
863 2. **FCRC (32-bits)** - CRC of the bytes after this commit's CRC tag's padding