форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
Сообщение от opennews (??) on 02-Июн-12, 11:25
Теодор Цо (Theodore Ts'o) представил (https://lkml.org/lkml/2012/6/1/220) порцию изменений в файловой системе Ext4, предложенных для интеграции в состав ядра Linux 3.5. Ключевым новшеством является обеспечение встроенной поддержки проверки целостности метаданных, реализованной в рамках инициативы по увеличению надёжности ФС Ext4.  Для обеспечения новой функции в поле метаданных добавлен новый блок с контрольной суммой crc32 и соответственно изменена структура хранимых на диске мета-данных. Контрольные суммы рассчитываются для суперблока, inode, битовых карт блоков, блоков дерева экстентов, htree-узлов, MMP-блоков, директорий и блоков с расширенными атрибутами. Также поддержка контрольных сумм добавлена в инфраструктуру журналирования jbd2 (Journaling block device), что позволит проверять целостность элементов журнала Ext4, а также отдельных коммитов и блоков данных, хранимых в журнале. URL: https://lkml.org/lkml/2012/6/1/220 Новость: http://www.opennet.me/opennews/art.shtml?num=33996
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+3 +/–
Сообщение от Аноним (??) on 02-Июн-12, 11:25
А производительность на сколько просядет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+3 +/–
	Сообщение от ВовкаОсиист (ok) on 02-Июн-12, 11:29
	не идиоты же пишут, там куча реализаций крк32 под разные процессорные возможности.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Анонимус_б6 on 02-Июн-12, 11:29
	видимо в зависимости от проца, я надеюсь он догадался поюзать все современные оптимизации?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	7. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–14 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 12:05
	в ядре? фантазёр
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	13. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 02-Июн-12, 13:04
	Да. В ядре. Достаточно посмотреть его исходники. Или хотя бы 1 раз его собрать самому и посмотреть параметры. Зыж Кстати сабж — это один из пунктов в пользу монолитности ядра.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	28. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от BratSinot on 02-Июн-12, 16:45
	> Кстати сабж — это один из пунктов в пользу монолитности ядра. В каком месте это вообще здесь уперлось? На микро/экзо/нано ядрах нет файловой подсистемы? Нет возможности использовать алгоритмы хеширования?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	31. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+3 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:03
	> подсистемы? Нет возможности использовать алгоритмы хеширования? Там счет crc32 покажется ерундой на фоне постоянного переключения контесктов :)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	36. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:34
	Отдельный сервер для расчёта CRC-32, да.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	48. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 02-Июн-12, 18:36
	Я бы лучше и не ответил. :)
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	73. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 21:21
	А разве такое выносится в отдельный процесс? Просто будет библиотека, оптимизированная для каждого процессора, со статической линковкой, которую подключат нужные компоненты микроядра.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	74. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 02-Июн-12, 21:39
	Вы вообще понимаете что говорите? Где статическая (да и любая другая) линковка и где контекст выполнения.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	94. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Voviandr (??) on 02-Июн-12, 23:43
	>> подсистемы? Нет возможности использовать алгоритмы хеширования? > Там счет crc32 покажется ерундой на фоне постоянного переключения контесктов :) цитата Зубинского (в контексте микторядра MINIX 3) : "За всякое улучшение надо платить, и расплатой здесь является снижение производительности ОС в целом, вызванное необходимостью реализации, на первый взгляд, весьма ресурсоемких механизмов «общения» привилегированного микроядра и непривилегированных серверов. Однако это только на первый взгляд. Разработчики MINIX 3 на ранних этапах проектирования системы построили и исследовали математические модели, позволяющие достаточно точно изучить снижение производительности, вызванное спецификой архитектуры системы. Оказалось, что по сравнению с ОС с монолитным ядром MINIX 3 теряет всего лишь на 0,5% процессорного времени больше из-за «общения» между микроядром и программами-серверами." полпроцента - это имхо, не потеря. цитата взята отсюда  http://itc.ua/articles/minix_mozhete_schitat_ee_studebekerom.../
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	141. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+3 +/–
	Сообщение от Аноним (??) on 04-Июн-12, 00:59
	> взгляд. Разработчики MINIX 3 на ранних этапах проектирования системы построили и > исследовали математические модели, позволяющие достаточно точно изучить снижение производительности, Да забодали вы с вашими сферическими конями в вакууме. Сделайте практическую реализацию, мы ее погоняем под разными ворклоадами и посмотрим чего все эти теоретические рассусоливания стоят. И какие там будут полпроцента при различных ворклоадах, включая всякие клинические случаи требующие переключать контексты, etc. > полпроцента - это имхо, не потеря. Ну вот когда будет вообще что побенчить - тогда и посмотрим какие там и у кого полпроцента. Только чур не забывайте что накопители нынче могут развивать скорость в сотни мегабайтов в секунду. Это заметный процентаж от того что вообще может пропустить через себя проц и оператива, так что там какие-то десятки-сотни команд должны обрабатывать весь поток. Если оверхед будет больше - не уложится и упрется. И есть риск что полпроцента которые наблюдаемы на тормозном ноутбучном диске, резко станут 50% на pci-E SSD, например, который может совершенно дикие скорости развивать.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	160. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Voviandr (??) on 04-Июн-12, 02:01
	вы выдвигаете тезис, что мои утверждения про полпроцента необоснованны, так как не было реальных тестов в высоконаргуженных приложениях. но тогда надо ли доказывать, что и ваши утверждения про то, что система загнётся под нагрузкой, точно так же необоснованны, по той же самой причине - не было реальных тестов ? я не ссылаюсь на то, что в реале и будет полпроцента, я ссылаюсь на то, что авторами софта были просчитаны некоторые варианты, и конечно плохо то, что деталей этих математических моделей мы не знаем.
	Ответить | Правка | ^ к родителю #141 | Наверх | Cообщить модератору

	166. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–2 +/–
	Сообщение от Аноним (??) on 04-Июн-12, 02:29
	> но тогда надо ли доказывать, что и ваши утверждения про то, что > система загнётся под нагрузкой, точно так же необоснованны, по той же > самой причине - не было реальных тестов ? У меня есть валидное оправдание: я на уровне инженерной интуиции вполне могу представить себе паттерны, которые будут "неудобны". В том плане что будет сравнительно много "дерганий" таковой логики при относительно небольшом объеме пропиханных полезных данных. Так что КПД устремится в плинтус. В микроядерной конструкции он шлепнется в плинтус гораздо быстрее, т.к. на одну и ту же операцию больше действий. У теоретиков есть одна проблема: они при анализе своей концепции невольно подыгрывают ей, придумывая некие анализы которые по их мнению чего-то там. Невольно выбирая более-менее удобные паттерны, на которых "свое - не пахнет". Ну или грабли - не более полупроцента. Я со своей стороны оцениваю "а что будет, если". Этим если могут быть совершенно разные ситуации. Я вполне могу прикинуть ситуацию когда вместо 0.5% будет какая-то иная величина, существенно менее прикольная для авторов. Как вы думаете, насколько академик защищающий некоторую концепцию хочет рассказывать о том что "а если паттерн доступа вот такой - то оно в 2 раза тормознее получается"? Правильно - обычно такие господа смолчат в тряпочку "чтобы статистику не портить" своему велосипеду. Вроде б и не соврали, но зато становится куда понятнее почему на этом велосипеде никто не хочет ездить на практике :P. > я не ссылаюсь на то, что в реале и будет полпроцента, я > ссылаюсь на то, что авторами софта были просчитаны некоторые варианты, Вот только такие авторы очень уж лю считать все для сферических коней в вакууме.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

	52. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от ананим on 02-Июн-12, 18:58
	> В каком месте это вообще здесь уперлось? На микро/экзо/нано ядрах нет файловой подсистемы? Нет возможности использовать алгоритмы хеширования? Куча профильных ошибок для специалиста (если вы специалист). В том то и дело что не "на", а "в". И не "подсистема", а "система". Зыж Для остальных — алгоритмы хэшировашия/cripto традиционно реализуются в ядре линуха уже давно, для каждой платформы и как правило самими разрабами платформы (интелом для пней, аэмдэшниками для дюронов, нвадией для нвидиа и тд). Сабж их просто заюзал. Причем в том же пространстве ядра. В общем это будет настолько быстро, насколько это вообще возможно на целевой платформе. Но можно эти алгоритмы вызывать и из юзер-спейса. Для этого есть необходимые системные вызовы. И они даже посикс (резко вспоминаем баг с крипто в фрибсд 2-а дня назад. И понимаем почему именно расширенные символы. И почему в линухе этого быть не может... но это уже для спецов:D)
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	87. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 22:42
	> И они даже посикс (резко вспоминаем баг с крипто в фрибсд 2-а дня назад. В пингвине к счастью никто не страдает настолько упоротой некромансией чтобы использовать DES. DES вообще отстойный алгоритм: он и тормозной, и ключ у него короткий. Уникальное сочетание отстойных свойств.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	106. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от Аноним (??) on 03-Июн-12, 09:31
	> В пингвине к счастью никто не страдает настолько упоротой некромансией чтобы использовать > DES. DES вообще отстойный алгоритм: он и тормозной, и ключ у > него короткий. Уникальное сочетание отстойных свойств. Для вас это будет сюрпризом, но в библиотеке Glibc, которая используется почти во всех дистрибутивах Linux, в функции crypt по умолчанию используется как раз DES.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	111. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от filosofem (ok) on 03-Июн-12, 12:54
	Да хоть бы XOR по дефолту. Что это меняет?
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	112. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от ананим on 03-Июн-12, 13:07
	>Для вас это будет сюрпризом, но в библиотеке Glibc, которая используется почти во всех дистрибутивах Linux, в функции crypt по умолчанию используется как раз DES. ещё бы! ведь это ложь. :D http://www.gnu.org/software/libc/manual/html_node/crypt.html... >Function: char * crypt (const char *key, const char *salt) >... >The salt parameter does two things. Firstly, it selects which algorithm is used, the MD5-based one or the DES-based one. Secondly, it makes life harder... надо пояснять что значит "it selects which algorithm is used"? :D
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	140. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 23:27
	> надо пояснять что значит "it selects which algorithm is used"? :D Не вырывайте из контекста, а читайте дальше где написано, что по дефолту DES, а для использования других алгоритмов нужно задавать специальным образом salt. Во FreeBSD точно также можно через salt задавать альтернативный метод хэширования. С тем же успехом можно было написать "Во FreeBSD к счастью никто не страдает настолько упоротой некромансией чтобы использовать DES.".
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	177. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 04-Июн-12, 09:42
	Ок. Я не буду "вырывать", а вы научитесь читать. Нет никакого дефолта. Есть переменная в функции. Используется в любом случае. Так что ложь и вы на ней настаиваете.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	130. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от Аноним (??) on 03-Июн-12, 22:11
	А причём тут glibc если crypt с DES это стандарт POSIX? glibc наоборот добавляет новые алгоритмы.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	139. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 23:19
	> А причём тут glibc если crypt с DES это стандарт POSIX? glibc > наоборот добавляет новые алгоритмы. При том, что аноним выше ухмылялся про DES во FreeBSD, в то время как crypt и в bsd libc и glibc не только DES поддерживает, но по дефолту и там и там DES.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	176. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 04-Июн-12, 09:37
	Какой в попу дефолт? Салт нужен в любом случае. И это первое. Второе — какое это имеет отношение к багу в бзде?
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	142. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:00
	> во всех дистрибутивах Linux, в функции crypt по умолчанию используется как раз DES. Осталось найти хоть 1 пароль в современном пингвине зашифрованный именно так.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	183. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 04-Июн-12, 11:06
	Вообще-то надо найти впингвине хоть один вызов не умеющий многобайтовые символы. Именно поэтому я и вспомнил баг. :) Даже когда был кои8, терменал конвертировал для внутреннего представления в уникод. А в бсде ещё куча устаревшего барахла по наследству осталось.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	207. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 05-Июн-12, 20:50
	устаревшее барахло это grep в linux?
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	211. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 06-Июн-12, 07:17
	Мимо — http://www.opennet.me/opennews/art.shtml?num=25926 Зыж Какое отношение грип имеет к вызовам? Речь то про ядро.
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	212. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 06-Июн-12, 07:30
	пример поиска в utf8 для grep-2.9: $ wget -O - http://opennet.ru 2>&1|iconv -f koi8-r|grep 'вар.ант'    <TITLE>OpenNet без "www" - минималистский вариант портала по открытому ПО, Linux, BSD и Unix системам</TITLE>
	Ответить | Правка | ^ к родителю #207 | Наверх | Cообщить модератору

	4. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 11:35
	В пределах погрешности
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 12:04
	не должно просесть, здесь запись на диск намного тормознее вычисления crc
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	16. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от pavlinux (ok) on 02-Июн-12, 14:56
	Диски уже не покупают.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	22. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 15:28
	> Диски уже не покупают. А что покупают? SSD?
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	35. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:32
	> А что покупают? SSD? Примерно так. На механические диски цены после наводнения в тайване довольно конские.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	39. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 17:39
	А как быть с большими объемами? Цены на SSD все еще довольно высокие. Цены на HDD несколько снизились. Растущая конкуренция с SSD должна только способствовать снижению. В некоторой, не очень долгосрочной, перспективе все вернется на место. А пока я не вижу серьезной конкуренции между HDD и SSD при хранении большого количества данных (порядка ТБ). ЗЫ И да, я админ локалхоста и в связи с этим имею ограниченные финансы.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	174. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 04:58
	> А как быть с большими объемами? Цены на SSD все еще довольно высокие. Ну вот и выбираем между конскими ценами и еще более конскими :)
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	17. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 14:58
	угу. админ локал хоста замечен. А что бы данный админ сказал о raid6 который имеет сумарную скорость записи 3ГБ/с ? и чтение около 6.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	19. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от pavlinux (ok) on 02-Июн-12, 15:05
	А у меня дома RAID 60 на SAS SSD c суммарной записью 12Gb/s, (или мне это приснилось).
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	107. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 12:03
	а без SSD получить столько ?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	143. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от pavlinux (ok) on 04-Июн-12, 01:01
	> а без SSD получить столько ? Конечно нет, да и с SSD столько не получишь, это ж маркетинг, как и 6Gb/s и 3Gb/s. Реальные цифры, сейчас, это 600-800 Mb/s
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	146. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:26
	В моем случае увы не маркетинг. А реальная стойка с винтами - нечто типа того что продает netap
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	186. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от pavlinux (ok) on 04-Июн-12, 13:39
	> В моем случае увы не маркетинг. А реальная стойка с винтами - нечто типа того что продает netap Давай скрины # iozone -a -+u -p -B -e -E; А то эти SANы/NASы - типа "кэшуруют", а при пиковый загрузке, скорость становится даже не как у RAID, а как у одного диска - 150MB/s;    А так же, показать скорость записи одно терабайтного файла между разными разделами, скажем из /usr в /var; >  нечто типа того что продает netap Ещё одна жертва маркетинга. :) --- Надеюсь спорить не будете, что RAID0 - самый быстрый способ организации  массива?! Вот примеры бынчмарков, http://www.tomshardware.com/charts/ssd-raid-0-charts-2011/be...,120.html 600 Мб/с, пускай не самый шустрый SSD, но максимум можно ещё 200 МБ/с натянуть.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	189. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 17:54
	сам ты жертва маркетинга. Некоторые подобные железки собирают.
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	30. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 16:59
	> А что бы данный админ сказал о raid6 который имеет сумарную скорость записи 3ГБ/с ? и чтение около 6. Если начальник не жмот, там и процы должны быть соответствующие.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	108. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 12:06
	>> А что бы данный админ сказал о raid6 который имеет сумарную скорость записи 3ГБ/с ? и чтение около 6. > Если начальник не жмот, там и процы должны быть соответствующие. начальник не жмот - но вот в чем проблема - подсчет crc32 от такого потока - съедает 4 ядра и 12. то есть сумарная производительность железки - падает ровно на столько же.. А ведь она могла бы заниматься еще чем-то - кроме как считать контрольные суммы. Вторым аспектом - является дополнительная задержка - которую вносит эта операция в сумарное время выполнения. В случае MD операций - это очень важный показатель. Хотя тем у кого обычный рабочий патерн куча больших файлов из которых читают (а не создают / удаляют постоянно временные файлы) - этого не понять.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	113. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от filosofem (ok) on 03-Июн-12, 13:07
	А че за железка такая, у которой скорость рандомной записи на raid 6 сравнима со скорость подсчета crc? На массив из DDR дисков похоже =)
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	179. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 09:54
	> А че за железка такая, у которой скорость рандомной записи на raid > 6 сравнима со скорость подсчета crc? На массив из DDR дисков > похоже =) Можно сказать самосбор - аналоичный тому что продает NETAP. только у NETAP наружу выдается FC, а тут SAS шина.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	126. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от XoRe (ok) on 03-Июн-12, 18:48
	>>> А что бы данный админ сказал о raid6 который имеет сумарную скорость записи 3ГБ/с ? и чтение около 6. >> Если начальник не жмот, там и процы должны быть соответствующие. > начальник не жмот - но вот в чем проблема - подсчет crc32 > от такого потока - съедает 4 ядра и 12. По моему, в новости написано о том, что будет. У вас, наверное реализовано что-то другое?
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	178. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 09:52
	У нас другое - но хорошо показывает использования CPU на больших потоках данных, для вычисления crc32 даже используя crc32_hw инструкцию в последних CPU имени интела.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	190. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от XoRe (ok) on 04-Июн-12, 17:56
	> У нас другое - но хорошо показывает использования CPU на больших потоках > данных, для вычисления crc32 даже используя crc32_hw инструкцию в последних CPU > имени интела. А у вас проверяются данные, или мета данные? Наверное, у вас данные - тогда понятна нагрузка на проц. Данный патч именно для мета данных - он будет нагружать проц на несколько порядков меньше.
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	201. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 05-Июн-12, 11:57
	Проверяется все. Но если для данных - это выльется в загрузку CPU, то для метаданных он выливается в увеличение времени выполнения операции. Как уже писал - лучше бы T10 DIF/DIX запилили - хотя бы проверка целостности (более частая операция) выполнялась бы аппаратно.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	213. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от XoRe (ok) on 08-Июн-12, 22:54
	> Проверяется все. Но если для данных - это выльется в загрузку CPU, > то для метаданных он выливается в увеличение времени выполнения операции. > Как уже писал - лучше бы T10 DIF/DIX запилили - хотя бы > проверка целостности (более частая операция) выполнялась бы аппаратно. Просто вы написали "подсчет crc32 от такого потока - съедает 4 ядра и 12". Вы невольно ввели людей в заблуждение, не указав, что идет подсчет ещё и для данных. Система, обсуждаемая в топике, подсчитывает только метаданные. Да, это создает доп. нагрузку и задержки. Но насколько большую - неизвестно. Нужно дождаться релиза и протестить. К сожалению, ваш опыт тут неприменим, т.к. у вас другая система считает другие вещи.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	181. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 10:01
	>>>> А что бы данный админ сказал о raid6 который имеет сумарную скорость записи 3ГБ/с ? и чтение около 6. >>> Если начальник не жмот, там и процы должны быть соответствующие. >> начальник не жмот - но вот в чем проблема - подсчет crc32 >> от такого потока - съедает 4 ядра и 12. > По моему, в новости написано о том, что будет. > У вас, наверное реализовано что-то другое? Кстати в догонку - лучше бы сделали поддержку T10 DIF/DIX. Хотя бы половина задачи (проверка) выполнялась бы не CPU, а HBA или диском - все же достаточно разгрузило бы камешек.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	125. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от XoRe (ok) on 03-Июн-12, 18:48
	> угу. админ локал хоста замечен. > А что бы данный админ сказал о raid6 который имеет сумарную скорость > записи 3ГБ/с ? и чтение около 6. Ну, положим не ГБ, а Гб ... Предполагаю, что сие можно будет отключить, когда оно будет реализовано.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	147. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:28
	>> угу. админ локал хоста замечен. >> А что бы данный админ сказал о raid6 который имеет сумарную скорость >> записи 3ГБ/с ? и чтение около 6. > Ну, положим не ГБ, а Гб ... > Предполагаю, что сие можно будет отключить, когда оно будет реализовано. Ну допустим именно 3ГБ/с - 4 контролера на 6 Gb/s и backplane на 24 sas диска
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	32. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:04
	> не должно просесть, здесь запись на диск намного тормознее вычисления crc А если pci-e ssd взять? :)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	55. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+9 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 19:45
	вы все здесь какие-то все упоротые собрались. У какого-то придурка там рейд выдаёт 3гбс, другие ssd во все щели пихают. У кого-то таки может хватит  мозги прочитать CRC чего там начали считать? Попробую напомнить - метаданных. Теперь посчитай сколько обновлений метаданных приходится на IO операцию.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	109. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 12:08
	> вы все здесь какие-то все упоротые собрались. У какого-то придурка там рейд > выдаёт 3гбс, другие ssd во все щели пихают. У кого-то таки > может хватит  мозги прочитать CRC чего там начали считать? Попробую > напомнить - метаданных. Теперь посчитай сколько обновлений метаданных приходится на IO > операцию. на каждую операцию операцию с диском приходится ровно одна операция с MD. видимо все забывают что по умолчанию ext4 обновляет atime при каждом обращении к файлу. а значит выполняется операция записи в журнал и обновление метаданных на диске. мисье этого не знал ?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	114. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от filosofem (ok) on 03-Июн-12, 13:17
	>видимо все забывают что по умолчанию ext4 обновляет atime при каждом обращении к файлу. Насчет упоротых соглашусь с предыдущим Анонимом.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	122. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Yakov Markovitch on 03-Июн-12, 16:40
	>> вы все здесь какие-то все упоротые собрались. У какого-то придурка там рейд >> выдаёт 3гбс, другие ssd во все щели пихают. У кого-то таки >> может хватит  мозги прочитать CRC чего там начали считать? Попробую >> напомнить - метаданных. Теперь посчитай сколько обновлений метаданных приходится на IO >> операцию. > на каждую операцию операцию с диском приходится ровно одна операция с MD. > видимо все забывают что по умолчанию ext4 обновляет atime при каждом обращении > к файлу. > а значит выполняется операция записи в журнал и обновление метаданных на диске. > мисье этого не знал ? Месье, как я понимаю, в отличие от Вас, знал, что не при каждом обращении к файлу, а при первом после изменения (AKA relatime - учите матчасть). Это при условии, что админ не включил noatime, что обычно делается - в этом случае atime обновляется только при записи, как mtime. Далее, ППКС (насчёт упоротости). И, господа диванные программисты, на современных процах (i5/i7/современные Xeon) скорость реализации CRC32 примерно 3 цикла/байт - это если не использовать hardware support, которого есть. Если его использовать, то 0.6цикла/байт (в среднем). Желающие могут посчитать, какой объём может обсчитать одно ядро - тут кто-то что-то нёс про "4 ядра из 12". На всякий случай, не надеясь на ваши арифметические способности - 1-5 GB/c. Усердный читатель может прикинуть, какое _количество_операций_записи_ надо провести, чтобы занять подсчётом crc32 хотя 5% _одного_ ядра.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	150. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:35
	>[оверквотинг удален] > записи, как mtime. > Далее, ППКС (насчёт упоротости). > И, господа диванные программисты, на современных процах (i5/i7/современные Xeon) скорость > реализации CRC32 примерно 3 цикла/байт - это если не использовать hardware > support, которого есть. Если его использовать, то 0.6цикла/байт (в среднем). Желающие > могут посчитать, какой объём может обсчитать одно ядро - тут кто-то > что-то нёс про "4 ядра из 12". На всякий случай, не > надеясь на ваши арифметические способности - 1-5 GB/c. > Усердный читатель может прикинуть, какое _количество_операций_записи_ надо провести, > чтобы занять подсчётом crc32 хотя 5% _одного_ ядра. Упроотые это все тестировали и писали реализаю этого когда в ядре еще не было. И хоть ты тресни но выше 2 GB/s не выдают ксеона. Такая вот незадача. А надо 6. Это как с хваленым io at - оказалось быстрее гонять через CPU чем использовать эту фичу. На счет остального - мисье еще забыл что очень дофига операций проходит через журнал, да и relative atime не является опции ей по умолчанию, а включив no atime можно сломать некоторый софт.
	Ответить | Правка | ^ к родителю #122 | Наверх | Cообщить модератору

	180. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 09:56
	>[оверквотинг удален] >> могут посчитать, какой объём может обсчитать одно ядро - тут кто-то >> что-то нёс про "4 ядра из 12". На всякий случай, не >> надеясь на ваши арифметические способности - 1-5 GB/c. >> Усердный читатель может прикинуть, какое _количество_операций_записи_ надо провести, >> чтобы занять подсчётом crc32 хотя 5% _одного_ ядра. > Упроотые это все тестировали и писали реализаю этого когда в ядре еще > не было. И хоть ты тресни но выше 2 GB/s не > выдают ксеона. Такая вот незадача. А надо 6. Это как с > хваленым io at - оказалось быстрее гонять через CPU чем использовать > эту фичу. ах да, забыл - когда у тебя один raid[5,6] тогда io AT дает выигрыш, а когда 3-4 тогда он дает проигрыш - так как упирается в свою пропускную. только почему-то в документации от intel об этом не слова.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	188. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Yakov Markovitch on 04-Июн-12, 15:07
	>[оверквотинг удален] >> Усердный читатель может прикинуть, какое _количество_операций_записи_ надо провести, >> чтобы занять подсчётом crc32 хотя 5% _одного_ ядра. > Упроотые это все тестировали и писали реализаю этого когда в ядре еще > не было. И хоть ты тресни но выше 2 GB/s не > выдают ксеона. Такая вот незадача. А надо 6. Это как с > хваленым io at - оказалось быстрее гонять через CPU чем использовать > эту фичу. > На счет остального - мисье еще забыл что очень дофига операций проходит > через журнал, да и relative atime не является опции ей по > умолчанию, а включив no atime можно сломать некоторый софт. 1. relatime _является_ опцией по умолчанию, на всякий случай. 2. В нормальной ситуации (data=ordered, по умолчанию) через журнал проходят только операции изменения метаданных. А если Вы вдруг поставили data=journal, то проблема производительности crc32 будет _последним_, о чем Вам стОит заботиться в плане производительности, смею Вас уверить. Еще раз, пожалуйста: приведите пример разумного практического режима нагрузки, при котором сколько-нибудь долго пишется хотя бы 200MB/s _метаданных_. Подчёркиваю - разумного и практического. P.S. Чтобы два раза не вставать - нет такого процессора "ксеон", есть "зион". Похоже, стоит учить не только материальную часть? P.P.S. Обсуждали бы уж что-нибудь, что знаете не только по форумам, что ли.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	191. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 17:59
	>[оверквотинг удален] >> через журнал, да и relative atime не является опции ей по >> умолчанию, а включив no atime можно сломать некоторый софт. >  1. relatime _является_ опцией по умолчанию, на всякий случай. >  2. В нормальной ситуации (data=ordered, по умолчанию) через журнал проходят только > операции изменения метаданных. А если Вы вдруг поставили data=journal, то проблема > производительности crc32 будет _последним_, о чем Вам стОит заботиться в плане > производительности, смею Вас уверить. > Еще раз, пожалуйста: приведите пример разумного практического режима нагрузки, при котором > сколько-нибудь долго пишется хотя бы 200MB/s _метаданных_. Подчёркиваю - разумного и > практического. welcome to HPC world. пример - Cray acceptance testing при сдаче BlueWaters project (тот что в NACA стоит) - Cray XT5 + Cray XT6. Требуемые параметры - 30-15k unlink per second. Расчет спец эффектов фильма черный рыцарь - класстер из 4к нод - среднее время расчета кадра 2-3с - требуется обеспечить порядка 8к md ops per second. Не разумное? учитывая что операция над метаданными как правило сожрет больше килобайта - то мы получаем в обоих случаях больше 200мб/с данных которые пытаются писать на диск. Welcome to HPC world, NEO.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	192. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Yakov Markovitch on 04-Июн-12, 19:59
	>>[оверквотинг удален] >> практического. > welcome to HPC world. пример - Cray acceptance testing при сдаче BlueWaters > project (тот что в NACA стоит) - Cray XT5 + Cray > XT6. > Требуемые параметры - 30-15k unlink per second. 30MB/s. OK, согласен, пишем на каждую операцию по странице - 120MB/c. 20% нагрузки одного ядра класса Xeon. Вы твёрдо уверены, что оно там одно?.. > Расчет спец эффектов фильма черный рыцарь - класстер из 4к нод - > среднее время расчета кадра 2-3с - требуется обеспечить порядка 8к md > ops per second. > Не разумное? учитывая что операция над метаданными как правило сожрет больше килобайта > - то мы получаем в обоих случаях больше 200мб/с данных которые > пытаются писать на диск. Виноват? 8kop/s * 1k == 8MB/s. Хорошо, пусть даже страница каждый раз (хотя это бред) - тогда 32MB/s. > Welcome to HPC world, NEO. Гм. Welcome во 2-й класс средней школы - учим арифметику.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	203. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 05-Июн-12, 12:07
	>>>[оверквотинг удален] >>> практического. >> welcome to HPC world. пример - Cray acceptance testing при сдаче BlueWaters >> project (тот что в NACA стоит) - Cray XT5 + Cray >> XT6. >> Требуемые параметры - 30-15k unlink per second. > 30MB/s. OK, согласен, пишем на каждую операцию по странице - 120MB/c. 20% > нагрузки одного ядра класса Xeon. Вы твёрдо уверены, что оно там > одно?.. вы твердо уверены что MD операции могут выполняться паралельно в одной директории? А то вы так яро бросились считать ядра у процессора. Спешу огорчить - не могут. И увеличение количества ядер тут слабо поможет - только увеличит cache ping-pong что само по себе очень дорогая операция. В MD операциях - меряют не абсолютной загрузкой ядра - а относительным по отношению к общей длительности операции. Если у вас операция идет 2мс, и вы добавляете еще одну ms - то получаете замедление на 50%. или это сложно для второго класса ? Если мы будем рассматривать паралельные операции в разных директориях - то увы - как не крути, 1 ядро из 16 - это почти 10% замедления для всех операций. У месье всегда найдется откуда взять эти 10% ? и не задумывается о том что есть вообще предел. Касательно всех цифр о пропускной - давайте посчитаем сколько это будет занимать при включеных квотах - насколько я помню - в пределе размер записи журнала по одной операции может достигать 16кб - куда входит информация о модификации всех экстентов, всех файлов связанных с операцией (квотных) - копия атрибутов и тп..
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	195. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 04-Июн-12, 23:32
	> Требуемые параметры - 30-15k unlink per second. знаешь что.. я тоже могу сейчас у себя на локалхосте написать быдлокод и заявить, мол мне нужно 200к анлинков в секунду. А да, ещё назову это 'HPC world', во!
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	202. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 05-Июн-12, 11:58
	>> Требуемые параметры - 30-15k unlink per second. > знаешь что.. я тоже могу сейчас у себя на локалхосте написать быдлокод > и заявить, мол мне нужно 200к анлинков в секунду. А да, > ещё назову это 'HPC world', во! Обратитесь в подразделение Cray за обоснованием этих цифр.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	206. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 05-Июн-12, 19:30
	ах да, требуемые 15к unlink/s это для кластера BlueWaters - TOP7 если склероз не изменяет. Там всего каких-то 5к-7к вычислительных нод - которые удаляют/создают файлики.. я думаю 2 unlink per node per second это не так много для быдло админа с локалхоста ?
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	131. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 22:14
	> на каждую операцию операцию с диском приходится ровно одна операция с MD. > видимо все забывают что по умолчанию ext4 обновляет atime при каждом обращении > к файлу. Ты откуда вылез? ext уже лет 5 как монтируется по умолчанию с relatime
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	144. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:03
	> вы все здесь какие-то все упоротые собрались. У какого-то придурка там рейд > выдаёт 3гбс, другие ssd во все щели пихают. А мы виноваты что технологии - вот они. Пошел в магазин да купил. Упоротый - это тот кто зациклился на своем ноутбучном венике и дальше своего носа ничего не видит. > Попробую напомнить - метаданных. Теперь посчитай сколько обновлений > метаданных приходится на IO операцию. Для начала объясните: 1) Нафига? 2) Что это по вашему мнению покажет и докажет?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	196. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 04-Июн-12, 23:38
	Я, честно говоря, свосем не понял вашего вопроса. А именно что вы там в магазине купите и что именно пояснить. Если не затруднит, то давайте не расчитывать на то, что я такой же аутист как и вы и пойму всё с двух слов. Прежде чем ещё раз задавать мне по несколько раз один и тот же ответ, то потрудитесь, пожалуйста, оценить, сколько дополнительных IOPSов в % соотношении выдаст расчёт CRC метаданных в любимом для вас профиле нагрузке на ФС. Или вам кажется, что достаточно сходить в магазин, купить чего-нить и устроить истерику на счёт 3гбс и CRC?
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

5. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
Сообщение от Аноним (??) on 02-Июн-12, 11:53
И как оно будет работать? Ну вырубися у меня комп во время записи, файл не записался и что будет? Выяснит он, что контрольная сумма не сходится, но данные то потеряются? Журналы то вообще я правильно понимаю? Есть 2 журнала, сначаа в первый пишется, что что файл такой-то изменился, потом он меняется (если в этот момент ошибка то во второй журнал не пишется и изменение потом откатывается) затем, если все ОК, то пишется во второй журнал.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от pavlinux (ok) on 02-Июн-12, 15:00
	> И как оно будет работать? Ну вырубися у меня комп во время > записи, файл не записался и что будет? Ну ёбни по диску кувалдой во время записи и проверь что будет. :) CRC используются проверки корректности данных.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	37. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:35
	> CRC используются проверки корректности данных.   здесь — метаданных
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	64. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от pavlinux (ok) on 02-Июн-12, 20:35
	>> CRC используются проверки корректности данных. > здесь — метаданных псевдо-, мета-, квази-, суб-, ... в общем данных.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	21. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 15:22
	> И как оно будет работать? Ну вырубися у меня комп во время записи, > файл не записался и что > будет? Выяснит он, что контрольная сумма > не сходится, но данные то потеряются? Сохранность данных во время операций записи, связанная со сбоями оборудования, не забота ФС (может есть и такие, но я о них не знаю, да и не интересовался), ее забота сохранение уже содержащихся в ней данных, что и делает журнал, поддерживая свою внутреннюю структуру в корректном состоянии. Я не админ, но на сколько мне известно в некоторых контроллерах ЖД, как раз по этой причине, есть свой ИБП с аккумулятором позволяющий завершить корректно работу с ЖД в случае отключения питания. Я также уверен, что эксплуатация систем, от которых требуется хоть какая-то надежность без ИБП вообще сродни самоубийству, так что Ваша ситуация скорее исключение, чем реальное положение вещей. ЗЫ Если что не так сказал - пусть более знающие поправят.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	41. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:40
	В т ч забота ФС. Журналирование - попытка решить эту проблему. Не важно что отказало оборудование или софт повис. Конечно можно обеспечить избыточность другим способом, в т ч рейдами и снэпшотами, но на каждый комп это не поставишь как и ибп.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	46. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 18:15
	> В т ч забота ФС. Журналирование - попытка решить эту проблему. Не > важно что отказало оборудование или софт повис. > Конечно можно обеспечить избыточность другим способом, в т ч рейдами и снэпшотами, > но на каждый комп это не поставишь как и ибп. Заботой ФС это было бы в том случае, если бы она это могла сделать хотя бы теоретически. Но реалии таковы, что обеспечение гарантированной записи в случае сбоя возможно лишь в случае обеспечении атомарности этой операции, что по определению невозможно т.к. это сложная операция над большим количеством данных. Во время нее необходимо обеспечивать полную работоспособность системы. ФС, в этом случае, может лишь уменьшить вероятность своего разрушения или повреждения данных избегая или обособляя и оптимизируя критические операции, которые имеют место при записи, т.е. приближая их к определению "атомарная". То, о чем Вы говорите - не проблема избыточности. Во всяком случае избыточности системы хранения. Проблема в обеспечении работы без перебоев. В случае рейда, также нет 100% гарантии, что данные успеют записаться хотя бы на один жесткий диск. То, о чем Вы говорите лишь вероятность, а не гарантия. По поводу ИБП, то за все приходится платить. Если нужна стабильность и надежность, то Вам придется приобретать ИБП т.к. это единственный реальный способ обеспечить именно гарантию.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	98. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 01:36
	А также ECC память, проверка целостности каждого блока данных записанного на диск (не помню как зовется технология) и еще много чего, но 100% гарантия вряд ли достижима на практике. Естественно, на серверах с важными данными девяток в этой цифре должно быть ооочень много. ext4 работает на куче простых устройств и компов, стрелять из пушки во воробьям (внедряя абсолютно все технологии по защите данных) тоже не стоит.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	115. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 03-Июн-12, 13:35
	Проверка целостности данных, на сколько я знаю, происходит при передаче через интерфейс диска и при считывании с диска (за счет этого работает внутренняя диагностика), так что за данные записанные/считанные с диска можно практически не беспокоиться. Про контроллеры и отслеживание ошибок в них ничего не знаю. А на счет пушки и воробьев, то да, согласен полностью, от включения проверок всегда и везде большого толку не будет, а минусы в виде сложности (потенциально больше ошибок), тотальной "велосипедности", снижения производительности и гибкости, гарантированы.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	102. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 02:03
	> это сложная операция над большим количеством данных Ман версионные FS. Никакой атомарности нам нахрен не нужно.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	110. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 03-Июн-12, 12:41
	На сколько понял, разница с обычными ФС только при изменении данных, т.е. они не изменяются, а создается измененная копия (версия). Как это решает проблему записи данных на диск непонятно. То, что ФС позволяет откатиться назад, к валидному состоянию, так это решает проблемы исключительно самой ФС и не решает проблемы пользователя, гарантируя целостность его данных.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	148. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:30
	> На сколько понял, разница с обычными ФС только при изменении данных, т.е. > они не изменяются, а создается измененная копия (версия). Да. При том только измененных блоков. И меняются структуры описывающие размещение файла чтобы указать что вон тот кус файла теперь брать вон там. Запись - только 1 раз а не 2 как с журналом. С обычным журналом блоки сперва полетели бы в журнал а потом в основную ФС. А тут сразу в сторонку, а старый вариант блоков не трогается вот так сразу, так что на него можно даже откатиться при желании. > Как это решает проблему записи данных на диск непонятно. Избавляются от двойной записи. Да еще и запись недеструктивная. Если все нагнулось когда "выносок" не успели записать - у вас остается старая версия. А когда он успел дописаться - у вас уже будет новая версия, как ни крути. Ну и старая тоже будет, покуда GC не подгребет временные сущности. > То, что ФС позволяет откатиться назад, к валидному состоянию, так это решает > проблемы исключительно самой ФС и не решает проблемы пользователя, Очень даже решает: снесли сдуру диру. Высрaли кирпичей. Откатили в вид как было. Ощутили облегчение т.к. кирпичи высирaться прекратили :) > гарантируя целостность его данных. А фокус в том что старое состояние не разрушается. Если случится факап то как минимум вы останетесь с оригиналом старой версии, а не каким-то полуперезаписанным нечто.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	167. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 04-Июн-12, 02:32
	В контексте обсуждений это та же хрень, что и с журналом, только сбоку. Тут обсуждается конкретная проблема: пропадает питание системы, а файл не успел записаться. Единственное решение - обеспечить работоспособность до завершения записи, а т.к. эта самая работоспособность не управляется файловой системой, то и обеспечить гарантию записи она не может, зато может ИБП. Вот и все. Какая там ФС (версионная или нет) все равно. ЗЫ С другой стороны ФС вполне в силах (и по большей части обязана) обеспечить валидность своего состояния т.к. работает на подверженной ошибкам и поломкам системе.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	152. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:37
	> Ман версионные FS. Никакой атомарности нам нахрен не нужно. С этой точки зрения атомарность - костылик обычным ФС по сути :). А у этих некое подобие оной само получается, за счет принципов работы.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	168. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 04-Июн-12, 02:39
	>> Ман версионные FS. Никакой атомарности нам нахрен не нужно. > С этой точки зрения атомарность - костылик обычным ФС по сути :). > А у этих некое подобие оной само получается, за счет принципов > работы. Атомарность - свойство, а не сущность, т.е. иными словами не может быть костылем по определению. Или я не понял что вы имеете под словом "костыль". А потом, какая разница введена она в дополнение к уже спроектированной архитектуре или заранее включена в нее при проектировании. Главное конечный результат. ЗЫ Вы очень вольно разделяете "обычные ФС с костыликом" и "остальные". Так уж заведено, что универсальных и в то же время самых лучших вещей не бывает, так что где-то ZFS, а где-то и FAT лучший выбор.
	Ответить | Правка | ^ к родителю #152 | Наверх | Cообщить модератору

	56. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 19:50
	Журнал решает совсем другую проблему - поддерживает целостность самой ФС, а не данных. Избыточность и сохранность уже существующих данных пока что умеет фс типа ZFS и прочие, которые умеют делать реплики на несколько физически разных носителя. И  таки да, это забота ФС в частности, но не все это умеют
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	129. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 20:43
	>Сохранность данных во время операций записи, связанная со сбоями оборудования, не забота ФС может есть и такие, но я о них не знаю, да и не интересовался) кто сказал zfs?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	132. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 03-Июн-12, 22:14
	И она конечно гарантирует, что например при отключении питания все данные будут записаны? Не смешите.
	Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

	165. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 02:10
	> И она конечно гарантирует, что например при отключении питания все данные будут > записаны? Не смешите. Такие ФС гарантируют что у вас или уж старая версия файла, или новая. А не непойми что, когда половина новое а половина старое. Так что вообще фиг такой файл прочтешь.
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	169. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 04-Июн-12, 02:41
	>> И она конечно гарантирует, что например при отключении питания все данные будут >> записаны? Не смешите. > Такие ФС гарантируют что у вас или уж старая версия файла, или > новая. А не непойми что, когда половина новое а половина старое. > Так что вообще фиг такой файл прочтешь. К сожалению тут, как уже отписался выше на 1 пост, обсуждается мной озвученная ситуация с отключением питания.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	33. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:26
	> Журналы то вообще я правильно понимаю? Есть 2 журнала, сначаа в первый > пишется, что что файл такой-то изменился, потом он меняется (если в > этот момент ошибка то во второй журнал не пишется и изменение > потом откатывается) затем, если все ОК, то пишется во второй журнал. Во первых, журнал - один. В него сначала пишутся намерения. Если облом на этой фазе, все остается в старом состоянии, как будто записи не было совсем. Потом из него все переносится в основную область ФС. Если облом настигает в этом месте, операция доводится до финиша из информации в журнале. Во вторых, не все так просто. Как вы заметили, в этой логике есть двукратная запись - сначала в журнал, потом на диск. Даже в самом хорошем случае скорость записи в этой схеме лишь половина от того что может диск. Поскольку все пишется 2 раза. По этому поводу часто используют компромиссные варианты, когда журналятся только метаданные, а данные - увы. При этом файловая система будет всегда в логически корректном состоянии, однако данные файла который записывался в момент краха в некоторых случаях могут оказаться наполовину старыми и наполовину новыми. Зато скорость проседает не в 2 раза а лишь немного, т.к. 2 раза пишутся только метаданные. p.s. в результате придумали видоизменение техники журналирования известное как CoW. Там при полном журналировании и данных и метаданных запись делается лишь 1 раз. Как бонус - за счет недеструктивной записи оно совершенно штатно может без всяких костылей хранить множество версий файла.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	38. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:38
	В COW тоже накладные расходы высокие. При изменении файла, он еще и копируется в другое место. Я так понял, в ext4 журналируются только или в основном метаданные. По данным гугля это съедает 20% скорости. Сам гугль отказался от журналирования в чего-то редового, об этом писали.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	47. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 02-Июн-12, 18:34
	Глупости. Пишется в новое место только блок/кластер/сектор(зависит от термина минимального объёма данных конкретной фс), который был подвергнут изменению. Очевидно что это такой же объём, если бы он писался в тоже место.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	57. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 20:00
	такой же объём для сектора, но никто не гранулирует по секторам. Грануляция идёт по кластерам (везде), но это не самое главное и мелочь. А главное, что одна операция COW, пусть даже одного кластера, может породить ещё целую кучу IOPSов т.к. это требует обновление "деревьев" карт и прочих метаданных. И тут именно IOPSы, не просто линейное чтение/запись, что может оказаться весьма затратным.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	80. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 02-Июн-12, 21:55
	:D Всё верно... почти. Вот только всё ЭТО только отговорка от темы "перезаписи всего файла" :D Зыж "Пересборка деревьев и тд" в памяти и сброс потом (!!!) на диск не более затратен, чем тоже журналирование сабжа. А местами и менее.
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	83. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 02-Июн-12, 22:01
	Ззыж > Грануляция идёт по кластерам (везде), но это не самое главное и мелочь. Во-первых это вопрос терминологии. Во-аторых размер сектора бывает разный. (А теперь и блока) В-третьих блок в фс и блок на диске — разные понятия. Мы говорим именно о блоке в фс (в zfs к примеру до 128кб. Или уже больше можно).
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	85. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 22:35
	это называется кластером и никто не оперирует в ФС сектором.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	89. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 02-Июн-12, 23:15
	БЛОКОМ. сознательно заметаете свой слив.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	149. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–2 +/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:32
	> 128кб. Или уже больше можно). А все-равно тупо. У нормальных людей нормальные экстентные аллокаторы уж давно, а у этих - ни два, ни полтора. Ничо, btrfs покажет вам как надо файловые системы дизайнить.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	153. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от iZEN (ok) on 04-Июн-12, 01:40
	> Ничо, btrfs покажет вам как надо файловые системы дизайнить. "С нетерпением ждём и надеемся. :))" © Счастливые пользователи ZFS. Так когда ждать "кузькину мать", никитасергеич?
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	164. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 02:07
	>> Ничо, btrfs покажет вам как надо файловые системы дизайнить. > "С нетерпением ждём и надеемся. :))" © Счастливые пользователи ZFS. Это того который даже отдебажить нормально не могут до сих пор, так что полно визгов о взвисе при нагрузке? Спасиб, мы не привыкли третий сорт скинутый под стол кушать. > Так когда ждать "кузькину мать", никитасергеич? Soon (tm).
	Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

	184. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от schwed on 04-Июн-12, 11:35
	>Ничо, btrfs покажет вам как надо файловые системы дизайнить. Вот только вопрос кто кому и чего покажет... :)
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	86. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 22:36
	какая разница где она происходит, этот процесс порождает несколько грязных кластеров которые тоже нужно сбрасывать.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	90. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 02-Июн-12, 23:17
	Так что там с перемещением всего файла и оверхедом коу?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	97. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 01:16
	про весь файл писал кто-то другой :)
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	99. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от ананим on 03-Июн-12, 01:40
	:D
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	100. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 01:42
	> про весь файл писал кто-то другой :) Я писал. Первый снепшот в LVM2 дает сильное замедление в работе, последующие практически не влияют. Я конечно в деталях не силен, но если раздел COW толстеет, на объем измененных данных (и в исходном разделе существуют уже новые данные вместо старых), то они скорее всего перемещаются ))
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	151. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:36
	> Я писал. Первый снепшот в LVM2 дает сильное замедление в работе Я думаю что теперь вы понимаете почему так активно пилят btrfs. Там снапшоты - нативное свойство механики. Ну и тормозить при их создании нечему. Пометка некоей точки в которой данные и метаданные консистентны как "снапшот" много времени сама по себе не занимает. > раздел COW толстеет, на объем измененных данных Но не объем всего файла! > (и в исходном разделе существуют уже новые данные вместо старых), > то они скорее всего перемещаются )) Никто в CoW ничего не перемещает покуда юзверь не вожелает новую версию неких блоков записать. Эти блоки и так и сяк бы записались. Только в случае классики они бы полетели прямо в основную версию файла, а в CoW - в сторонку, оставив оригинал нетронутым.
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	145. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:17
	> В COW тоже накладные расходы высокие. При изменении файла, он еще и > копируется в другое место. Никуда там файл не копируется. При записи изменений: 1) В сторонку пишется блок с этими самыми изменениями, по количеству оных. 2) Структуры ФС описывающие размещение файла меняются чтобы указывать что теперь вон тот кусок файла брать надо вот там, а не там где было раньше. Собственно операция записи измененного куска и есть то "копирование". Bonus 1: поскольку старое содержимое никто не сносил, на него в принципе можно вернуться. Этакая машина времени - условно нахаляву. Достаточно вернуть описание размещения файла в старый вид и готово: у вас получается старый вариант файла. Bonus 2: в принципе подвид этой техники можно применить и к самим структурам ФС, так что в результате будет ну совсем просто городить снапшоты - для них всегда все и так есть, достаточно лишь зафиксировать консистентное состояние и объявить что "а вот это - типа снапшот". При этом действий по его созданию минимум: все структуры потребные для этого и так уже были, осталось только формально задекларировать и сделать пометочку, чтоб GC это не подгреб при случае как нечто "устаревшее". Из недостатков этого подхода: 1) Очевидно что линейный доступ к такому файлу превратится в нелинейный. В принципе эта схема более склонна к фрагментации. На механических дисках сие может икаться. 2) Без принятия специальных мер место на томе рано или поздно закончится. Поэтому требуется Garbage Collector. Который однажды придет и грохнет тот перезаписанный блок в середине файла, пометив его как "пустое место которое можно использовать", так что старая версия "перестанет существовать". В принципе, оный может быть совмещен с дефрагером, избавившись от первой проблемы, т.к. логично было бы и вдвинуть как раз "скопированный" фрагмент в "только что получившееся пустое место" (если конечно оно туда лезет). В btrfs примерно так и делают IIRC. > Я так понял, в ext4 журналируются только или в основном метаданные. В дефолтной настройке большинства дистров - только метаданные. Если вы хотите еще и данные, такая опция есть. Но вам не понравится скорость работы. Это для тех кому транзакционная модель важнее всего остального, любой ценой. > По данным гугля это съедает 20% скорости. Сам гугль отказался от журналирования > в чего-то редового, об этом писали. А гугль вообще особый случай. Понимаете, им вообще глубоко плевать - в их распределенной структуре один узел может не то что сбойнуть, а выгореть синим пламенем. Никто и не заметит что там что-то не так: данные есть и на иных узлах, они подхватят нагрузку и как будто бы ничего и не умирало. А у вас тоже есть такая крутая распределенная ФС, что вы можете спокойно наплевать вообще на вылет парочки компьютеров в распределенном сторадже? :)
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

14. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
Сообщение от АнонимЪ on 02-Июн-12, 14:01
Если формат метаданных изменился, значит получается несовместимость с предыдущими версиями ядра?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	23. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 15:31
	Вариант с простым игнорированием данной информации более ранними версиями Вами не рассматривается в принципе?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

15. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
Сообщение от anonymous (??) on 02-Июн-12, 14:14
Не совсем понятно это чего ? Что разе ехт4(ехт2) не могла чекать данные ? А другие фс ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:39
	разрушение метаданных может вынудить fsck порубить нормальные данные в капусту. Другие системы: http://en.wikipedia.org/wiki/Comparison_of_file_systems#Meta... (последняя колонка)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	92. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от anonymous (??) on 02-Июн-12, 23:33
	> разрушение метаданных может вынудить fsck порубить нормальные данные в капусту. Это понятно. Понятно даже почему это было на кассетах от БК, но как это может произойти на винте не очень понятно, кто поцарапает то его ? P.S. Нужно было тогда уж не црц пихать а уж сразу пихать что то типа - https://en.wikipedia.org/wiki/Reed–Solomon_error_corre... вот тогда был бы профит !
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	154. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:40
	> Это понятно. Понятно даже почему это было на кассетах от БК, Наверное потому что это файловой системой толком не являлось. А чексумм блоков сам по себе - не больно какая ракетная наука.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

20. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
Сообщение от Panasonic1 (ok) on 02-Июн-12, 15:06
А есть инфа как изменится занимаемое место?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	58. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 20:02
	увеличится на 4 байта per inode /петросян
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

24. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
Сообщение от dalco (ok) on 02-Июн-12, 15:39
Да, посмотрели разработчики на ZFS/BTRFS и закричали "мы тоже такое себе хотим" :) P.S. Если бы этот патч еще и контрольные суммы данных проверял - вообще бы красота была.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 15:46
	> Да, посмотрели разработчики на ZFS/BTRFS и закричали "мы тоже такое себе хотим" > :) > P.S. Если бы этот патч еще и контрольные суммы данных проверял - > вообще бы красота была. Зачем это надо не расшифруете?
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	34. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 17:31
	> Зачем это надо не расшифруете? Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент их появления, а не когда половина файловой системы превратится в какие-то макароны.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	44. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 18:00
	>> Зачем это надо не расшифруете? > Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент их > появления, а не когда половина файловой системы превратится в какие-то макароны. Во первых, на сколько мне известно, хранимая на винте информация п.у. имеет избыточность в виде хранения ее CRC, которая отслеживается самим винтом. Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое контроллеру. Во вторых, что мешает самому вычислить CRC для требуемых данных? Возможно есть какие-либо "подводные камни" о которых я не знаю. То, что может с бОльшей эффективностью (из-за наличия дополнительной информации) управляться на других уровнях системы хранения данных должно управляться на них, иначе будет иметь место избыточность в виде выполнения одного и того же действия (трата ресурсов) или неоправданное возрастание сложности системы (читать как наличие потенциально большего количества ошибок) в результате создания дополнительного связывания ее элементов, работающих на разных уровнях (в перспективе, из-за этого уменьшается также и ее гибкость). В данном случае, возможно Вам не нужно отслеживать все данные или, при постоянном их изменении как в случае с БД, просчитать CRC вообще будет невозможно, либо возможно, но с большими потерями ресурсов системы.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	51. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от dalco (ok) on 02-Июн-12, 18:43
	К сожалению, нет гарантии, что на винте записаны те самые данные, что мы хотели записать. В реальной жизни то шлейф к винту барахлит, то питание моргает, то память сбоит, то ОС вразнос пошла. А на винте его внутренние CRC при таких неисправностях вполне правильные - он же не в курсе, что ему мусор для записи передали :) Вот для подобных случаев дополнительная CRC на уровне файловой системы и выше становится полезна. Кстати, там еще и некоторый бонус всплывает - после сбоя проще повреждения искать. Где CRC нарушено - там точно усиленные раскопки нужны. P.S. А если еще и данные в файловой системе CRC прикрыты, то вообще красота. При периодической фоновой проверке я не только узнаю о наличии проблем, но я еще и буду точно знать - какие конкретно файлы накрылись медным тазом, что, зачастую, крайне полезно при реанимации зомби-компа.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	53. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от анон on 02-Июн-12, 19:12
	> К сожалению, нет гарантии, что на винте записаны те самые данные, что > мы хотели записать. В реальной жизни то шлейф к винту барахлит, > то питание моргает, то память сбоит, то ОС вразнос пошла. А > на винте его внутренние CRC при таких неисправностях вполне правильные - > он же не в курсе, что ему мусор для записи передали > :) Вот для подобных случаев дополнительная CRC на уровне файловой системы > и выше становится полезна. Ошибки интерфейса отлавливаются точно (см. SMART). Буферная память ЖД также может быть проверена (MHDD, Victoria). Питание, уж извините, ИБП решает. Память тоже с избыточностью бывает, вплоть до восстановления информации "на лету". ОС оно конечно серьезно, но такого уровня компоненты, работающие внутри ядра, должны и скорее всего усиленно тестируются. Не надо также забывать и о проверке "временем", т.е. пользоваться не самым новым, а зарекомендовавшим себя ядром/софтом/железом там , где нужна повышенная надежность. Делайте копии, профилактику и будет счастье. > Кстати, там еще и некоторый бонус всплывает - после сбоя проще повреждения > искать. Где CRC нарушено - там точно усиленные раскопки нужны. Никак не проще. Постройте себе дерево из CRC для интересующей части ФС и сверяйте ее с текущим. Вот и все. > P.S. А если еще и данные в файловой системе CRC прикрыты, то > вообще красота. При периодической фоновой проверке я не только узнаю о > наличии проблем, но я еще и буду точно знать - какие > конкретно файлы накрылись медным тазом, что, зачастую, крайне полезно при реанимации > зомби-компа. Если "зачастую крайне полезно", то у Вас уже есть примеры реализации подобных возможностей. Если не сложно поделиться инфой, поделитесь. Делая своевременные копии информации мне все равно что случится с компом и я всегда уверен, что если выяснится факт некорректности файла - я смогу взять его из проверенной копии. Все проблемы решаемы, и не надо придумывать себе задачи, которые кроме как к новым проблемам ни к чему не приведут, и их решать.
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	62. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+4 +/–
	Сообщение от dalco (ok) on 02-Июн-12, 20:19
	>Ошибки интерфейса отлавливаются точно (см. SMART). Буферная память ЖД также может быть проверена (MHDD, Victoria). Питание, уж извините, ИБП решает. Память тоже с избыточностью бывает, вплоть до восстановления информации "на лету". ОС оно конечно серьезно, но такого уровня компоненты, работающие внутри ядра, должны и скорее всего усиленно тестируются. Не надо также забывать и о проверке "временем", т.е. пользоваться не самым новым, а зарекомендовавшим себя ядром/софтом/железом там , где нужна повышенная надежность. Делайте копии, профилактику и будет счастье. В идеальном мире из идеальных программ и идеальной аппаратуры вообще ни журналов, ни fsck не нужно. Одна беда - живем-то мы в реальном :) И смарт не всегда отслеживается, и рейд-контроллер глючит, и банальная несовместимость железа при конкретной версии прошивки винта. Особенно весело, когда винт не один, а сотня-другая, и тестить их все через MHDD, мягко говоря, некогда. >Если "зачастую крайне полезно", то у Вас уже есть примеры реализации подобных >возможностей. Если не сложно поделиться инфой, поделитесь. >   Делая своевременные копии информации мне все равно что случится с компом и я всегда >уверен, что если выяснится факт некорректности файла - я смогу взять его из проверенной >копии. > >   Все проблемы решаемы, и не надо придумывать себе задачи, которые кроме как к новым >проблемам ни к чему не приведут, и их решать. Ок, пример из реальной жизни. Глючит рейд-контролер. Не так, чтобы вообще сплошной мусор пишет, но иногда с ним такое случается. И до вас это дошло только сейчас. В разделе несколько десятков терабайт информации, сервак работает и останавливать его крайне не желательно. Восстановление информации из бэкапа - гарантированные пол-суток простоя. Самое обидное, что непонятно - нужно ли вообще делать эти действия, быть может, вся инфа на разделе вполне валидная. И я попадал в эту ситуацию. Единственный плюс - начальство знало, что сервак глючит, и было морально готово к его остановке, благо, его близнец на другом краю России работал без сбоев. В случае того же ZFS/BTRFS раз в сколько-то времени в фоновом режиме по всему диску проходит демон, проверяя файловые CRC. Если что, он просто кидает мне письмо, что файлы такие-то и такие-то накрылись и резервной копии у системы нет (а бывает, что есть, и демон сам все восстановит). И, зная конкретный убитый файл, я уже буду распаковывать не весь бэкап, а только его малую часть, сэкономив кучу времени. Заодно я буду в курсе, что с файловой системой что-то не так, хотя вся аппаратура мониторинга молчит, как партизан. P.S. Если какая-то фича для вас не очевидна и не особо нужна, то это еще не значит, что она не нужна другим.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	65. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 20:35
	> В идеальном мире из идеальных программ и идеальной аппаратуры вообще ни журналов, > ни fsck не нужно. Одна беда - живем-то мы в реальном > :) И смарт не всегда отслеживается, и рейд-контроллер глючит, и банальная > несовместимость железа при конкретной версии прошивки винта. Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования. Все что Вы перечислили к ФС не имеет никакого отношения. Согласен, что она должна по возможности сопротивляться реалиям, но требовать от нее полного обеспечения безопасности хранения как минимум недальновидно по причине неминуемого падения других характеристик (скорость, простота использования, падение эффективности использования ресурсов системы) и как максимум невозможно т.к. она полностью зависит от системы, где она работает, на которую она не в силах никак повлиять. > Ок, пример из реальной жизни. Глючит рейд-контролер. Не так, чтобы вообще сплошной > мусор пишет, но иногда с ним такое случается. И до вас > это дошло только сейчас... > В случае того же ZFS/BTRFS раз в сколько-то времени в фоновом режиме > по всему диску проходит демон, проверяя файловые CRC. ... Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. > P.S. Если какая-то фича для вас не очевидна и не особо нужна, > то это еще не значит, что она не нужна другим. Я где-то написал что это не нужно? Странно что нормальные вопросы и попытки добраться до истины вещей у вас вызывают такие чувства.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	67. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 20:47
	> Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. кто будет восстанавливать запорченные реплики нормальными? Что вы тут вещаете это костыль для ФС которые не умеют этого делать. У систем безопасности юз-кейсы совсем другие и их использование мягко говоря, геморное. Как собираешься отслеживать изменение данных без поддрежки ФС? Придётся вещать кучу костылей в ОС и городить прочие подпорки.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	70. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–2 +/–
	Сообщение от анон on 02-Июн-12, 20:57
	>> Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. > кто будет восстанавливать запорченные реплики нормальными? Что вы тут вещаете это костыль > для ФС которые не умеют этого делать. То, что я "вещаю" есть способ решения задачи. То, что Вы говорите (заметьте отсутствие хамского тона), что это костыль, еще не значит, что встроенная поддержка в ФС решает эти задачи лучше. По вашей логике, все программы надо объединить с ядром ОС и запускать всю систему как единый исполняемый файл иначе все будет в виде костылей к ядру. > У систем безопасности юз-кейсы совсем другие и их использование мягко говоря, геморное. > Как собираешься отслеживать изменение данных без поддрежки ФС? Придётся вещать кучу > костылей в ОС и городить прочие подпорки. И какие данные на сервере изменяются? БД? И как их поможет отслеживать хваленые ZFS/BTRFS?
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	69. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от dalco (ok) on 02-Июн-12, 20:56
	>Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования. Все что Вы перечислили к ФС не имеет никакого отношения. Имеет, к сожалению. Целостность FS от всего вышеперечисленного нехило зависит. И если FS не знает о наличии проблем в аппаратуре, то это еще не значит, что этих проблем нет. >Согласен, что она должна по возможности сопротивляться реалиям, но требовать от нее полного обеспечения безопасности хранения как минимум недальновидно по причине неминуемого падения других характеристик (скорость, простота использования, падение эффективности использования ресурсов системы) и как максимум невозможно т.к. она полностью зависит от системы, где она работает, на которую она не в силах никак повлиять. А никто и не требует от FS невозможного. Просто добавили ей еще один шанс, который иногда помогает. >Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. А зачем мне изобретать велосипед, городить скрипты, когда со всем этим легко и не напряжно справится утилита из состава этой самой FS. Почему мне не нравится отдельная прога? Элементарно - FS лучше знает - где и как ей лучше себя проверять, не мешая другим, и как лучше восстановиться, не прерывая рабочего процесса (если таковая возможность есть). К тому же, подобная проверка вполне может идти на уровне ядра - т.е. быстро и без заморочек с правами.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	72. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 21:10
	>>Я говорил о реально отслеживаемых ошибках, а не о способах их диагностирования. Все что Вы перечислили к ФС не имеет никакого отношения. > Имеет, к сожалению. Целостность FS от всего вышеперечисленного нехило зависит. И если > FS не знает о наличии проблем в аппаратуре, то это еще > не значит, что этих проблем нет. А то, что все это зависит от прямости рук админа? От этого она не должна защищать? Может и руки продублировать? Есть же предел издевательствам! Или нет? > А никто и не требует от FS невозможного. Просто добавили ей еще > один шанс, который иногда помогает. Просто не надо на этом концентрировать внимание. Добавили - хорошо. Кстати я в обсуждении имел ввиду проверку именно данных, а не внутренних данных ФС. Если вы имеете ввиду второе и спорите на счет первого, то мы не договоримся. >>Что мешает сделать это без поддержки со стороны ФС? Существуют системы безопасности, отслеживающие целостность и неизменность данных как раз по CRC. Это практически тоже самое. > А зачем мне изобретать велосипед, городить скрипты, когда со всем этим легко > и не напряжно справится утилита из состава этой самой FS. Т.е. у вас нет проблемы стабильности т.к. вы не решали ее скриптом, но задарма получая возможность это делать, вы готовы "сровнять с землей" другие решения лишь бы оправдать свое неосиляторство. Или я не прав и есть реальные доводы в пользу ФС? > Почему мне не нравится отдельная прога? Элементарно - FS лучше знает - > где и как ей лучше себя проверять, не мешая другим, и > как лучше восстановиться, не прерывая рабочего процесса (если таковая возможность есть). > К тому же, подобная проверка вполне может идти на уровне ядра - > т.е. быстро и без заморочек с правами. Лучше всего знает админ когда ему требуется проверка данных, каких конкретно данных, и насколько ему это надо (в ущерб производительности или во время простоя). Этого ФС знать не может. В ином случае это объединение решения различных задач в одном месте - комбайн. Еще раз, ИМХО CRC метаданных - хоошо, CRC данных пользователя - отчасти невозможно и полностью не нужно.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	75. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от dalco (ok) on 02-Июн-12, 21:39
	Хм, попробую объяснить последний раз... Есть железо, НЕидеальное железо. Есть FS, которая живет на этом НЕидеальном железе. Все, что мне от этой FS нужно - чтобы она надежно хранила данные или хотя бы сообщала, где она лажанулась. Т.е. я либо получаю от нее данные, которым я верю без дополнительных проверок с моей стороны, либо 100% же уверенность, что такой-то файл в такой-то ноде потерян. Для этого и нужно полное CRC (не только метаданные, но и сами данные). Для меня, как конечного пользователя, FS - "черный ящик". Что и как она там делает - не моя забота, главное, чтобы данные были целы. И я не должен бегать за FS и подтирать ей сопли каждый раз, когда она споткнется. Пусть выживает сама по мере сил. В случае одного-двух серверов я могу потратить время на тонкий тюнинг FS, доскональное тестирование железа и навешивание third party костылей. Когда серверов сотни, мне заниматься этим некогда. Вот отсюда и растут ноги у ZFS/BTRFS - они выживать в реальном мире научились (по крайней мере, на бумаге). P.S. Усе, иду баиньки, буду сверять CRC нейронов :)))
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	78. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 21:54
	Все, что я узнал из вашего поста - не хочу знать где как и что работает, хочу всех проверок на всех уровнях и много денег на железо, которое все это потянет. Это похоже на паранойю. Когда в меру, то все нормально ибо некоторый запас всегда должен быть, но тут уже тяжелый случай. Объяснять начиная каждую фразу "Все, что мне нужно", "Для меня", "И я не должен" и т.д. как-то странно. Не много ли зависит от Вашей личности? Вы или идеальный и безгранично опытный админ и ваша речь что-то значит, либо админ не знающий своего железа и Ваша речь не более чем болтовня и сказки. ЗЫ Спокойной ночи.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	95. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от mix (??) on 02-Июн-12, 23:47
	страшно похоже на знакомую на шкуре  полемику ленивого(по определению) админа и манагера ) типа - а сделайте мне красиво и бесплатно.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	119. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 15:49
	тут всё прозаичнее, полемика условного технаря с ламерьём (это анон). Только ламерьё какое-то усердно-упороте попалось
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	121. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 03-Июн-12, 16:28
	Прозаичнее, это да. Думаю что проблема в том, что моя точка зрения "не модная" и требует некоторых знаний, а тут попался практик (я серьезно), который не привык думать как и что работает, а привык получать результат. Это в общем-то нормально - каждому свое. Отсюда и безосновательные высказывания и призывы к тому, что он считает верным. Одно "но", его мнение и реальное положение дел - это разные вещи, что из-за "скромности" понять ему не дано. Я вполне допускаю, что я также могу ошибаться, но соглашаться со мнениями других без каких либо реальных доводов...
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	128. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от dalco (ok) on 03-Июн-12, 19:11
	Господа, все довольно просто. Были времена, когда мне действительно было интересно устройство каждой железки и каждой софтины в компе. Мне не влом было сотворить собственными руками какой-нибудь аппаратный или програмный прибамбас для компа. Очередной велосипед изобретался ради самого процесса изобретения. Генерилась куча кода на асме и Си ради повышения ЧСВ и просто ради фана. Но время шло, я все дальше уходил в глубины энтерпрайза... И обнаружил пренеприятнейшие вещи. Оказалось, что велосипеды не столько повышают ЧСВ, сколько приносят попоболи. Каждый велосипед надо подробно документировать, за его поведение материальную ответственность несешь именно ты, а вот бонусов никаких, кроме устного поощрения от начальства (очень изредка). К тому же, в энтерпрайзе ценятся не те решения, которые красивые, а те, что надежные, документированные,требующие минимальной поддержки и, в случае чего, легко починяемые/заменяемые не очень квалифицированным персоналом типа приходящего админа-студента. Так что теперь я копаю документацию ровно настолько, сколько необходимо и достаточно для запуска очередного "черного ящика". В случае проблем оказывается гораздо быстрее и дешевле взять аналогичную деталь со склада или типовую виртуалку из бэкапа, чем рыться во внутренностях железки с паяльником или искать в каком конфиге что слетело. Да, теперь я почти не думаю, ибо для 99% ситуаций уже готовы типовые решения. И я не бегаю со взмыленной задницей, лихорадочно вспоминая где и за какую хрень у компа XYZ надо дернуть, чтобы оно опять полетело в правильном направлении. И, самое странное, меня это вполне устраивает :)
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	133. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 03-Июн-12, 22:29
	Так с этого и надо было начинать. ИМХО все хорошее начинается с велосипедов и нестандартных решений иначе было бы все одинаковое. Просто есть гарантированные общеизвестные вещи, о которых если знаешь, то становится жить легче, а то можно дойти что все проги в отладочном режиме запускать что бы ни одна ошибка не прошла мимо. А так полностью согласен, кому-то нужен результат, а кому-то процесс и/или перспектива.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	163. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 02:05
	> Так что теперь я копаю документацию ровно настолько, сколько необходимо и достаточно > для запуска очередного "черного ящика". Поздравляю, ваш мозг заржавел. Правда с этим обычно не поздравляют... > И, самое страшное, меня это вполне устраивает :) Небольшой фикс. Ибо когда мозг заржавел - это страшно. По сути это уже отработанный материал.
	Ответить | Правка | ^ к родителю #128 | Наверх | Cообщить модератору

	136. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от Аноним (??) on 03-Июн-12, 22:51
	Ваша точка зрения не требует знаний, она ровно такая же модная как и все здесь остальные. Да, были времена, лет эдак 15-20 назад, когда на любую проблему был подход подобный вашему и тогда это был модно. Подобный это найти близкую по звучанию технологию для проблемы X и пихать её куда попало, мол 'зачем решать эту проблему, мы же можем прикостылять сюда X или Y'. У некоторых даже поворачивался язык называть этот бред юникс веем. К счастью, эти времена ушли, многие успели набить на этом ишики и стали ценить технологичность решений. А о тех временах сейчас напоминает некоторое легаси  и немногочисленные  личности вроде вас, которые остались в своём понимании и видении развития технологий в 8х-9х годах. >  который не привык думать как и что работает, а привык получать результат. а кто тут привык думать, вы чтоли? Не очень это заметно, по крайней мере, совсем не похоже что область ваших дум как-то пересекается с айти.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	138. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 03-Июн-12, 22:56
	Ваше мнение очень важно для нас. Ждите, мы сами Вам позвоним. ЗЫ Еще один аноним не умеющий читать от начала до конца.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	116. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от kurokaze (ok) on 03-Июн-12, 13:56
	>Когда серверов сотни, мне заниматься этим некогда. Что, в две смены бедняга поди ишачишь? Завтра серверов старент сотни тысяч и тебе прийдется в третью смену выходить, бггг
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	155. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:49
	> Во первых, на сколько мне известно, хранимая на винте информация п.у. имеет > избыточность в виде хранения ее CRC, которая отслеживается самим винтом. Даже круче: ECC, которая при сбое чтения пытается скорректироваться самим винтом, прозрачно для вас. В идеале фирмваре еще и проблемный сектор на резервный ремапнуть должно бы (правда у некоторых дисков оно столь тупое что убедить его увидеть сбойный сектор можно только спецпинком по болючему месту). > Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое > контроллеру. Нифига он не сообщит - если удалось починить то вы получаете данные. Если не удалось - read error. Статистика полетов - в SMART. > Во вторых, что мешает самому вычислить CRC для требуемых данных? Возможно есть > какие-либо "подводные камни" о которых я не знаю. Ничто не мешает, кроме того что ФС это может делать прозрачно и для всего, а в остальных случаях - надо явно позаботиться. > постоянном их изменении как в случае с БД, просчитать CRC вообще > будет невозможно, либо возможно, но с большими потерями ресурсов системы. Что за идиотека? Кто запретил считать CRC поблочно?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	193. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 04-Июн-12, 22:13
	> Нифига он не сообщит - если удалось починить то вы получаете данные. Если не удалось - read error. Статистика полетов - в SMART. И что вам не понравилось, будет ошибка - сообщит, будет исправимая ошибка - не сообщит. В чем проблема? Или Вам надо по каждой проблеме свой лог вести, даже если проблема и не проблема вовсе? На счет работы ЖД я в курсе. Ремап можно запустить многократной записью в сектор с большим временем доступа. Предполагаю, что с некоторыми конкретными моделями есть нюансы, но это не суть важно. > Ничто не мешает, кроме того что ФС это может делать прозрачно и для всего, > а в остальных случаях - надо явно позаботиться. dalco уже говорил, что в случае ZFS/BTRFS по диску проходит демон и проверяет CRC. Точно такого же демона (по сути, это та же программа или, с определенной натяжкой в деталях реализации, скрипт) можно сделать универсальным для всех ФС. Так зачем делать из кода поддержки ФС кухонный комбайн и жить в ожидании что какая-нибудь из тех встроенных хреновин, без которых "нельзя" прожить, не "накроет" всю информацию на винте? Из практических соображений критические области, коей по факту важности и является ФС, необходимо уменьшать и упрощать, а тут предлагают сделать разжиревшее и потенциально небезопасное с точки зрения хранения информации, мягко говоря, уродство. Ошибки надо исправлять на том уровне, на котором их возможно в наиболее полной мере исправить. Это возможно при обладании максимально полной информацией о том, чего Вы хотите. ФС этого знать не может. Можно конечно сделать механизм, позволяющей сделать это, но надо ли это все, если вполне реально обеспечить ту же функциональность другими, более универсальными, а скорее всего и не мене (если не более) эффективными средствами, в наибольшей степени отвечающим вашим потребностям. Именно по этому CRC метаданных - есть правильное решение т.к. кроме ФС, владеющей ими, о них толком ни кто не знает (и не должен) и решения должны приниматься именно на этом уровне. В случае же с данными пользователя, они принадлежат именно ему, а не ФС, именно по этому решения по их обслуживанию и само обслуживание должно приниматься и производиться им, конечно при условии, что его интересы не настолько жестко завязаны на конкретную ФС и не требуют проведения специфичных операций. В случае CRC данных пользователя никаких специфичных операций производиться не должно. > постоянном их изменении как в случае с БД, просчитать CRC вообще > будет невозможно, либо возможно, но с большими потерями ресурсов системы. > Что за идиотека? Кто запретил считать CRC поблочно? И как посчитать CRC БД так, чтобы им можно было воспользоваться, при условии, что БД все же используется, а не просто хранится? Подсказка: конечная цель всей этой "камасутры" не посчитать CRC, а установить корректность и неизменность данных, что без привлечения самой СУБД с этой БД невозможно в принципе. Даже если ФС позволяет "заморозить" данные для расчета CRC, то установить момент для "заморозки", когда дынные в БД будут в валидном состоянии, без самой СУБД невозможно. Связь же между СУБД и ФС, которая могла бы включать такую возможность, вообще маразм высшей степени.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	197. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 04-Июн-12, 23:53
	> Сам винт определяет (диагностирует) испорченные данные о чем непременно сообщит о сбое контроллеру. ему аналог CRC нужен совсем по другой причине. Чтение с физического носителя идёт с ошибками и сумму контроллер диска использует для N-кратного перечтения сектора. Только если после M попыток так и не удалось считать блок, то получается ошибка IO. Это рядовое событие для диска (в смысле, перечтение сектора) и здесь нет наложения "уровней", сумма на диске служит совсем иным целям.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	198. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 05-Июн-12, 00:45
	Во-первых, спасибо за детали работы, не знал, хоть к делу это и не имеет отношения. Во-вторых, процетирую dalco: > Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент > их появления, а не когда половина файловой системы превратится в какие-то макароны. и после моего коммента (он же): > К сожалению, нет гарантии, что на винте записаны те самые данные, что мы хотели записать. Так что то, что я имел ввиду я ввиду и имел, что подтверждаете и Вы > Только если после M попыток так и не удалось считать блок, то получается ошибка IO. т.к. потеря доли информации из-за неудачного чтения эквивалентно ее испорченному состоянию. > сумма на диске служит совсем иным целям. Это да, но также она гарантирует и то, что данные считанные с диска - это те же данные, что на него и записывались. Тут же, усиленно предлагают, и за это неистово "плюсуют", ввести второй уровень проверки корректности данных на диске исходя из того, что эта гарантия не работает, причем встроить эту проверку в код работы ФС. Единственное, для чего это может пригодиться, так это для аудита системы и проверки того, что никто не изменил данные извне. Но это вообще к ФС отношения не имеет и в код включаться не должно. Также тут упоминается про ZFS и BTRFS, в которых, со слов того же dalco, имеется встроенная возможность проверки контрольных сумм файлов в ФС. Правда он заметил, что она реализована через демон и работает на уровне ядра (тут у меня есть некоторые сомнения, но разбираться не хочу за ненадобностью). Мной предлагался способ считать контрольные суммы без участия ФС, что я считаю как минимум более логичным.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	200. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 05-Июн-12, 10:50
	> Это да, но также она гарантирует и то, что данные считанные с диска - это те же данные, что на него и записывались. Не гарантирует. Кроме чтения с физического носителя есть ещё firmware котроллера самого диска, а там внутри кэш который навряд ли в лоу энде чем-то вообще защищён. И само firmware тоже нередко бывает с ошибками. HDD это уже давно не просто набор блинов. Ещё раз попробую донести смысл суммы на диске - это часть механизма общения между физ. носителем и firmware диска, и всё. > Тут же, усиленно предлагают, и за это неистово "плюсуют", ввести второй уровень проверки корректности данных нет тут второго уровня, это ваша фантазия и какое-то непонимание что, как и где нужно. > Единственное, для чего это может пригодиться, так это для аудита системы и проверки того, что никто не изменил данные извне. Аудит это совсем другая область и она не имеет отношения к суммам на уровне ФС. Суммы для аудита реализуются совсем другими методами с точки зрения реализации, у них разные временные характеристики и т.п. > Мной предлагался способ считать контрольные суммы без участия ФС, что я считаю как минимум более логичным. если вам нужно просто считать суммы непонятно для какой цели и для чего, то да, их можно считать без ФС и даже без участия каких-либо полезных данных. Тупо можно взять /dev/urandom, посчитать сумму и считать это более логичным чем суммы в ФС
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	204. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 05-Июн-12, 13:54
	Приведу ссылку http://rlab.ru/doc/s.m.a.r.t..html#1511 и цитату: > UltraDMA CRC Error Count > Общее количество ошибок CRC в режиме UltraDMA. > Поле raw value содержит количество ошибок, возникших в режиме передачи > данных UltraDMA в контрольной сумме (ICRC - Interface CRC). > Примечание автора. Практика, собранная статистика и изучение журналов ошибок SMART > показывают: в большинстве случаев ошибки CRC возникают при сильном завышении частоты PCI >(больше номинальных 33.6 MHz), сильно перекрученом кабеле, а также - по вине драйверов ОС, > которые не соблюдают требований к передачи/приему данных в режимах UltraDMA. Это лишь пример ошибок касаемо интерфейса (и вашего буфера, как его части, тоже). Если посмотрите более внимательно то заметите, что HDD отлавливает массу ошибок как аппаратного происхождения, так и программного и, по моему мнению, данным с него можно доверять практически не проверяя (абсолютно конечно, в силу вероятностной природы самого CRC, ничто не может гарантировать, тут я согласен). Можете спорить дальше на этот счет и цепляться к тому, что не ATA единым и что SMART не связана с контроллером и чем либо еще, кроме HDD, но мне все равно, т.к. ваши оправдания в своем же лице подведомственны только специалисту (психиатру). > Ещё раз попробую донести смысл суммы на диске - это часть механизма общения между физ. носителем и firmware диска, и всё. Надо смотреть шире на вещи. Если "внутренние" гарантии (считывание с блинов и передача по интерфейсу) обеспечивают также и "внешние" (гарантия соответствия считанных данных записанным), то это так и есть. А Ваша логика - если проверяется в HDD, то кроме как в HDD это не имеет смысла. В этом плане вы не менее упоротый теоретик, на сколько упорот и практик выше по ветке, но если его можно понять, то Вас я понимать решительно отказываюсь за отсутствие желания заниматься мозговым онанизмом. > нет тут второго уровня, это ваша фантазия и какое-то непонимание что, как и где нужно. На счет своего непонимания слышу от "профессионалов" в каждом посте этой ветки, только вот беда, все доводы они основывают на личных убеждениях и уничижении других. > если вам нужно просто считать суммы непонятно для какой цели... Я даже отвечать на эти "обрубки" моего поста не буду. Если бы Вы умели читать, то поняли, что мне эти CRC никуда не вперлись и ради интереса в мотивации неприменул спросить у "виновника" этого обсуждения. Далее понеслась вся эта тупость, которую Вы безаппиляционно продолжаете.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	209. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 05-Июн-12, 22:06
	> Это лишь пример ошибок касаемо интерфейса (и вашего буфера, как его части, тоже). это пример медийных ошибок, а не буфера.  Точно такие же ошибки как при чтении с носителя, но вдругом месте. Откуда у вас эта трафа на счёт 'вашего буфера'? Достаточно уже кидать ссылки содержимое кторых вам не понятно. > и уничижении других. что же поделать, таков закон джунглей.
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	210. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 05-Июн-12, 23:43
	Вы либо студент-идиот, либо умело здесь им прикидываетесь. Я разговариваю с вами только из-за того, что мне это по приколу. Не злоупотребляйте. Если решите оправдать себя, то пожалуйста приведите ссылки из сторонних, относительно вашего ума, источников (сразу уточняю, что соц. сети и ваша личная страница не покатят) по поводу: 1. "медийная ошибка" (и какие еще в этой классификации присутствуют) 2. "трафа" (цитата "Откуда у вас эта трафа на счёт 'вашего буфера'") 3. "аналог CRC" (сумма на диске; уточните чем фактически отличается если аналог) Как Вы понимаете суть проблемы в данной ветке т.к. мне кажется, что вы ее не понимаете? ЗЫ При условии продолжения безосновательной глупости с Вашей стороны буду считать полный Ваш слив по всем вопросам.
	Ответить | Правка | ^ к родителю #209 | Наверх | Cообщить модератору

	199. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 05-Июн-12, 00:47
	Да, во избежание недопонимания из-за многабуков, обсуждаемые контрольные суммы относятся к данным пользователя ФС, а не к ее метаданным.
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	59. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 20:02
	> P.S. Если бы этот патч еще и контрольные суммы данных проверял - вообще бы красота была. ты же сам сбежишь от такой ФС первым.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

25. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
Сообщение от Crazy Alex (??) on 02-Июн-12, 15:44
Я один не вижу use case для этого? Там, где нужна надёжность, подсчётом контрольных сумм (всех! не только метаданных) занимается слой RAID, а где его нет - значит не больно-то и надо.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 16:35
	Черно-белый мир?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	42. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Crazy Alex (??) on 02-Июн-12, 17:44
	Ну так вам либо хоть как-то важны данные (тогда их надо бэкапить или хотя бы резервировать и проверять не только метаданные) либо вы готовы их потерять раз в три года, что для домашних или офисных машин вполне норма. Рейд сейчас поднять - невелика проблема, чй, не 15 лет назад, когда для этого обязательно нужен был аппаратный контроллер.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	135. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 22:37
	И сейчас ничего не изменилось - по-прежнему нужен аппаратный контроллер.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	162. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 02:03
	> И сейчас ничего не изменилось - по-прежнему нужен аппаратный контроллер. Смотря где. В ряде случаев можно и без него. В том плане что это просто кучка sata или чего там еще, а не нечто умеющее RAID аппаратно.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	187. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от schwed on 04-Июн-12, 14:02
	>И сейчас ничего не изменилось - по-прежнему нужен аппаратный контроллер Изменилось - раньше он был _необходим_
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	60. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	–1 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 20:07
	придурок, рейд не обеспечивает проверку данных, он _не_ считает контрольные суммы и может вернуть херню.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	79. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 21:54
	> придурок, рейд не обеспечивает проверку данных, он _не_ считает контрольные суммы и может вернуть херню. Какой умный и вежливый аноним. Вы когда-нибудь слышали, как работают пятый и шестой уровни рейда?
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	91. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от iZEN (ok) on 02-Июн-12, 23:26
	>> придурок, рейд не обеспечивает проверку данных, он _не_ считает контрольные суммы и может вернуть херню. > Какой умный и вежливый аноним. Вы когда-нибудь слышали, как работают пятый и шестой уровни рейда? А это что-то меняет? Что конкретно, на ваш взгляд, при нормальной работе может _дополнительно_ обеспечить RAID-5(-6), чего не может RAID-1? (Я совсем не имею в виду задействование ещё одного HDD и генерирование CRC в полосе RAID-5 _при_записи_). Давайте узнаем ваши познания в области RAID-5(-6), когда данные просто считываются с них: что у них по-другому, и чем они в чтении отличаются от RAID-1?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	93. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+2 +/–
	Сообщение от Аноним (??) on 02-Июн-12, 23:40
	> что у них по-другому, и чем они в чтении отличаются от RAID-1? Если не знаете - книжки почитайте, статьи. Зачем к людям-то приставать?
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	161. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 02:01
	Это же изен. Не нести фигню он не может: клюв перевешивает.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	156. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:52
	> Что конкретно, на ваш взгляд, при нормальной работе может _дополнительно_ обеспечить RAID-5(-6), > чего не может RAID-1? Raid-6 может задетектить сбойный диск. Ценой за это является лишний шпиндель пущенный на коррекцию ошибок. Грубо говоря если есть N дисков одинакового размера, емкость RAID6 будет (N-2) * размер 1 диска. То-есть, если дисков 3 то эффективная емкость как у 1 диска. Если 4 - как у 2. Если 5 - как у 3. Так что конфиг с менее чем 4 дисками в RAID6 не имеет особого смысла.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	173. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от iZEN (ok) on 04-Июн-12, 03:50
	>> Что конкретно, на ваш взгляд, при нормальной работе может _дополнительно_ обеспечить RAID-5(-6), >> чего не может RAID-1? > Raid-6 может задетектить сбойный диск. Современные hard- и soft-контроллёры RAID-1 тоже. И что? > Ценой за это является лишний шпиндель пущенный на коррекцию ошибок. Эта цена при нормальном-то чтении? Но с какой стати? Мне всегда думалось, что цену за коррекцию ошибок в RAID-5(-6) мы платим только в случае аварийной работы массива — при вылете одного (двух) носителей. Полный страйп (набор) данных вместе с кодом его коррекции мы получаем одновременно со всех шпинделей, поэтому скорость чтения с исправного RAID-5(-6), действительно, почти прямо пропорциональна количеству дисков в массиве, при этом код коррекции не используется, так как не нужен — восстанавливать ничего не требуется. А вот когда RAID-5(-6) переходит в аварийный режим работы (описываю цену), то тут подключается процессор контроллёра (или CPU в soft-RAID) для вычисления недостающих данных набора по оставшимся в живых, и мы получаем тот же самый страйп (набор) данных, как если бы ничего не произошло, но уже знаем, что вылет ещё одного шпинделя из массива — фатален. > Грубо говоря если есть N дисков одинакового размера, > емкость RAID6 будет (N-2) * размер 1 диска. То-есть, если дисков > 3 то эффективная емкость как у 1 диска. Если 4 - > как у 2. Если 5 - как у 3. Так что > конфиг с менее чем 4 дисками в RAID6 не имеет особого > смысла. Да ладно.
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	118. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Михрютка on 03-Июн-12, 14:04
	>> придурок, рейд не обеспечивает проверку данных, он _не_ считает контрольные суммы и может вернуть херню. > Какой умный и вежливый аноним. Вы когда-нибудь слышали, как работают пятый и > шестой уровни рейда? неужели ж 5 и 6 рейды чексуммят мою ФС? осподи, чего только на опеннете не прочитаешь.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	159. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 02:00
	> неужели ж 5 и 6 рейды чексуммят мою ФС? В какой-то роде. В общем случае код коррекции ошибок является и кодом детектирования ошибок. Или по хомячковому - чексуммой :)
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	205. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Михрютка on 05-Июн-12, 15:54
	грамотей-опричник в треде? > В какой-то роде. you doing it wrong. > В общем случае код коррекции ошибок является и кодом > детектирования ошибок. Или по хомячковому - чексуммой :) ну-ну. я ж говорю, чего только на опеннете не начитаешься.
	Ответить | Правка | ^ к родителю #159 | Наверх | Cообщить модератору

	81. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Михрютка on 02-Июн-12, 21:56
	hint: ошибки бывают не только аппаратные, но и программные.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	88. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Crazy Alex (??) on 02-Июн-12, 22:54
	Ну так вероятность ошибки в логике Ext4 ничуть не меньше чем вероятность ошибок в логике RAID5.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	96. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Михрютка on 03-Июн-12, 00:52
	> Ну так вероятность ошибки в логике Ext4 ничуть не меньше чем вероятность > ошибок в логике RAID5. и что?
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	101. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Crazy Alex (??) on 03-Июн-12, 02:01
	В чём хинт-то?
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	103. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 02:40
	В том, что ошибки бывают не только аппаратные, но и программные.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	117. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Михрютка on 03-Июн-12, 14:01
	> В чём хинт-то? не тупи. контроль целостности данных на уровне ФС и контроль целостности данных на уровне СХД никак не связаны между собой.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	123. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Crazy Alex (??) on 03-Июн-12, 17:56
	ну тогда это получается отладочная возможность для разработчиков FS, не более
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	124. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Михрютка on 03-Июн-12, 18:47
	> ну тогда это получается отладочная возможность для разработчиков FS, не более почему? рейды тоже глючат и сбоят. особенно саташные промисы без батареек или всякие nvraid. про raid write hole только ленивый не знает. и не только рейды, и JBOD тож. чем в этой ситуации помешает лишняя проверка на целостность данных? (которая может случиться как по софтовой так и по аппаратной причине) при восстановлении ФС после отказа тоже не лишним может быть.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	127. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от а on 03-Июн-12, 18:48
	> ну тогда это получается отладочная возможность для разработчиков FS, не более вы чего такое все курите ? аппаратный ECC в SDRAM может спасти от разрушения данных или кода одного процесса в результате ошибки другого ? очевидно это разные логические уровни.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

29. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
Сообщение от Аноним (??) on 02-Июн-12, 16:57
Имхо, бесполезно. Лучше бы для RAID1 такое сделали - вот там оно действительно, чтобы понять, какая из черепашек говорит неправду.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+1 +/–
	Сообщение от Crazy Alex (??) on 02-Июн-12, 17:45
	> Имхо, бесполезно. Лучше бы для RAID1 такое сделали - вот там оно > действительно, чтобы понять, какая из черепашек говорит неправду. Вот-вот. Здесь оно на месте было бы.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	50. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 18:40
	> Имхо, бесполезно. Лучше бы для RAID1 такое сделали - вот там оно > действительно, чтобы понять, какая из черепашек говорит неправду. Просто ради интереса, по сообщениям с RAID контроллера или из SMART нельзя это определить? Сам с RAID на практике не сталкивался.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	54. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 19:40
	> Просто ради интереса, по сообщениям с RAID контроллера или из SMART нельзя это определить? Сам с RAID на практике не сталкивался. А если они ничего не говорят, а данные с зеркал приходят разные?
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	61. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 20:18
	Тогда как гарантированно определить что это не контроллер?
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	63. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 20:21
	И да, это реальная ситуация или из раздела "Истории одного анонимуса"? Если реальная, то как все же определили какой?
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	77. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 02-Июн-12, 21:53
	> Если реальная, то как все же определили какой? От балды. Одно из зеркал назначается "первичным", и при несовпадении данных, блок копируется с первичного зеркала на остальные. Если сбой именно на первичном зеркале, а на остальных все правильно - извините, увы вам.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	84. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 02-Июн-12, 22:09
	> От балды. Одно из зеркал назначается "первичным", и при несовпадении данных, блок > копируется с первичного зеркала на остальные. Если сбой именно на первичном > зеркале, а на остальных все правильно - извините, увы вам. А в логах ошибок при этом ни каких не пишется и SMART не меняется? Т.е. тупо по очереди проверяешь каждый диск из зеркала с целью найти корректный?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	157. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:55
	> А в логах ошибок при этом ни каких не пишется и SMART не меняется? А вот это - "как повезет". Вообще, как бы не сильно то удобно и быстро SMART постоянно смотреть у винчей. И то что фирмварь сбоящего удосужится честно зарапортовать все как есть - это та еще лотерея.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	170. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 04-Июн-12, 02:48
	>> А в логах ошибок при этом ни каких не пишется и SMART не меняется? > А вот это - "как повезет". Вообще, как бы не сильно то > удобно и быстро SMART постоянно смотреть у винчей. И то что > фирмварь сбоящего удосужится честно зарапортовать все как есть - это та > еще лотерея. Т.е. валидность одного из зеркал определяется сторонними средствами относительно программно-аппаратной части рейда, а СМАРТ идет как бонус? Неужели ни ЖД ни контроллер никак не реагирует на происходящие ошибки ведь маловероятно (хотя вполне возможно), что проблема зеркала вызвана проблемами железа (контроллер и ЖД)?
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	171. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от анон on 04-Июн-12, 02:50
	> возможно), что проблема зеркала вызвана проблемами железа (контроллер и ЖД)? имелось ввиду НЕ проблемами железа.
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	134. "Для Ext4 представлена поддержка контрольных сумм для проверк..."	+/–
	Сообщение от Аноним (??) on 03-Июн-12, 22:33
	Для RAID1 надо сделать скоростную доставку в ближайшую дурку. Бо находящие в здравом уме люди сию гадость не используют.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

104. "а контрольные суммы для проверки целостности контрольных сумм?"	+/–
Сообщение от Аноним (??) on 03-Июн-12, 03:44
Интересно, а поддержка вторых контрольных сумм для проверки целостности этих уже запланирована?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	105. "а контрольные суммы для проверки целостности контрольных сумм?"	+/–
	Сообщение от dalco (ok) on 03-Июн-12, 07:56
	Это делается проще. Берут другой алгоритм подсчета CRC и просчитывают им все тоже самое, что и первым. И если для блока данных совпадает и первая и вторая CRC, то вероятность, что с ним что-то не так, крайне мала.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	137. "а контрольные суммы для проверки целостности контрольных сумм?"	+2 +/–
	Сообщение от Аноним (??) on 03-Июн-12, 22:55
	это вы сейчас через задницу увеличили битность контрольной суммы
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	185. "а контрольные суммы для проверки целостности контрольных сумм?"	+/–
	Сообщение от dalco (ok) on 04-Июн-12, 12:49
	И да, и нет... Половинки мегаCRC получаются независимы друг от друга. Их вычислять легче в большинстве реализаций, более того, их даже вычислять одновременно можно и нужно попробовать. И косвенно обе половинки друг-друга верифицируют. Если результаты обсчета блока данных совпали для обех контрольных сумм, считай, получили исправный блок данных с CRC повышенной длины. Не совпали для обоих - тоже все понятно. Совпали только для одной, значит с приличной вероятностью вторая CRC посчиталась неверно, а блок данных не при чем. P.S. Все вышеописанное - imho. Если у вас есть убедительные аргументы против, то с интересом выслушаю.
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	194. "а контрольные суммы для проверки целостности контрольных сумм?"	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok) on 04-Июн-12, 22:53
	две CRC вычесленные по разным алгоритмам дают меньшую битность чем одно CRC с большой битностью > И косвенно обе половинки друг-друга верифицируют. Если результаты обсчета блока данных совпали для обех давайте только вот не будем излагать всё это на пальцах, в своём каком-то там особенном понимании > получили исправный блок данных с CRC повышенной длины. повышенной на сколько бит? > Совпали только для одной, значит с приличной вероятностью вторая CRC посчиталась неверно, а блок данных не при чем. с какого это хера вы делаете такие выводы? Если где-то что-то не срослось, то значит что запорчено всё, и блок данных, и сами суммы. Существуют специальные пары контрольных сумм, которые помогают узнать где примерно произошла порча при условии что может побиться не более заранее указанного числа бит. Такие методы обычно используются для коррекции медийных ошибок чтения/записи/передачи где можно построить вероятностную модель ошибки. И это, кстати, не CRC методы. А CRC в топике выше преследует иную цель - детектирование порчи данных по "техногенной" причине. Наример, вообще не тот сектор оказался где ожидается inode (такое, например, может быть если улетела карта отображений менеджера томов) или горе-админ решил что-то как-то пофиксить и сломал всё. Т.е. алгоритм анализа CRC совсем другой - если оно не совпрало, значит произошла порча и нельзя сказать как и где. Это просто сигнал для более детального анализа (человеком или эвристическими методами). А если CRC совпала то это не значит ничего, т.е. это не означает целостности данных и даже нельзя сказать с какой вероятностью они оказались валидными. Это всё сказано применительно к CRC метаданных в ФС. Кстати, там где-то ниже, или выше, разгорелся срач на эту тему и какой-то чувак всё упорно не видит различия между видами "контрольных сумм" (т.е. коррекция медийных ошибок с детерминированной моделью ошибки и защита от условно умышленной порчи где в принципе нельзя построить модель) и беды от которых они могут защитить.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	158. "а контрольные суммы для проверки целостности контрольных сумм?"	+/–
	Сообщение от Аноним (??) on 04-Июн-12, 01:58
	> Интересно, а поддержка вторых контрольных сумм для проверки целостности этих уже запланирована? Так, стоп, а кто будет проверять что вторые контрольные суммы - правильные? :)
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	172. "а контрольные суммы для проверки целостности контрольных сумм?"	+/–
	Сообщение от анон on 04-Июн-12, 03:07
	>> Интересно, а поддержка вторых контрольных сумм для проверки целостности этих уже запланирована? > Так, стоп, а кто будет проверять что вторые контрольные суммы - правильные? > :) Если уж прикалываться, и делать контрольную сумму на контрольную сумму, то предложу свой вариант. Заводить 2 контрольных суммы не надо, надо лишь записать ее копию как можно дальше от первой так, чтобы вероятность повреждения обоих была минимальной (это порядка 95 или 97% будет если мне память не изменяет). При несовпадении вновь рассчитанной суммы с первой копией она сверяется со второй. Если есть совпадение, то данные верны, а одна из копий - повреждена, что указывает скорее всего на баг в коде работы с ФС. Если контрольные суммы равны, и не сходятся с рассчитанной, то данные испорчены.
	Ответить | Правка | ^ к родителю #158 | Наверх | Cообщить модератору

	182. "а контрольные суммы для проверки целостности контрольных сумм?"	+1 +/–
	Сообщение от ыгчч on 04-Июн-12, 10:34
	Вы бы хоть почитали что-нибудь про CRC вместо того чтобы бред нести.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема