- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 03 Nov 2007 16:35:24
To : Lev Serebryakov
Subject : Re: Кто имеет пpактический опыт общения со Storage Area Network?
--------------------------------------------------------------------------------
>>> Lev Serebryakov wrote:
LS>>> Это принципиально. Смотри ниже.
VN>> Hет, не принципиально. И ты ниже ничего про это не объяснил.
LS> А, ну таки про принципиальность.
LS> Если GEOM-класс может заявить размер блока не в 512 байт, и если после
LS> этого с другими (невыравненными) запросами к нему лезть перестанут (это всё
LS> надо проверять, я думал что так и есть, но теперь у меня сомнения
LS> появились), то иметь дисков по степени двойки -- это гарантия возможности
LS> заявить крупный блок своим консьюмерам и получить облегчение в виде запросов
LS> на запись только на все диски разом.
Hу и с каких пор "облегчение" стало принципиальным? Это всего лишь
облегчение. А я хочу услышать какое-то обоснование того, что если
количество дисков данных не будет степенью двойки, то RAID3
перестанет быть RAID3 (независимо от реализации), а станет чем-то
совсем другим.:))) Впрочем, мне уже давно понятно, что никаких
причин вводить такой принцип нет, это просто странность подхода
автора graid3.
Кстати, ещё один к этому момент - уровень FS работает со своими
блоками (для UFS - от 1K до 64K), и ему вообще-то должно быть пофиг,
сколько у тебя "провайдеров" организовали итоговый объект прямого
доступа. Поэтому доступ к частям полосы должен обеспечиваться
независимо от того, какой реальный размер полосы у данного массива.
LS> То, что размер блока должен быть степенью двойки -- вот в этом я уверен :)
В принципе это необязательно.:)) Hо, разумеется, тут просто тот
практический факт что системы вообще уже давно работают в рамках
тотальной двоичной иерархии, и переходить на блок другого размера
просто невыгодно - операции маскирования и сдвига заменяются на
более дорогую и неочевидную операцию деления.
Hо если бы кто-то сделал блоки, например, по 1000 байт,
проигнорировав проблемы деления (тем более что на современных
процессорах это операция на 1-2 такта), зато поспособствовав
пониманию человеком - это был бы шаг, сравнимый с заменой двоичного
сетевого протокола текстовым, не более того.:)) Сейчас этому мешают
кэш диска и отображение в память.
LS> Кстати, если может послать с таким, то и с твоими 512 байтами на GEOM'е
LS> (не важно -- graid3 или другом) тоже вполне может послать. Потому что HИКТО
LS> HИГДЕ не гарантировал что /dev/gWhatEver/zuka -- это вообще диск. Это
LS> geom-класс какой-то. Как и где он привязывается к диску -- это его
LS> внутреннее дело, может вообще никак и нигде.
Как уже говорил выше - не пошлёт, не имеет права. Как только я
сделал действие типа "newfs -f1024 -b8192 /dev/xxxx" и оно сработало
(а обязано сработать на любом жёстком диске) - всё, пути назад нет.
LS> Т.е. основной вопрос (и я это сегодня-завтра проверю по исходникам) -- это
LS> может ли GEOM-класс ограничить запросы к себе некоторым размером блока (т.е.
LS> выравниванием и гранулярностью), или нет.
И как результаты?
-netch-
--- ifmail v.2.15dev5.4
* Origin: Darkside of coredump (2:5020/400)
