On Sun, Nov 12, 2017 at 7:05 AM, Piotr Pawłow <p...@siedziba.pl> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
