xfs_db/xfs_check doesn't currently handle filesystems with multi-record inode chunks correctly. For example, do the following on a 64k page size arch such as ppc64: # mkfs.xfs -f -b size=64k <dev> # xfs_db -c check <dev> bad magic number 0 for inode 1152 bad magic number 0 for inode 1153 bad magic number 0 for inode 1154 bad magic number 0 for inode 1155 bad magic number 0 for inode 1156 bad magic number 0 for inode 1157 ... This boils down to a regression in the inode record processing code (scanfunc_ino()) in db/check.c. Specifically, the cblocks value can end up being zero after it is shifted by mp->m_sb.sb_inopblog (i.e., 64 >> 7 == 0 for an -isize=512 -bsize=64k fs). The xfs_check sparse inode processing code takes a unique approach from similar code in other areas such as metadump and repair. This was sufficiently confusing for me that I decided to start with a revert of the patch that introduced the regression and follow up with a patch that updates the inode record processing code to take a similar approach as used in metadump, for example. This approach processes inode chunks a cluster at a time on sparse inode enabled filesystems and skips the regions that are sparse according to the record holemask. The two patches could probably be squashed into one if that is desired, but I'm posting separately as it describes my workflow. This survives my testing thus far on sparse inode filesystems as well as multi-record chunk configurations. These multi-rec configurations don't exactly have a high test pass rate ;P but I haven't hit any regressions. BTW, I have noticed that xfs_check seems to also have memory issues with quotas on multi-inode-rec fs', but that seems to go much farther back and may just be a limitation of check. Brian Brian Foster (2): Revert "xfs_db: make check work for sparse inodes" xfs_check: process sparse inode chunks correctly db/check.c | 274 +++++++++++++++++++++---------------------------------------- 1 file changed, 92 insertions(+), 182 deletions(-) -- 2.5.5 _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
