The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

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

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

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

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

  1. Главная ссылка к новости (http://kerneltrap.org/Linux/Bl...)
Автор новости: blkdog
Тип: К сведению
Ключевые слова: linux, kernel, disk, checksum
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 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
    >можно рассчитать лучше чем сам накопитель.Ага, удачи.

    Умник я ровно об этом в первом сообщении и говорил. Т.е. несколькими постами выше ты сам себя ругал.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor