https://www.opennet.ru/openforum/vsluhforumID3/87740.html Опубликована (http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/) техника DoS-атаки на файловую систему Btrfs, манипулирующая коллизиями хэшей имён файлов. При создании примерно 500 файлов со случайными именами, их удаление происходит почти мгновенно. Но если выбрать имена файлов, вызывающих коллизии при их хэшировании, при удалении система начинает тратить чрезмерные ресурсы. Например, создав 500 файлов с именами, которые сводятся к 55 хэш-значениям crc32c, их удаление заняло настолько много времени, что в ходе эксперимента пришлось принудительно завершить процесс после того как его выполнение заняло 220 минут.<br><br><br>URL: http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=35593<br> https://www.opennet.ru/openforum/vsluhforumID3/87740.html#163 Fri, 21 Dec 2012 16:10:48 GMT &gt; Да вон на лисяре гражданин выкусил - элементарнейший бэдсектор, а солнце пришлось <br>&gt; закатывать вручную. Потому что fsck нету и не планируется.<br><br>Не поэтому. scrub бессилен на FAULTED-пуле. Но недавно появилась волшебная команда "zpool import -F" &#8212; дарю, пользуйся на здоровье и больше не неси чепухи про fsck.<br> https://www.opennet.ru/openforum/vsluhforumID3/87740.html#162 Thu, 20 Dec 2012 21:58:39 GMT &gt; хэш. crc32. на всякий случай отложил идею пощупать btrfs на 50 лет. <br><br>Лучше на 100. А то вдруг каким-то чудом доживешь еще? Как же тогда твой статус некрофила?<br> https://www.opennet.ru/openforum/vsluhforumID3/87740.html#161 Thu, 20 Dec 2012 18:24:51 GMT &gt; Блджад. Вот сразу видно жабиста. "Zero knowledge of underlying operations". Не узнает <br>&gt; твой "пул" до момента расчёта CRC вообще о том, что данные "не те". Они ему придут <br>&gt; уже искаженными. А то и еще хуже - посчитает гнилую CRC из нормальных данных, <br>&gt; и благополучно запишет на диск.<br><br>Ну что поделать. Не понимают жабисты как работают компьютеры. Это позволяет им красиво зафэйлить, картинно сев в лужу на элементарщине. Бывает.<br><br>&gt; А при чтении сильно удивится :) когда увидит порушенную "по CRC" цепочку <br>&gt; вроде бы нормально записавшихся данных. Причем начнет "откатываться"/"восстанавливаться", <br>&gt; что еще хуже, чем если бы просто прочитал "как есть".<br><br>Да вон на лисяре гражданин выкусил - элементарнейший бэдсектор, а солнце пришлось закатывать вручную. Потому что fsck нету и не планируется. Так что если механика драйвера ФС сбойнет - вообще все, финиш. Хэксэдитором колупай это монстрило. Особенно прикольно на многодисковом пуле с каким-нибудь сжатием и райдом будет :). Сани вообще любят маркетинговы https://www.opennet.ru/openforum/vsluhforumID3/87740.html#160 Thu, 20 Dec 2012 17:59:15 GMT &gt; Ориентируясь на скорость в среднем, а не worst case (о чем <br>&gt; обычно честно предупреждают). CRC32, очевидно, является хэш-функцией, сжимая все множество <br>&gt; входных значений до 32 битов (или сколько там у кого).<br><br>ага, а костыли &#8212; это такие ноги, только альтернативные и экономичные. но марафоны на костылях почему-то не бегают.<br><br>вообще-то в *нормальном* учебном заведении когда говорят про хэш-таблицы, рассказывают и про uniform distribution, и про avalanche, и &#8212; в том числе &#8212; почему люди, использующие crc32 в качестве хэш-функции для хэш-таблиц &#8212; форменные идиоты.<br><br>&gt; Ниоткуда не следует что ее нельзя юзать как функцию хэш-таблицы.<br><br>следует, причём напрямую: из изучения её свойств.<br><br>не надо больше про хэши в этом контексте, ок? а то позоришься не хуже изи.<br> https://www.opennet.ru/openforum/vsluhforumID3/87740.html#159 Thu, 20 Dec 2012 17:08:51 GMT &gt; Для hash table это в принципе вполне себе функция.<br><br>вот такие кулхацкеры и суют её в хэши, ага. сейчас я тебе скажу два словосочетания: &#171;avalanche test&#187; и &#171;uniform distribution test&#187;. да, это надо вбивать в гугель вместе с буквами &#171;crc32&#187;.<br><br>я надеюсь, ты не пишешь ничего сложнее приветмиров. или хотя бы не показываешь публике. потому что с таким уровнем компетенции&#8230; в других областях она у тебя не лучше, инфа 146%<br> https://www.opennet.ru/openforum/vsluhforumID3/87740.html#158 Thu, 20 Dec 2012 17:04:49 GMT хэш. crc32. на всякий случай отложил идею пощупать btrfs на 50 лет.<br> https://www.opennet.ru/openforum/vsluhforumID3/87740.html#157 Mon, 17 Dec 2012 22:24:57 GMT &gt;&gt; А, может, самба зачрутована.<br>&gt; Или запихана в LXC. В KVM-виртуалке.<br><br>... на бездисковом сервере. <br> https://www.opennet.ru/openforum/vsluhforumID3/87740.html#156 Mon, 17 Dec 2012 15:30:33 GMT &gt; При сбое любого компонента на пути данных ZFS пул немедленно завершает свою <br>&gt; работу. Это сделано намеренно, чтобы не разрушить пул окончательно.<br><br>Блджад. Вот сразу видно жабиста. "Zero knowledge of underlying operations". Не узнает твой "пул" до момента расчёта CRC вообще о том, что данные "не те". Они ему придут уже искаженными. А то и еще хуже - посчитает гнилую CRC из нормальных данных, и благополучно запишет на диск. <br><br>А при чтении сильно удивится :) когда увидит порушенную "по CRC" цепочку вроде бы нормально записавшихся данных. Причем начнет "откатываться"/"восстанавливаться", что еще хуже, чем если бы просто прочитал "как есть".<br><br>&gt; Ну а в ZFS свойство checksum для данных можно перевести в состояние <br>&gt; "off" и избавиться от проверки данных на лету. Что случится в <br>&gt; этом случае с быстродействием? Быстродействие вырастет незначительно, так как эта вещь <br>&gt; хорошо оптимизирована.<br><br>Спасибо, кэп.<br><br> https://www.opennet.ru/openforum/vsluhforumID3/87740.html#155 Mon, 17 Dec 2012 14:37:44 GMT &gt;&gt; Твой винт поддерживает хотя бы дедупликацию блоков ФС <br>&gt; Мммм... трудновато найти мазохиста, готового платить за дедуп 4+ кратным падением производительности. <br><br>А чего же тогда лезет в охотный ряд и сравнивает в принципе известные факты: "дедупликация тормозит", "обеспечение журналирования и данных и метаданных тормозит". Капитан Очевидность для тех кто в курсе, а для тех, кто не в курсе, герой-срывающий-покровы-с-гадкой-и-тормозной-технологии?<br><br>&gt;&gt; не говоря уж о сквозной целостности данных и метаданных?<br>&gt; Ты не поверишь - твоя система также не имеет никакой "сквозной целостности". <br>&gt; Сбой памяти/контроллера памяти/CPU угробит твою FS еще до расчета CRC, и <br>&gt; вся твоя целостность пойдёт лесом.<br><br>При сбое любого компонента на пути данных ZFS пул немедленно завершает свою работу. Это сделано намеренно, чтобы не разрушить пул окончательно.<br><br>&gt;&gt; Тогда включи хотя бы журналирование _данных_и_метаданных_ в своей Ext4 <br>&gt; Лично мне нужно только журналирование метаданных. Включать журнал данных имеет смысл