forum.opennet.ru - "OpenNews: Реализация в Linux проверки целостности данных в б..." (8)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"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.ru/opennews/art.shtml?num=16467
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Реализация в Linux проверки целостности данных в блочных уст..., AsphyX, 02:43 , 14-Июн-08, (2)
Реализация в Linux проверки целостности данных в блочных уст..., belkin, 20:07 , 14-Июн-08, (3)

Реализация в Linux проверки целостности данных в блочных уст..., i_am, 11:21 , 17-Июн-08, (6)

Реализация в Linux проверки целостности данных в блочных уст..., belkin, 16:51 , 17-Июн-08, (7)

Реализация в Linux проверки целостности данных в блочных уст..., гость, 14:14 , 16-Июн-08, (4)

Реализация в Linux проверки целостности данных в блочных уст..., belkin, 16:53 , 17-Июн-08, (8)

Реализация в Linux проверки целостности данных в блочных уст..., i_am, 11:18 , 17-Июн-08, (5)

Реализация в Linux проверки целостности данных в блочных уст..., belkin, 16:56 , 17-Июн-08, (9)

Сообщения по теме [Сортировка по ответам | 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ообщить модератору

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

Сообщение от гость on 16-Июн-08, 14:14

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

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

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

Сообщение от i_am (ok) on 17-Июн-08, 11:18

Вообще-то в HDD всю жизнь сектора были более чем 512 байтов, как раз для ECC.И ECC там всегда есть.Только вот как правило все накопители сами считают ECC, чинят ошибки а то и принимают решение о переносе данных из нестабильного сектора в резервный.Не совсем понятно зачем это вообще выносить на уровень ос.Конечно программно считать ECC вместо того чтобы накопитель это делал аппаратно сам круто но вот НАФИГА БЫ???Процессор нечем занять?Если пытаться померяться с железом накопителя в исправлении ECC - особо смысла не вижу: ecc и сам накопитель посчитает, а трудные случаи все-равно к ошибке чтения приведут.В лучшем случае.Можно подумать что ECC можно рассчитать лучше чем сам накопитель.Ага, удачи.

Высказать мнение | Ответить | Правка | ^ | Наверх | 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ообщить модератору

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

Сообщение от belkin (ok) on 17-Июн-08, 16:53

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

Высказать мнение | Ответить | Правка | ^ | Наверх | 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]

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру


	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ообщить модератору


	4. "Реализация в Linux проверки целостности данных в блочных уст..."
	Сообщение от гость on 16-Июн-08, 14:14
	Белкин, ты совсем дурак, да? Это стандартное расширение протокола - изменится протокол и сказёвые дрова придётся переделывать в любом случае. А "завтра" оно будет столь же прекрасно работать со всеми дисками, поддерживающими данную версию протокола. И безо всяких костылей вроде zfs.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


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


	8. "Реализация в Linux проверки целостности данных в блочных уст..."
	Сообщение от belkin (ok) on 17-Июн-08, 16:53
	>Белкин, ты совсем дурак, да? > >Это стандартное расширение протокола - изменится протокол и сказёвые дрова придётся переделывать >в любом случае. >А "завтра" оно будет столь же прекрасно работать со всеми дисками, поддерживающими >данную версию протокола. >И безо всяких костылей вроде zfs. В наше время только идиоты завязывают ОС на особенности реализаций SCSI. Свободней надо думать, смотреть в будущее и учится на чужих ошибках. Автору идеи нечем заняться.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| 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]