A few tens of nanoseconds in either case. That is spectacularly good performance. I'll take a hash designed by a hash expert any day over a cheap hack or something I rolled myself that seems to pass my tests. Been there, wish I'd had Siphash then. Using CRC for the hash was just a bad idea, Chris must have been having a bad day that day. Best time to fix it is now, it only gets harder later.
Posted Dec 14, 2012 15:27 UTC (Fri) by drag (subscriber, #31333)
[Link]
BTRFS folks responded that supporting other hashing algorithms is on their list of patches to apply.
A hash-based DOS attack on Btrfs
Posted Dec 15, 2012 2:11 UTC (Sat) by daniel (subscriber, #3181)
[Link]
Anyway, it is apparent that issue is not merely a linear increase in directory operation time, but a for-real bug that looks like some kind of live-lock. The hash can and should be fixed, because although the attack in question turned out to achieve something other than its original intent, there is no question that trivially being able to force hash collisions is a vulnerability.
The most important result here is not the inappropriateness of CRC as a hash, but that Btrfs is a complex beast, still in development, a critical bug was just exposed, and likely a few more remain. Given wide enough testing and continued developer commitment it will become stable, but today it is not. From where I sit, it looks like Ext4 will be wearing its standard Linux filesystem crown for some time yet.
A hash-based DOS attack on Btrfs
Posted Dec 15, 2012 6:17 UTC (Sat) by SEJeff (subscriber, #51588)
[Link]
Unless tux3 matured first *poke*
A hash-based DOS attack on Btrfs
Posted Dec 15, 2012 13:18 UTC (Sat) by vonbrand (subscriber, #4458)
[Link]
From a cursory look over, I'd say 220 *minutes* isn't just a bad hash degenerating to a linear search...