Re: btrfs-image hash collision option, super slow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>>    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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux