On Thu, Nov 08, 2012 at 12:37:30AM +1100, Dave Chinner wrote: > These patches introduce the first little piece of the CRC picture. > The first patch introduces the calculation and checking functions, > as well as the superblock feature bit for CRCs. The superblock bit > is not set anywhere, not is it really needed for 3.8. There's no > real harm in introducing it now, and doing so means that the log > code can demonstrate how it will differentiate between advisory > warnings and fatal errors on CRC mistmatches during recovery. > > The second patch converts the log checksum code to use the CRCs and > enables it for *all* filesystems. This can be done because the log > header already has a CRC field in it, and for production kernels it > is guaranteed to be zeroed. Hence for production kernels, only > issuing a CRC mistmatch warning when the log header CRC field is non > zero means that people can upgrade to a kernel with this > functionality and not see any CRC mismatch warnings. > > Warnings look like: > > XFS (vda): log record CRC mismatch: found 0xa05866c2, expected 0xd9290110. > > ffffc90001088000: 00 00 00 14 00 00 00 00 69 01 00 00 6e 14 a5 3d ........i...n..= > ffffc90001088010: 00 00 00 10 69 00 00 00 4e 41 52 54 2a 00 00 00 ....i...NART*... > > > The only issue with this is that filesystems that were not cleanly > shut down on debug kernels will throw CRC mismatch warnings the > first time the are recovered after mount. After the first mount on > upgrade, the warnings won't happen again unless you downgrade to an > older debug kernel. I don't see this as a major problem - debug > kernels are not used in production, and anyone using a debug kernel > should be following this mailing list. ;) > > Anyway, the overhead is negliable - I don't see any measurable > impact on metadata heavy operations (cpu verhead or performance), > and the benefits of even advisory warnings on production kernels are > of significant benefit. e.g. the recent log buffer wrap recovery > problem would have triggered a CRC mismatch warning long before > the bad client id error was detected.... FWIW, perf indicates that the CPU overhead of the CRC overhead when unlinking files at around 60,000/s - a log write rate of about 15MB/s - is: 0.25% [kernel] [k] __crc32c_le When creating files at around 90,000/s, the log write rate is ~40-50MB/s, and the CPU overhead is: 0.74% [kernel] [k] __crc32c_le So roughly linear scaling of about 0.15% of 8p per 10MB/s. On a single CPU, that would be 1% CPU overhead per 10MB/s of log throughput. This was measured inside a VM running on a 2.5 year old 2.26GHz Xeon. The VM does not assert the sse4_2 cpu feature, so can not use the special CPU instruction to calculate the CRC as efficiently as the hardware allows.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
