Hi folks, This RFC series brings write support to xfs_db for CRC enabled filesytsems. The series converts xfs_db to use libxfs for it's IO, adds awareness of verifiers and CRC validation to the IO stack and enables write support for v5 filesystem structures. The main infrastructure change is switching to libxfs-based IO instead of buffered block device IO. This means that xfs_db now switches to direct IO cached in it's own address space, meaning that when it runs it always starts with a cold cache and so we don't have problem with it reading stale cached data out of the kernel. With it using libxfs, we can also attach verifiers to the IO to validate structures and CRCs before we act on them. The fact that CRCs were passed or not is available to usres of the data that is read, and so programs like xfs_check can be made to fail if CRC validation fails on read of metadata. Finally, write support is enabled because now that all data buffers have verifiers they can recalculate CRCs on write. There's some special support for inodes and dquots, but they will still have CRCs recalculated before write IOs. Hence xfs_db won't corrupt v5 metadata now when you change a field value manually. There are still some issues with the libxfs support - there are some places where xfs_db re-reads the same block address with different buffer lengths, resulting in libxfs throwing a cache lookup badness warning. e.g: $ sudo xfs_db -c "push sb" -c "p crc" /dev/vdc 7fe16ab3f740: Badness in key lookup (length) bp=(bno 0x0, len 0 bytes) key=(bno 0x0, len 512 bytes) Version 5 superblock detected. xfsprogs has EXPERIMENTAL support enabled! Use of these features is at your own risk! crc = 0xfc7b42ec (correct) $ This shows a buffer at block 0 was created with zero length for some reason, but when we push the superblock onto the stack, it looks up a buffer of 512 bytes, not 0, and it throws an error. The experimental warning is being thrown by the superblock buffer verifier on detecting the v5 superblock version. And the CRC of the buffer is displayed as being correct as the verifier didn't throw a corruption error when it ran. This output currently causes all sorts of problems for xfstests - the root inode cluster is another that causes issues, and there are also cases occurring where cache purging on unmount is throwing warnings. Hence it's not yet ready for merge, but otherwise it seems to work reliably enough to use. Early review and testing would be helpful at this point. These changes also mean that we should be able to turn metadump back on, as it needs CRC write support for the obfuscation code to work on v5 filesystems. Patches will be coming shortly to do that. xfs_check is still an open question. I might just re-enable it and add CRC validation checks and see what falls out from that, without adding any extra validation for the v5 filesystem format bits... Comments, thoughts, flames? Cheers, Dave. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
