Реализация в Linux проверки целостности данных в блочных устройствах

13.06.2008 14:55

Мартин Петерсен (Martin K. Petersen) усовершенствовал в Linux ядре механизм ввода/вывода информации на SCSI устройства, который теперь позволяет добавлять к данным проверочную информацию (контрольные суммы и не только) на блочном уровне или уровне файловой системы и сохранять ее на физическом носителе.

В своем сообщении Martin объясняет: «Мета-информация может сохраняться в непосредственной близости от данных. Контроллеры дисков, RAID массивы и физические диски могут следить за целостностью записываемой или считываемой информации и прерывать операцию в случае ее нарушения.» В настоящее время такая поддержка реализована только для SCSI дисков, но идет работа над добавлением к списку SATA дисков и SCSI лент. С незначительными доработками, из-за ограничения протокола, формат SATA идентичен SCSI.

Работает это следующим образом: «SCSI диски обычно могут быть отформатированы с размером сектора 520 байт, что добавляет 8 дополнительных байт к каждому сектору. Традиционно эти байты использовались SCSI-контроллерами для хранения внутренней информации. DIF (поле целостности данных) — это расширение управляющих команд SCSI, стандартизирующее формат дополнительных 8 байт, и устанавливающее правила доступа к их содержимому на уровне протокола... При записи данных HBA считывает сектор, размером 512 байт, напрямую из памяти, рассчитывает контрольный блок метаданных и формирует 520-байтовый пакет. Диск осуществляет проверку целостности данных непосредственно перед их записью на магнитный носитель. При чтении диск отправляет 520-байтовый сектор контроллеру, который после осуществления проверки переписывает данные в память.»

исправить +/–

Главная ссылка к новости (http://kerneltrap.org/Linux/Bl...)

Автор новости: blkdog

Лицензия: CC BY 3.0

Короткая ссылка: https://opennet.ru/16467-linux

Ключевые слова: linux, kernel, disk, checksum

При перепечатке указание ссылки на opennet.ru обязательно

Обсуждение (8)

1.2, AsphyX (??), 02:43, 14/06/2008 [ответить]	+/–
Разве раньше контрольные суммы не проверялись?

1.3, belkin (ok), 20:07, 14/06/2008 [ответить]	+/–
Он бабу себе на выходные не нашёл, вот и решил себе занятие найти - добавить в помойку ещё какого-нибудь мусора. Это по-настоящему, по-пионерски. А контрольные суммы TCP он не хочет в заголовок кадра Ethernet запихивать? Если ему мало аппаратного контроля, который есть отдельно в SCSI и НЖМД, то есть программные RAID или такие комлексные решения как ZFS. Теперь Linux SCSI будет зависима от этих 520-512=8 байтов в сегодняшних дисках? А завтра? А в других устройствах хранения? Ах, да: появится ещё одна настройка в ядре: "костыль вкл./выкл.".

2.6, i_am (ok), 11:21, 17/06/2008 [^] [^^] [^^^] [ответить]	+/–
Да, ваш профессионализм так и прет.Поставить в один ряд ECC сектора с чексуммированием метаинформации ФС - сразу видно профи который разбирается в уровнях абстракции, слоях протоколов и прочая.В вашем случае - вы сказав что поскольку для файла можно передать хэш и после получения файла проверить утверждаете что чексуммы TCP для каждого пакета - это фигня и нафиг не нужны.Ведь разрушение файла можно обнаружить и по переданному хэшу!Правда вы не уточняете что делать в случае если хэш (ну или чексумм метаинформации в ФС) не сошелся.А так фигня, да.

3.7, belkin (ok), 16:51, 17/06/2008 [^] [^^] [^^^] [ответить]	+/–
>Да, ваш профессионализм так и прет.Поставить в один ряд ECC сектора с >чексуммированием метаинформации ФС - сразу видно профи который разбирается в уровнях >абстракции, слоях протоколов и прочая.В вашем случае - вы сказав что >поскольку для файла можно передать хэш и после получения файла проверить >утверждаете что чексуммы TCP для каждого пакета - это фигня и >нафиг не нужны.Ведь разрушение файла можно обнаружить и по переданному хэшу!Правда >вы не уточняете что делать в случае если хэш (ну или >чексумм метаинформации в ФС) не сошелся.А так фигня, да. Умник, пишите поростыми предложениями, если не можете оформить сложные. Пример с контролем TCP и Ethernet - это и есть мой сарказм по-поводу смешивания разных уровней управления.

1.4, гость (?), 14:14, 16/06/2008 [ответить]	+/–
Белкин, ты совсем дурак, да? Это стандартное расширение протокола - изменится протокол и сказёвые дрова придётся переделывать в любом случае. А "завтра" оно будет столь же прекрасно работать со всеми дисками, поддерживающими данную версию протокола. И безо всяких костылей вроде zfs.

2.8, belkin (ok), 16:53, 17/06/2008 [^] [^^] [^^^] [ответить]	+/–
>Белкин, ты совсем дурак, да? > >Это стандартное расширение протокола - изменится протокол и сказёвые дрова придётся переделывать >в любом случае. >А "завтра" оно будет столь же прекрасно работать со всеми дисками, поддерживающими >данную версию протокола. >И безо всяких костылей вроде zfs. В наше время только идиоты завязывают ОС на особенности реализаций SCSI. Свободней надо думать, смотреть в будущее и учится на чужих ошибках. Автору идеи нечем заняться.

1.5, i_am (ok), 11:18, 17/06/2008 [ответить]	+/–
Вообще-то в HDD всю жизнь сектора были более чем 512 байтов, как раз для ECC.И ECC там всегда есть.Только вот как правило все накопители сами считают ECC, чинят ошибки а то и принимают решение о переносе данных из нестабильного сектора в резервный.Не совсем понятно зачем это вообще выносить на уровень ос.Конечно программно считать ECC вместо того чтобы накопитель это делал аппаратно сам круто но вот НАФИГА БЫ???Процессор нечем занять?Если пытаться померяться с железом накопителя в исправлении ECC - особо смысла не вижу: ecc и сам накопитель посчитает, а трудные случаи все-равно к ошибке чтения приведут.В лучшем случае.Можно подумать что ECC можно рассчитать лучше чем сам накопитель.Ага, удачи.

2.9, belkin (ok), 16:56, 17/06/2008 [^] [^^] [^^^] [ответить]	+/–
>Вообще-то в HDD всю жизнь сектора были более чем 512 байтов, как >раз для ECC.И ECC там всегда есть.Только вот как правило все >накопители сами считают ECC, чинят ошибки а то и принимают решение >о переносе данных из нестабильного сектора в резервный.Не совсем понятно зачем >это вообще выносить на уровень ос.Конечно программно считать ECC вместо того >чтобы накопитель это делал аппаратно сам круто но вот НАФИГА БЫ???Процессор >нечем занять?Если пытаться померяться с железом накопителя в исправлении ECC - >особо смысла не вижу: ecc и сам накопитель посчитает, а трудные >случаи все-равно к ошибке чтения приведут.В лучшем случае.Можно подумать что ECC >можно рассчитать лучше чем сам накопитель.Ага, удачи. Умник я ровно об этом в первом сообщении и говорил. Т.е. несколькими постами выше ты сам себя ругал.

игнорирование участников | лог модерирования

Добавить комментарий

Текст: