Исходное сообщение
"Компания Oracle молча перевела man-руководства MySQL на..." Отправлено arisu, 20-Июн-13 11:32
>> доверять системе, разработчики которой считают, что crc — хорошая хэш-функция? нененене. > Для целей файловой системы и ее внутренних нужд? Нормальная вполне. нет. *ни для каких целей* crc не является «нормальной хэш-функцией». вообще ни для каких. если ты строишь дом с хреновым фундаментом, то отмаз «а, для наших целей покатит» — не проходит. ты совершенно не понимаешь сути проблемы, что ли? crc имеет херовый avalanche. очень херовый. на *любых* данных. что *в любом случае* приводит к херовой работе хэш-таблиц. это как взять скоростной скутер и воткнуть на него квадратные колёса. так вот фишка в том, что авторы btrfs, похоже, тоже этого не понимают. то есть, как минимум одну вещь они используют без понимания основ, которые дают в любом нормальном ВУЗе (или которые узнаёшь сам, как только начинаешь разбираться с вещью). и вот я не вижу причин, по которым такая вещь в системе должна быть всего одна. гораздо логичней предположить, что подобных граблей там раскидано изрядно. поэтому лично мне — учитывая сложность btrfs — совершенно не хочется доверять ей какие-либо данные, которые я не готов сразу потерять. а если я готов эти данные сразу потерять — то их проще тут же и удалить, и btrfs снова не нужна.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> доверять системе, разработчики которой считают, что crc — хорошая хэш-функция? нененене. >> Для целей файловой системы и ее внутренних нужд? Нормальная вполне. > нет. *ни для каких целей* crc не является «нормальной хэш-функцией». вообще ни > для каких. если ты строишь дом с хреновым фундаментом, то отмаз > «а, для наших целей покатит» — не проходит. > ты совершенно не понимаешь сути проблемы, что ли? crc имеет херовый avalanche. > очень херовый. на *любых* данных. что *в любом случае* приводит к > херовой работе хэш-таблиц. это как взять скоростной скутер и воткнуть на > него квадратные колёса. > так вот фишка в том, что авторы btrfs, похоже, тоже этого не > понимают. то есть, как минимум одну вещь они используют без понимания > основ, которые дают в любом нормальном ВУЗе (или которые узнаёшь сам, > как только начинаешь разбираться с вещью). > и вот я не вижу причин, по которым такая вещь в системе > должна быть всего одна. гораздо логичней предположить, что подобных граблей там > раскидано изрядно. поэтому лично мне — учитывая сложность btrfs — совершенно > не хочется доверять ей какие-либо данные, которые я не готов сразу > потерять. а если я готов эти данные сразу потерять — то > их проще тут же и удалить, и btrfs снова не нужна.
	Введите код, изображенный на картинке: