- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 24 Oct 2007 02:06:05
To : Lev Serebryakov
Subject : Re: Кто имеет пpактический опыт общения со Storage Area Network?
--------------------------------------------------------------------------------
>>> Lev Serebryakov wrote:
AK>> переписать raid5 с нуля нормально и зачем-то потратили усилия на
AK>> совершенно никому не нужный raid3.
LS> Мне нужный. Почему никому не нужный? Какие к нему вообще претензии, кроме
LS> ограничения на число дисков? Дык 5 дисков -- очень удобное число :)
LS> Зато read-before-write нету.
Если ты внимательно почитаешь описания видов RAID, то увидишь, что
отличие между R3 и R5 одно: для R3 диск, на котором размещаются
контрольные суммы (XOR прочих) - один и тот же, а для R5 он меняется
на каждой полосе. Это, в частности, значит, что "read-before-write
нету" или одновременно справедливо для обоих типов, или одновременно
несправедливо опять же для обоих типов.
У них обоих для обновления данных при записи - один и тот же выбор
из двух методов. Первый метод - при записи блока надо прочитать
данные всех других блоков данных в той же полосе, сделать XOR и
полученное записать в блок чётности. Это надёжнее против сбоев
данных. Другой метод - сделать XOR нового и старого содержимого
блока данных, который записывается, а также старого содержимого
блока чётности - и результат записать в блок чётности. Hо в любом
случае у тебя будут минимум две записи (блок данных и блок чётности)
и два чтения, но по первому методу чтений может быть и больше.
Претензий же две. Первая - к R3 вообще, почему и был придуман R5 -
диск чётности протирается и изнашивается в два раза быстрее
остальных, в случае произвольных операций записи (и как минимум с
такой же скоростью - при потоковых операциях записи без требования
немедленного подтверждения). Вторая - к конкретной реализации -
странная двоичная иерархия количества дисков - видно, что автор
хотел сэкономить собственные усилия. Видимо, это ему удалось успешно
- чего нельзя сказать про экономию затрат остальных.
-netch-
--- ifmail v.2.15dev5.4
* Origin: Darkside of coredump (2:5020/400)
