Мартин Петерсен (Martin K. Petersen) усовершенствовал (http://kerneltrap.org/Linux/Block_Data_Integrity) в Linux ядре механизм ввода/вывода информации на SCSI устройства, который теперь позволяет добавлять к данным проверочную информацию (контрольные суммы и не только) на блочном уровне или уровне файловой системы и сохранять ее на физическом носителе.В своем сообщении Martin объясняет:<i> «Мета-информация может сохраняться в непосредственной близости от данных. Контроллеры дисков, RAID массивы и физические диски могут следить за целостностью записываемой или считываемой информации и прерывать операцию в случае ее нарушения.»</i> В настоящее время такая поддержка реализована только для SCSI дисков, но идет работа над добавлением к списку SATA дисков и SCSI лент. <i>С незначительными доработками, из-за ограничения протокола, формат SATA идентичен SCSI</i>.
Работает это следующим образом:<i> «SCSI диски обычно могут быть отформатированы с размером сектора 520 байт, ...URL: http://kerneltrap.org/Linux/Block_Data_Integrity
Новость: http://www.opennet.me/opennews/art.shtml?num=16467
Разве раньше контрольные суммы не проверялись?
Он бабу себе на выходные не нашёл, вот и решил себе занятие найти - добавить в помойку ещё какого-нибудь мусора. Это по-настоящему, по-пионерски. А контрольные суммы TCP он не хочет в заголовок кадра Ethernet запихивать? Если ему мало аппаратного контроля, который есть отдельно в SCSI и НЖМД, то есть программные RAID или такие комлексные решения как ZFS.Теперь Linux SCSI будет зависима от этих 520-512=8 байтов в сегодняшних дисках? А завтра? А в других устройствах хранения? Ах, да: появится ещё одна настройка в ядре: "костыль вкл./выкл.".
Да, ваш профессионализм так и прет.Поставить в один ряд ECC сектора с чексуммированием метаинформации ФС - сразу видно профи который разбирается в уровнях абстракции, слоях протоколов и прочая.В вашем случае - вы сказав что поскольку для файла можно передать хэш и после получения файла проверить утверждаете что чексуммы TCP для каждого пакета - это фигня и нафиг не нужны.Ведь разрушение файла можно обнаружить и по переданному хэшу!Правда вы не уточняете что делать в случае если хэш (ну или чексумм метаинформации в ФС) не сошелся.А так фигня, да.
>Да, ваш профессионализм так и прет.Поставить в один ряд ECC сектора с
>чексуммированием метаинформации ФС - сразу видно профи который разбирается в уровнях
>абстракции, слоях протоколов и прочая.В вашем случае - вы сказав что
>поскольку для файла можно передать хэш и после получения файла проверить
>утверждаете что чексуммы TCP для каждого пакета - это фигня и
>нафиг не нужны.Ведь разрушение файла можно обнаружить и по переданному хэшу!Правда
>вы не уточняете что делать в случае если хэш (ну или
>чексумм метаинформации в ФС) не сошелся.А так фигня, да.Умник, пишите поростыми предложениями, если не можете оформить сложные. Пример с контролем TCP и Ethernet - это и есть мой сарказм по-поводу смешивания разных уровней управления.
Белкин, ты совсем дурак, да?Это стандартное расширение протокола - изменится протокол и сказёвые дрова придётся переделывать в любом случае.
А "завтра" оно будет столь же прекрасно работать со всеми дисками, поддерживающими данную версию протокола.
И безо всяких костылей вроде zfs.
>Белкин, ты совсем дурак, да?
>
>Это стандартное расширение протокола - изменится протокол и сказёвые дрова придётся переделывать
>в любом случае.
>А "завтра" оно будет столь же прекрасно работать со всеми дисками, поддерживающими
>данную версию протокола.
>И безо всяких костылей вроде zfs.В наше время только идиоты завязывают ОС на особенности реализаций SCSI. Свободней надо думать, смотреть в будущее и учится на чужих ошибках. Автору идеи нечем заняться.
Вообще-то в HDD всю жизнь сектора были более чем 512 байтов, как раз для ECC.И ECC там всегда есть.Только вот как правило все накопители сами считают ECC, чинят ошибки а то и принимают решение о переносе данных из нестабильного сектора в резервный.Не совсем понятно зачем это вообще выносить на уровень ос.Конечно программно считать ECC вместо того чтобы накопитель это делал аппаратно сам круто но вот НАФИГА БЫ???Процессор нечем занять?Если пытаться померяться с железом накопителя в исправлении ECC - особо смысла не вижу: ecc и сам накопитель посчитает, а трудные случаи все-равно к ошибке чтения приведут.В лучшем случае.Можно подумать что ECC можно рассчитать лучше чем сам накопитель.Ага, удачи.
>Вообще-то в HDD всю жизнь сектора были более чем 512 байтов, как
>раз для ECC.И ECC там всегда есть.Только вот как правило все
>накопители сами считают ECC, чинят ошибки а то и принимают решение
>о переносе данных из нестабильного сектора в резервный.Не совсем понятно зачем
>это вообще выносить на уровень ос.Конечно программно считать ECC вместо того
>чтобы накопитель это делал аппаратно сам круто но вот НАФИГА БЫ???Процессор
>нечем занять?Если пытаться померяться с железом накопителя в исправлении ECC -
>особо смысла не вижу: ecc и сам накопитель посчитает, а трудные
>случаи все-равно к ошибке чтения приведут.В лучшем случае.Можно подумать что ECC
>можно рассчитать лучше чем сам накопитель.Ага, удачи.Умник я ровно об этом в первом сообщении и говорил. Т.е. несколькими постами выше ты сам себя ругал.