The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"OpenNews: Реализация в Linux проверки целостности данных в б..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"OpenNews: Реализация в Linux проверки целостности данных в б..."  
Сообщение от opennews (??) on 14-Июн-08, 00:45 
Мартин Петерсен (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

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

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


2. "Реализация в Linux проверки целостности данных в блочных уст..."  
Сообщение от AsphyX (??) on 14-Июн-08, 02:43 
Разве раньше контрольные суммы не проверялись?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Реализация в Linux проверки целостности данных в блочных уст..."  
Сообщение от belkin (ok) on 14-Июн-08, 20:07 
Он бабу себе на выходные не нашёл, вот и решил себе занятие найти - добавить в помойку ещё какого-нибудь мусора. Это по-настоящему, по-пионерски. А контрольные суммы TCP он не хочет в заголовок кадра Ethernet запихивать? Если ему мало аппаратного контроля, который есть отдельно в SCSI и НЖМД, то есть программные RAID или такие комлексные решения как ZFS.

Теперь Linux SCSI будет зависима от этих 520-512=8 байтов в сегодняшних дисках? А завтра? А в других устройствах хранения? Ах, да: появится ещё одна настройка в ядре: "костыль вкл./выкл.".

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Реализация в Linux проверки целостности данных в блочных уст..."  
Сообщение от i_am (ok) on 17-Июн-08, 11:21 
Да, ваш профессионализм так и прет.Поставить в один ряд ECC сектора с чексуммированием метаинформации ФС - сразу видно профи который разбирается в уровнях абстракции, слоях протоколов и прочая.В вашем случае - вы сказав что поскольку для файла можно передать хэш и после получения файла проверить утверждаете что чексуммы TCP для каждого пакета - это фигня и нафиг не нужны.Ведь разрушение файла можно обнаружить и по переданному хэшу!Правда вы не уточняете что делать в случае если хэш (ну или чексумм метаинформации в ФС) не сошелся.А так фигня, да.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Реализация в Linux проверки целостности данных в блочных уст..."  
Сообщение от belkin (ok) on 17-Июн-08, 16:51 
>Да, ваш профессионализм так и прет.Поставить в один ряд ECC сектора с
>чексуммированием метаинформации ФС - сразу видно профи который разбирается в уровнях
>абстракции, слоях протоколов и прочая.В вашем случае - вы сказав что
>поскольку для файла можно передать хэш и после получения файла проверить
>утверждаете что чексуммы TCP для каждого пакета - это фигня и
>нафиг не нужны.Ведь разрушение файла можно обнаружить и по переданному хэшу!Правда
>вы не уточняете что делать в случае если хэш (ну или
>чексумм метаинформации в ФС) не сошелся.А так фигня, да.

Умник, пишите поростыми предложениями, если не можете оформить сложные. Пример с контролем TCP и Ethernet - это и есть мой сарказм по-поводу смешивания разных уровней управления.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Реализация в Linux проверки целостности данных в блочных уст..."  
Сообщение от гость on 16-Июн-08, 14:14 
Белкин, ты совсем дурак, да?

Это стандартное расширение протокола - изменится протокол и сказёвые дрова придётся переделывать в любом случае.
А "завтра" оно будет столь же прекрасно работать со всеми дисками, поддерживающими данную версию протокола.
И безо всяких костылей вроде zfs.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Реализация в Linux проверки целостности данных в блочных уст..."  
Сообщение от belkin (ok) on 17-Июн-08, 16:53 
>Белкин, ты совсем дурак, да?
>
>Это стандартное расширение протокола - изменится протокол и сказёвые дрова придётся переделывать
>в любом случае.
>А "завтра" оно будет столь же прекрасно работать со всеми дисками, поддерживающими
>данную версию протокола.
>И безо всяких костылей вроде zfs.

В наше время только идиоты завязывают ОС на особенности реализаций SCSI. Свободней надо думать, смотреть в будущее и учится на чужих ошибках. Автору идеи нечем заняться.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Реализация в Linux проверки целостности данных в блочных уст..."  
Сообщение от i_am (ok) on 17-Июн-08, 11:18 
Вообще-то в HDD всю жизнь сектора были более чем 512 байтов, как раз для ECC.И ECC там всегда есть.Только вот как правило все накопители сами считают ECC, чинят ошибки а то и принимают решение о переносе данных из нестабильного сектора в резервный.Не совсем понятно зачем это вообще выносить на уровень ос.Конечно программно считать ECC вместо того чтобы накопитель это делал аппаратно сам круто но вот НАФИГА БЫ???Процессор нечем занять?Если пытаться померяться с железом накопителя в исправлении ECC - особо смысла не вижу: ecc и сам накопитель посчитает, а трудные случаи все-равно к ошибке чтения приведут.В лучшем случае.Можно подумать что ECC можно рассчитать лучше чем сам накопитель.Ага, удачи.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

9. "Реализация в Linux проверки целостности данных в блочных уст..."  
Сообщение от belkin (ok) on 17-Июн-08, 16:56 
>Вообще-то в HDD всю жизнь сектора были более чем 512 байтов, как
>раз для ECC.И ECC там всегда есть.Только вот как правило все
>накопители сами считают ECC, чинят ошибки а то и принимают решение
>о переносе данных из нестабильного сектора в резервный.Не совсем понятно зачем
>это вообще выносить на уровень ос.Конечно программно считать ECC вместо того
>чтобы накопитель это делал аппаратно сам круто но вот НАФИГА БЫ???Процессор
>нечем занять?Если пытаться померяться с железом накопителя в исправлении ECC -
>особо смысла не вижу: ecc и сам накопитель посчитает, а трудные
>случаи все-равно к ошибке чтения приведут.В лучшем случае.Можно подумать что ECC
>можно рассчитать лучше чем сам накопитель.Ага, удачи.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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