Documentation/filesystems/xfs-self-describing-metadata.rst

14 adequate for supporting PB scale filesystems with billions of inodes, however it
24 For example, it is entirely possible to manually use xfs_db and a bit of
26 determine the root cause of a corruption problem, but it is still mainly a
28 weren't the ultimate cause of a corruption event. It may take a few hours to a
44 magic number in the metadata block, we have no other way of identifying what it
45 is supposed to be. We can't even identify if it is the right place. Put simply,
46 you can't look at a single metadata block in isolation and say "yes, it is
54 went wrong, but it is impossible to tell what order the blocks were linked into
74 numbers in the metadata objects. That is, if it has the current magic number,
75 the metadata isn't self identifying. If it contains a new magic number, it is
80 integrity checking. We cannot trust the metadata if we cannot verify that it has
83 block. If we can verify the block contains the metadata it was intended to
88 metadata blocks. CRC32c is also now hardware accelerated on common CPUs so it is
90 could be used, it is more than sufficient for our needs and has relatively
92 does really provide any extra value over CRC32c, but it does add a lot of
98 look at any other metadata. This means it needs to contain location information.
105 block belongs to. We already know the type, the location, that it is valid
106 and/or corrupted, and how long ago that it was last modified. Knowing the owner
107 of the block is important as it allows us to find other related metadata to
109 object, we don't know what inode it belongs to and hence have to walk the entire
111 no owner can be found (i.e. it's an orphan block), and so without an owner field
123 Self describing metadata also needs to contain some indication of when it was
126 metadata blocks based on modification times is important as it can indicate
132 space or still allocated if it is still referenced by its owner by looking at
139 Number (LSN) of the most recent transaction it was modified on written into it.
141 thing that resets it is running xfs_repair on the filesystem. Further, by use of
145 modification occurred between the corruption being written and when it was
156 The verification is completely stateless - it is done independently of the
157 modification process, and seeks only to check that the metadata is what it says
158 it is and that the metadata fields are within bounds and internally consistent.
167 that it should see, and the IO completion process verifies that the metadata
168 object matches what was expected. If the verification process fails, then it
170 error (same as for IO errors), and if it needs to take special action due to a
171 verification error it can do so by catching the EFSCORRUPTED error value. If we
176 whether CRC validating is necessary. If it is, the CRC32c is calculated and
183 is extensively verified and if it is OK we then update the LSN from the last
184 modification made to the object, After this, we calculate the CRC and insert it
217 	  header that contains the magic number has other information in it as
242 (or is not needed) it verifies the actual contents of the block.
246 the case it can't, the code is structured as follows::
327 update the LSN field (when it was last modified) and calculate the CRC on the
347 only addition here is to add the LSN and CRC to the inode as it is copied back
352 log recovery. So, it's gone unnoticed until now. This won't matter immediately -
353 repair will probably complain about it - but it needs to be fixed.