>> It could definitely be improved -- I believe there are some good >> (but non-trivial) algorithms for finding preimages for CRC32 checksums >> out there. It's just that btrfs-image doesn't use them.
I implemented a faster method using a reverse CRC32 table, which is in btrfs-progs since release 4.13.1. On my 20GB root fs SSD: # echo 3 >/proc/sys/vm/drop_caches && time btrfs-image -s /dev/mapper/pp-root /dev/null >/dev/null 2>&1 real 0m22,023s user 0m14,812s sys 0m2,508s # echo 3 >/proc/sys/vm/drop_caches && time btrfs-image -ss /dev/mapper/pp-root /dev/null >/dev/null 2>&1 real 0m31,977s user 0m17,984s sys 0m2,632s Slower, but not 2 orders of magnitude slower :) > The other part I'm not groking is that some filenames fail with: > > WARNING: cannot find a hash collision for 'Tool', generating garbage, > it won't match indexes Unfortunately there are no CRC32 collisions for any file name having 4 or less characters when you have to keep the same file name length, and there may be no collisions for longer file names when you limit the result to ASCII only. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
