Hi folks, Attached is a tarball that adds the CRC infrastructure to xfsprogs. It is basically a port of the kernel changes, and sits on top of the V2 tarball for the kernel code sync posted here: http://oss.sgi.com/pipermail/xfs/2013-May/025941.html This tarball contains the following commits: libxfs: add crc format changes to generic btrees xfsprogs: add crc format chagnes to ag headers libxfs: change quota buffer formats libxfs: add version 3 inode support libxfs: add support for crc headers on remote symlinks xfs: add CRC checks to block format directory blocks xfs: add CRC checking to dir2 free blocks xfs: add CRC checking to dir2 data blocks xfs: add CRC checking to dir2 leaf blocks xfs: shortform directory offsets change for dir3 format xfs: add CRCs to dir2/da node blocks xfs: add CRCs to attr leaf blocks xfs: split remote attribute code out xfs: add CRC protection to remote attributes xfs: add buffer types to directory and attribute buffers xfs: buffer type overruns blf_flags field xfs: add CRC checks to the superblock xfs: implement extended feature masks xfsprogs: Add verifiers to libxfs buffer interfaces. xfsprogs: Support new AGFL format mkfs: fix realtime device initialisation [ I just noticed I need to update all the commit prefixes on the patch titles (from "xfs:" to "libxfs:"), but that's a minor issue right now. ] This series builds a fully working xfsprogs package, but does not support CRC enabled filesystems at all. It runs through xfstests without any new regressions for standard configurations (i.e. no rt device, internal log), but unlike previous patch sets will not immediately SEGV if you use external log devices or rt devices. I don't think there are any new regressions even with external devices, but I have not run enough iterations to say for sure. Most of these patches are simply ports from the kernel patches to match the libxfs structure, so there aren't any real surprises there. There are some small changes in various parts outside libxfs to ensure everything compiles as each patch is applied, but no attempt has been made to ensure that each patch results in a fully working xfsprogs package. Instead, the last 3 patches in the series hook up all the new bits and fix issues that make stuff break. The verifier hookup can't easily be done in any of the other patches simply because it requires lots of libxfs specific infrastructure changes. I may not have found all the places where verifiers can be added, but that's not a major concern until CRCs are enabled (i.e. the next patchset). The "xfsprogs: Support new AGFL format" patch can probably be folded into the "xfsprogs: add crc format chagnes to ag headers" patch which introduces the bugs being fixed, but I left it separate for testing. Similarly, the rt dev fixes probably belong in the kernel sync patchset, but I only came across that when testing rt devices a couple of days ago and just dumping it here means I don't need to post a new kernel sync tarball right now. ;) If people want me to, I can post an aggregate tarball of both sets of patches. This patches up to the point seem pretty well stabilised, so I don't see there being many changes up to them after this point. That, of course, will change when I start finding CRC format related bugs, but I'd prefer to keep those fixes separate so the userspace code has the same series of changes committed for the shared kernel/libxfs code. Hence I expect there will be quite a few patches in the next series (the "add CRC functionality" series) that fix bugs in the code introduced in this patch series.... Comments, thoughts, flames, bug reports and pictures of puppies all welcome. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
Attachment:
xfsprogs-crc-sync-patchset.tar.gz
Description: Binary data
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
