https://opennet.me/openforum/vsluhforumID3/84842.html Теодор Цо (Theodore Ts'o) представил (https://lkml.org/lkml/2012/6/1/220) порцию изменений в файловой системе Ext4, предложенных для интеграции в состав ядра Linux 3.5. Ключевым новшеством является обеспечение встроенной поддержки проверки целостности метаданных, реализованной в рамках инициативы по увеличению надёжности ФС Ext4. Для обеспечения новой функции в поле метаданных добавлен новый блок с контрольной суммой crc32 и соответственно изменена структура хранимых на диске мета-данных. <br><br><br>Контрольные суммы рассчитываются для суперблока, inode, битовых карт блоков, блоков дерева экстентов, htree-узлов, MMP-блоков, директорий и блоков с расширенными атрибутами. Также поддержка контрольных сумм добавлена в инфраструктуру журналирования jbd2 (Journaling block device), что позволит проверять целостность элементов журнала Ext4, а также отдельных коммитов и блоков данных, хранимых в журнале.<br><br><br>URL: https://lkml.org/lkml/2012/6/1/220<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=33996<br> https://opennet.me/openforum/vsluhforumID3/84842.html#213 Fri, 08 Jun 2012 18:54:33 GMT &gt; Проверяется все. Но если для данных - это выльется в загрузку CPU, <br>&gt; то для метаданных он выливается в увеличение времени выполнения операции.<br>&gt; Как уже писал - лучше бы T10 DIF/DIX запилили - хотя бы <br>&gt; проверка целостности (более частая операция) выполнялась бы аппаратно.<br><br>Просто вы написали "подсчет crc32 от такого потока - съедает 4 ядра и 12".<br>Вы невольно ввели людей в заблуждение, не указав, что идет подсчет ещё и для данных.<br>Система, обсуждаемая в топике, подсчитывает только метаданные.<br>Да, это создает доп. нагрузку и задержки.<br>Но насколько большую - неизвестно.<br>Нужно дождаться релиза и протестить.<br>К сожалению, ваш опыт тут неприменим, т.к. у вас другая система считает другие вещи.<br> https://opennet.me/openforum/vsluhforumID3/84842.html#212 Wed, 06 Jun 2012 03:30:51 GMT пример поиска в utf8 для grep-2.9:<br><br>$ wget -O - http://opennet.ru 2&gt;&1&#124;iconv -f koi8-r&#124;grep 'вар.ант'<br> &lt;TITLE&gt;OpenNet без "www" - минималистский вариант портала по открытому ПО, Linux, BSD и Unix системам&lt;/TITLE&gt;<br> https://opennet.me/openforum/vsluhforumID3/84842.html#211 Wed, 06 Jun 2012 03:17:33 GMT Мимо &#8212; http://www.opennet.ru/opennews/art.shtml?num=25926<br>Зыж<br>Какое отношение грип имеет к вызовам?<br>Речь то про ядро.<br> https://opennet.me/openforum/vsluhforumID3/84842.html#210 Tue, 05 Jun 2012 19:43:22 GMT Вы либо студент-идиот, либо умело здесь им прикидываетесь.<br>Я разговариваю с вами только из-за того, что мне это по приколу. Не злоупотребляйте.<br><br>Если решите оправдать себя, то пожалуйста приведите ссылки из сторонних, относительно вашего ума, источников (сразу уточняю, что соц. сети и ваша личная страница не покатят) по поводу:<br>1. "медийная ошибка" (и какие еще в этой классификации присутствуют)<br>2. "трафа" (цитата "Откуда у вас эта трафа на счёт 'вашего буфера'")<br>3. "аналог CRC" (сумма на диске; уточните чем фактически отличается если аналог)<br><br>Как Вы понимаете суть проблемы в данной ветке т.к. мне кажется, что вы ее не понимаете?<br><br>ЗЫ При условии продолжения безосновательной глупости с Вашей стороны буду считать полный Ваш слив по всем вопросам.<br> https://opennet.me/openforum/vsluhforumID3/84842.html#209 Tue, 05 Jun 2012 18:06:33 GMT &gt; Это лишь пример ошибок касаемо интерфейса (и вашего буфера, как его части, тоже).<br><br>это пример медийных ошибок, а не буфера. Точно такие же ошибки как при чтении с носителя, но вдругом месте. Откуда у вас эта трафа на счёт 'вашего буфера'? Достаточно уже кидать ссылки содержимое кторых вам не понятно.<br><br>&gt; и уничижении других.<br><br>что же поделать, таков закон джунглей.<br> https://opennet.me/openforum/vsluhforumID3/84842.html#207 Tue, 05 Jun 2012 16:50:53 GMT устаревшее барахло это grep в linux?<br> https://opennet.me/openforum/vsluhforumID3/84842.html#206 Tue, 05 Jun 2012 15:30:35 GMT ах да, требуемые 15к unlink/s это для кластера BlueWaters - TOP7 если склероз не изменяет.<br>Там всего каких-то 5к-7к вычислительных нод - которые удаляют/создают файлики..<br>я думаю 2 unlink per node per second это не так много для быдло админа с локалхоста ?<br> https://opennet.me/openforum/vsluhforumID3/84842.html#205 Tue, 05 Jun 2012 11:54:58 GMT грамотей-опричник в треде?<br><br>&gt; В какой-то роде. <br><br>you doing it wrong.<br><br><br>&gt; В общем случае код коррекции ошибок является и кодом <br>&gt; детектирования ошибок. Или по хомячковому - чексуммой :) <br><br>ну-ну. я ж говорю, чего только на опеннете не начитаешься.<br><br> https://opennet.me/openforum/vsluhforumID3/84842.html#204 Tue, 05 Jun 2012 09:54:15 GMT Приведу ссылку <br>http://rlab.ru/doc/s.m.a.r.t..html#1511<br>и цитату:<br>&gt; UltraDMA CRC Error Count<br>&gt; Общее количество ошибок CRC в режиме UltraDMA.<br>&gt; Поле raw value содержит количество ошибок, возникших в режиме передачи<br>&gt; данных UltraDMA в контрольной сумме (ICRC - Interface CRC).<br>&gt; Примечание автора. Практика, собранная статистика и изучение журналов ошибок SMART<br>&gt; показывают: в большинстве случаев ошибки CRC возникают при сильном завышении частоты PCI <br>&gt;(больше номинальных 33.6 MHz), сильно перекрученом кабеле, а также - по вине драйверов ОС, <br>&gt; которые не соблюдают требований к передачи/приему данных в режимах UltraDMA. <br><br>Это лишь пример ошибок касаемо интерфейса (и вашего буфера, как его части, тоже). Если посмотрите более внимательно то заметите, что HDD отлавливает массу ошибок как аппаратного происхождения, так и программного и, по моему мнению, данным с него можно доверять практически не проверяя (абсолютно конечно, в силу вероятностной природы самого CRC, ничто не может гарантировать, тут я сог