Lines Matching full:it
10 adequate for supporting PB scale filesystems with billions of inodes, however it
20 For example, it is entirely possible to manually use xfs_db and a bit of
22 determine the root cause of a corruption problem, but it is still mainly a
24 weren't the ultimate cause of a corruption event. It may take a few hours to a
40 magic number in the metadata block, we have no other way of identifying what it
41 is supposed to be. We can't even identify if it is the right place. Put simply,
42 you can't look at a single metadata block in isolation and say "yes, it is
50 went wrong, but it is impossible to tell what order the blocks were linked into
70 numbers in the metadata objects. That is, if it has the current magic number,
71 the metadata isn't self identifying. If it contains a new magic number, it is
76 integrity checking. We cannot trust the metadata if we cannot verify that it has
79 block. If we can verify the block contains the metadata it was intended to
84 metadata blocks. CRC32c is also now hardware accelerated on common CPUs so it is
86 could be used, it is more than sufficient for our needs and has relatively
88 does really provide any extra value over CRC32c, but it does add a lot of
94 look at any other metadata. This means it needs to contain location information.
101 block belongs to. We already know the type, the location, that it is valid
102 and/or corrupted, and how long ago that it was last modified. Knowing the owner
103 of the block is important as it allows us to find other related metadata to
105 object, we don't know what inode it belongs to and hence have to walk the entire
107 no owner can be found (i.e. it's an orphan block), and so without an owner field
119 Self describing metadata also needs to contain some indication of when it was
122 metadata blocks based on modification times is important as it can indicate
128 space or still allocated if it is still referenced by its owner by looking at
135 Number (LSN) of the most recent transaction it was modified on written into it.
137 thing that resets it is running xfs_repair on the filesystem. Further, by use of
141 modification occurred between the corruption being written and when it was
152 The verification is completely stateless - it is done independently of the
153 modification process, and seeks only to check that the metadata is what it says
154 it is and that the metadata fields are within bounds and internally consistent.
163 that it should see, and the IO completion process verifies that the metadata
164 object matches what was expected. If the verification process fails, then it
166 error (same as for IO errors), and if it needs to take special action due to a
167 verification error it can do so by catching the EFSCORRUPTED error value. If we
172 whether CRC validating is necessary. If it is, the CRC32c is calculated and
179 is extensively verified and if it is OK we then update the LSN from the last
180 modification made to the object, After this, we calculate the CRC and insert it
213 header that contains the magic number has other information in it as
238 (or is not needed) it verifies the actual contents of the block.
242 the case it can't, the code is structured as follows:
323 update the LSN field (when it was last modified) and calculate the CRC on the
343 addition here is to add the LSN and CRC to the inode as it is copied back into
348 log recovery. So, it's gone unnoticed until now. This won't matter immediately -
349 repair will probably complain about it - but it needs to be fixed.