Re: btrfs-image hash collision option, super slow

2017-11-13 Thread Chris Murphy
On Mon, Nov 13, 2017 at 1:02 AM, Piotr Pawłow wrote: > W dniu 13.11.2017 o 04:42, Chris Murphy pisze: >> Strange. I was using 4.3.3 and it had been running for over 9 hours at >> the time I finally cancelled it. > > If you're compiling from source, the usual advice would be to

Re: btrfs-image hash collision option, super slow

2017-11-13 Thread Piotr Pawłow
W dniu 13.11.2017 o 04:42, Chris Murphy pisze: > Strange. I was using 4.3.3 and it had been running for over 9 hours at > the time I finally cancelled it. If you're compiling from source, the usual advice would be to "make clean" and make sure you're using the correct executable. If your fs is

Re: btrfs-image hash collision option, super slow

2017-11-12 Thread Chris Murphy
On Sun, Nov 12, 2017 at 7:05 AM, Piotr Pawłow 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

Re: btrfs-image hash collision option, super slow

2017-11-12 Thread Duncan
Piotr Pawłow posted on Sun, 12 Nov 2017 15:05:44 +0100 as excerpted: >> 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

Re: btrfs-image hash collision option, super slow

2017-11-12 Thread Piotr Pawłow
>>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

Re: btrfs-image hash collision option, super slow

2017-11-11 Thread Chris Murphy
On Sat, Nov 11, 2017 at 5:42 PM, Hugo Mills wrote: > On Sat, Nov 11, 2017 at 05:18:33PM -0700, Chris Murphy wrote: >> OK this might be in the stupid questions category, but I'm not >> understanding the purpose of computing hash collisions with -ss. Or >> more correctly, why

Re: btrfs-image hash collision option, super slow

2017-11-11 Thread Hugo Mills
On Sat, Nov 11, 2017 at 05:18:33PM -0700, Chris Murphy wrote: > OK this might be in the stupid questions category, but I'm not > understanding the purpose of computing hash collisions with -ss. Or > more correctly, why it's taking so much longer than -s. > > It seems like what we'd want is every