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
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
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
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
>>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
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
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