Hi folks, In making xfs_repair handle discontiguous directory blocks properly, it uncovered the fact that xfs_metadump has never handled discontiguous directory blocks properly. It doesn't handle discontiguous block format directories, and there are a couple of other cases where it is just says "too hard" and gives up, leading to un-obfuscated, corrupt or missing directory blocks in the metadump image. xfs/291 on CRC enabled filesystems was causing all three of these conditions to occur. This patchset fixes metadump to fully support all forms of discontiguous directory blocks. It changes the obfuscation code from reading and extent at a time and trying to slice and dice the objects within it - which will never work for objects that need CRC recalculation as a result of obfuscation - to dealing with individual objects. This does affect IO patterns somewhat - single large contiguous IOs turn into multiple smaller sequential IOs - but it means that we can use the object verifiers to do CRC recalculation correctly. It also means we can walk the extent tree to gather discontiguous extents into a single buffer to build an object fom multiple IOs. This is what all the other directory block IO does, and we need to do it here too. The result is that the code is simpler and more obvious in what it does - the "walk over a large extent" code is generic rather than object specific, and the discontiguous block code is separated from the single block object code. Hence both cases are clearer and easier to understand. And it works, unlike the old code. FWIW, with this fixed and xfs/291 passing, the only remaining outstanding work that is blocking a 3.2.0 release is to trap IO verifier errors in repair so we repair/rebuild objects based on CRC errors. Comments, flames, thoughts all welcome. Cheers, Dave. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs