>> (вздыхает) как я уже писал, человеки, выбирающие в качестве хэш-функции crc32 о
>> хэш-функциях знают примерно столько же, сколько я о балете. доверять им ссыкатна.
> А ты посмотри какие хэш-функции применяются в хэш-таблицах и тому подобной байде,
> когда криптостойкость не является ключевым требованием (хорошая криптостойкость сильно
> сажает скорость алгоритма как правило, т.к. требует множество раундов для тасовки
> данных).я тебе сейчас секрет открою: «хорошая криптостойкость» совершенно не обязательна для хэш-функции. просто так получается, что криптостойкая функция автоматически обеспечивает и то, что от «обычной» хэш-функции требуется: avalanche effect. однако есть хэш-функции, которые не проходят кучу раундов, но при этом таки обеспечивают оный avalanche.
в данном сучае не мыслил не «как программер», а как кодер-недоучка, у которого не хватило мозга элементарно спросить гугль про то, стоит ли использовать crc32 как хэш-функцию для хэш-таблиц, и если нет, то почему и какие предлагаются замены. и нашёл бы он, например, товарища Боба Дженкинса, простенькая on-at-a-time которого сильно лучше для хэш-таблиц. а если бы ещё поискал, то и другие бы нашёл, даже с готовыми исходниками, которые посложнее, но и побыстрее — хотя в данном случае это вряд ли bottleneck.
а, соответственно, у меня есть основания предполагать, что и другие аспекты дизайна btrfs тоже брались «с потолка». сам я весь дизайн проверить не могу — в силу отсутствия соответствующих знаний, — но не доверяю. если люди профэйлили в том, что гуглится за считаные секунды (и что *обязан* знать любой, кто пишет реализацию хэш-таблиц), то вполне вероятно, что вещи посложнее у них ещё хуже «придуманы». нененене, это не случай «солонки», это «стою на асфальте я в лыжи обутый».
