On Sun, Nov 12, 2017 at 7:05 AM, Piotr Pawłow <pp@xxxxxxxxxxx> wrote: > >>> 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 :) Strange. I was using 4.3.3 and it had been running for over 9 hours at the time I finally cancelled it. > >> 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. Gotcha. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
