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

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