Comments 7
Какая все-таки крутая была технология.
А вычисление хэш функций для файлов добавили в рэйд? Помню мне очень понравилась эта идея, когда массив сам мог отслеживать целостность информации, сохраненной на жестких дисках, с учетом возможных ошибок чтения, и в случае чего дублировать файл в другое место диска.
А рейд — я ему перестал доверять, после того, как на обычном зеркале вся информация превратилась в кашу после ребилда. При этом ребилд был вызван не аппаратным сбоем дисков — а перезагрузкой винды из-за ошибки.
А вычисление хэш функций для файлов добавили в рэйд? Помню мне очень понравилась эта идея, когда массив сам мог отслеживать целостность информации, сохраненной на жестких дисках, с учетом возможных ошибок чтения, и в случае чего дублировать файл в другое место диска.
В смысле — добавили? Scrub есть в ZFS с чёрт-те какого года.
При этом ребилд был вызван не аппаратным сбоем дисков — а перезагрузкой винды из-за ошибки.
А у вас под виндой был ZFS?
У mdraid есть проблемы с консистентностью записи при креше (т.н. write hole), а кроме того, он НИКАК (ну вообще никак) не следит за корректностью данных. Например, если есть ZFSный raidz1, то ему можно нагадить /dev/urandom
'ом в один из дисков (или в разные диски, но без перекрытия), и он всё прекрасно определит при чтении (и выдаст корректную инфу) и восстановит — при scrub'е. А если такое сделать mdraid'у — он ничего не определит даже. Несмотря на то, что теоретическая возможность определить порчу (но не восстановить) есть для raid5 и ещё и восстановить порчу данных на одном блоке страйпа — в raid6. Никакие 'check' порчу не увидят и никакие 'repair' (для raid6) не починят, последний просто запорет данные окончательно.
Да сталкивался с таким в mdraid
Контора не следила за SMART (точнее игнорила предупреждения и некому было заменить диск и не на что заменить), один диск забедился и mdraid его не выплюнул как должно было и все вирты на этом рейде превратились в кашу
В RAIDz появится расширение массива добавлением дисков