Lines Matching +full:block +full:- +full:number
1 .. SPDX-License-Identifier: GPL-2.0
44 magic number in the metadata block, we have no other way of identifying what it
46 you can't look at a single metadata block in isolation and say "yes, it is
52 understanding how things like cross linked block lists (e.g. sibling
65 location. This allows us to identify the expected contents of the block and
70 Luckily, almost all XFS metadata has magic numbers embedded already - only the
72 magic numbers. Hence we can change the on-disk format of all these objects to
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
83 block. If we can verify the block contains the metadata it was intended to
87 hence a 32 bit CRC is more than sufficient to detect multi-bit errors in
97 metadata block can be verified as being in the correct place without needing to
99 Just adding a block number to the metadata is not sufficient to protect against
100 mis-directed writes - a write might be misdirected to the wrong LUN and so be
101 written to the "correct block" of the wrong filesystem. Hence location
102 information must contain a filesystem identifier as well as a block number.
105 block belongs to. We already know the type, the location, that it is valid
107 of the block is important as it allows us to find other related metadata to
110 filesystem to find the owner of the block. Worse, the corruption could mean that
111 no owner can be found (i.e. it's an orphan block), and so without an owner field
121 freespace btree block written to the wrong AG).
125 analysis is how recently the block was modified. Correlation of set of corrupted
129 present that the run-time verification is not detecting.
133 when the free space btree block that contains the block was last written
135 block is more recent than the object and the object's owner, then there is a
136 very good chance that the block should have been removed from the owner.
138 To provide this "written timestamp", each metadata block gets the Log Sequence
139 Number (LSN) of the most recent transaction it was modified on written into it.
140 This number will always increase over the life of the filesystem, and the only
151 Validation of self-describing metadata takes place at runtime in two places:
153 - immediately after a successful read from disk
154 - immediately prior to write IO submission
156 The verification is completely stateless - it is done independently of the
159 As such, we cannot catch all types of corruption that can occur within a block
163 body, but in general most of the per-field validation is handled by the
175 The first step in read verification is checking the magic number and determining
182 Write verification is the opposite of the read verification - first the object
192 A typical on-disk structure needs to contain the following information::
195 __be32 magic; /* magic number */
211 - short btree blocks have a 32 bit owner (ag number) and a 32 bit block
212 number for location. The two of these combined provide the same
216 - directory/attribute node blocks have a 16 bit magic number, and the
217 header that contains the magic number has other information in it as
229 struct xfs_mount *mp = bp->b_mount;
231 if ((xfs_sb_version_hascrc(&mp->m_sb) &&
232 !xfs_verify_cksum(bp->b_addr, BBTOB(bp->b_length),
235 XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
242 (or is not needed) it verifies the actual contents of the block.
245 whether the magic number can be used to determine the format of the block. In
252 struct xfs_mount *mp = bp->b_mount;
253 struct xfs_ondisk_hdr *hdr = bp->b_addr;
255 if (hdr->magic != cpu_to_be32(XFS_FOO_MAGIC))
258 if (!xfs_sb_version_hascrc(&mp->m_sb)) {
259 if (!uuid_equal(&hdr->uuid, &mp->m_sb.sb_uuid))
261 if (bp->b_bn != be64_to_cpu(hdr->blkno))
263 if (hdr->owner == 0)
279 struct xfs_mount *mp = bp->b_mount;
280 struct xfs_ondisk_hdr *hdr = bp->b_addr;
282 if (hdr->magic == cpu_to_be32(XFS_FOO_CRC_MAGIC)) {
283 if (!uuid_equal(&hdr->uuid, &mp->m_sb.sb_uuid))
285 if (bp->b_bn != be64_to_cpu(hdr->blkno))
287 if (hdr->owner == 0)
289 } else if (hdr->magic != cpu_to_be32(XFS_FOO_MAGIC))
304 struct xfs_mount *mp = bp->b_mount;
305 struct xfs_buf_log_item *bip = bp->b_fspriv;
308 XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp, bp->b_addr);
313 if (!xfs_sb_version_hascrc(&mp->m_sb))
318 struct xfs_ondisk_hdr *hdr = bp->b_addr;
319 hdr->lsn = cpu_to_be64(bip->bli_item.li_lsn);
321 xfs_update_cksum(bp->b_addr, BBTOB(bp->b_length), XFS_FOO_CRC_OFF);
333 Inodes and dquots are special snowflakes. They have per-object CRC and
334 self-identifiers, but they are packed so that there are multiple objects per
335 buffer. Hence we do not use per-buffer verifiers to do the work of per-object
336 verification and CRC calculations. The per-buffer verifiers simply perform basic
337 identification of the buffer - that they contain inodes or dquots, and that
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.