> crc32 не является криптохэшем :-) видимо что бы это узнать нужны дикие познания?

Внезапно, хэш-таблицы сами по себе вообще не требуют в общем случае использования именно криптостойких функций. И для них совергшенно нормально если будет некий процент коллизий. Покуда он небольшой - это мало замедляет работу таблицы. Это считается штатным развитием событий и как правило явно обрабатывается, так что столкнувшиеся записи тем не менее сохраняются и доступны. А вот то что специально нагенеренные оптом коллизии в хэш-таблице можно абузануть для сильного торможения работы чего-либо с злонамеренной целью - намного менее очевидный факт. Требующий не программерского мышления а хакерского. Не "как закрепить рельсу на полотне", а "как сделать так чтобы рельсу не унес первый встречный козел, голыми руками, за минуту". Редкий программер мыслит именно в таком контексте. Где-то это и так прокатывает. А где-то случаются различные приколы.

> к конкретному алгоритму - так будет лучше?

Отмазался, типа? :)

> формулировка нормальная - только с тем как используются хэш при построении файловых
> систем - вы не знакомы.

Нифига себе апломба. А откуда такой масштабный вывод следует? Из вашего немеряного апломба? Других предпосылок не вижу.

> Знакомы только с хэшированными списками - но есть и другие варианты - с другими болячками.

Кто вам сказал что я знаком только с хэш-таблицами? Вы сами придумали?

> будет слишком много - затраты на модификацию этих блоков - могут
> быть очень и очень большими. (split, merge blocks - и создание

Ну спасиб, Капитан. Что бы я без вас делал? А еще можно b-деревья юзать, например. Нет хэш-функции - нет проблем с ней. Зато других проблем есть.

> (как и увеличением размера хэша) - можно только усложнить подбор имен дающих колизию.

Ну так если подобрать коллизию не получится - стало быть и проблема отсутствует. Что мне там не нравится - так это 220 минут взвиса. Похоже на то что алгоритм совсем где-то взвис. Т.е. там видимо еще и просто баг где-то порылся.