Lines Matching refs:and

9 structures and indexes on disk and the algorithms for iterating them are
14 metadata is the allocation group headers (SB, AGF, AGFL and AGI), while all
17 validating and repairing the structure, there are limits to what they can
18 verify, and this in turn limits the supportable size of an XFS filesystem.
20 For example, it is entirely possible to manually use xfs_db and a bit of
29 to analyse and so that analysis blows out towards weeks/months of forensic work.
30 Most of the analysis work is slow and tedious, so as the amount of analysis goes
32 concern for supporting PB scale filesystems is minimising the time and effort
42 you can't look at a single metadata block in isolation and say "yes, it is
43 supposed to be there and the contents are valid".
46 verification of metadata values, looking for values that are in range (and hence
47 not detected by automated verification checks) but are not correct. Finding and
54 quickly determine if the metadata is intact and can be ignored for the purpose
61 location. This allows us to identify the expected contents of the block and
62 hence parse and verify the metadata object. IF we can't independently identify
67 AGFL, remote symlinks and remote attribute blocks do not contain identifying
69 add more identifying information and detect this simply by changing the magic
72 self identifying and we can do much more expansive automated verification of the
78 integrity check, and this is done by adding CRC32c validation to the metadata
82 CRC32c was selected as metadata cannot be more than 64k in length in XFS and
86 could be used, it is more than sufficient for our needs and has relatively
87 little overhead. Adding support for larger integrity fields and/or algorithms
89 complexity and so there is no provision for changing the integrity checking
96 mis-directed writes - a write might be misdirected to the wrong LUN and so be
102 and/or corrupted, and how long ago that it was last modified. Knowing the owner
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
113 directory, attribute and extent tree blocks are all owned by an inode, whilst
114 freespace btree blocks are owned by an allocation group. Hence the size and
124 events that lead to the eventual failure, and even whether there are corruptions
131 block is more recent than the object and the object's owner, then there is a
136 This number will always increase over the life of the filesystem, and the only
139 checkpoint and hence have some idea of how much modification occurred between
140 the first and last instance of corrupt metadata on disk and, further, how much
141 modification occurred between the corruption being written and when it was
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
166 error (same as for IO errors), and if it needs to take special action due to a
171 The first step in read verification is checking the magic number and determining
172 whether CRC validating is necessary. If it is, the CRC32c is calculated and
176 buffer is considered corrupt and the EFSCORRUPTED error is set appropriately.
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
202 information, such as the superblock and AG headers.
207 	- short btree blocks have a 32 bit owner (ag number) and a 32 bit block
209 	  information as @owner and @blkno in eh above structure, but using 8
212 	- directory/attribute node blocks have a 16 bit magic number, and the
237 by checking the superblock of the feature bit, and then if the CRC verifies OK
322 modified in memory. If the metadata verifies OK, and CRCs are enabled, we then
323 update the LSN field (when it was last modified) and calculate the CRC on the
326 Inodes and Dquots
329 Inodes and dquots are special snowflakes. They have per-object CRC and
332 verification and CRC calculations. The per-buffer verifiers simply perform basic
333 identification of the buffer - that they contain inodes or dquots, and that
334 there are magic numbers in all the expected spots. All further CRC and
338 The structure of the verifiers and the identifiers checks is very similar to the
341 read out of the buffer and the struct xfs_inode is instantiated. The inode is
343 addition here is to add the LSN and CRC to the inode as it is copied back into