Hi all, This is the sixth revision of a patchset that adds to xfsprogs support for tracking reverse-mappings of physical blocks to file and metadata (rmap); support for mapping multiple file logical blocks to the same physical block (reflink); and implements the beginnings of online metadata scrubbing. Given the significant amount of design assumptions that change with block sharing, rmap and reflink are provided together. There shouldn't be any incompatible on-disk format changes, pending a thorough review of the patches within. The first few libxfs patches resync the xfsprogs libxfs with the kernel libxfs so that the new feature development can branch off (roughly) the same code. All patches in the kernel patchset that touch libxfs are provided here individually, and implement the same code changes. Patches to the actual xfsprogs programs are also provided -- xfs_db, xfs_logprint, and xfs_metadump are taught to examine the new on-disk data structures; xfs_io now knows how to inject errors for tests; mkfs can format the new features; and xfs_repair has been taught to check its own observations against the existing rmapbt and refcountbt and to regenerate the two indices. At the very end of the patchset is an initial implementation of twin "fsmap" commands in xfs_db and xfs_io for offline and online analysis of the filesystem. The last patch implements xfs_scrub which performs (very) limited online checking of the filesystem. It should work on any disk-based filesystem, and if it detects XFS it can trigger the in-kernel metadata b+tree scrubbing. The very first patch is a tool that can analyze xfs_buf deadlocks from ftrace output, and the patches after that merge various kernel libxfs changes into the xfsprogs libxfs so that the rest of the patches apply consistently. If you're going to start using this mess, you probably ought to just pull from my github trees for kernel[1], xfsprogs[2], and xfstests[3]. There are also updates for xfs-docs[4]. The kernel patches should apply to dchinner's for-next; xfsprogs patches to for-next; and xfstest to master. The kernel git tree already has for-next included. The patches have been xfstested with x64, i386, and armv7l--arm64, ppc64, and ppc64le no longer boot in qemu. All three architectures pass all 'clone' group tests except xfs/128 (which is the swapext test), and AFAICT don't cause any new failures for the 'auto' group. This is an extraordinary way to eat your data. Enjoy! Comments and questions are, as always, welcome. --D [1] https://github.com/djwong/linux/tree/djwong-devel [2] https://github.com/djwong/xfsprogs/tree/djwong-devel [3] https://github.com/djwong/xfstests/tree/djwong-devel [4] https://github.com/djwong/xfs-documentation/tree/djwong-devel _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
