В чем разница между “свойством” и “недостатком”
В некоем оффлайновом споре, развернувшемся по поводу недавно опубликованной мной заметки по поводу того, как организовано использование дисковой емкости на системах хранения NetApp, я столкнулся с непониманием того, что было мной названо “не недостатком, а свойством”, и в чем между ними в данном случае принципиальная разница.
Вынося это обсуждение из того спора, я хочу отдельно пояснить свою позицию по этому вопросу.
Например, когда мы решаем использовать для хранения наших данных RAID-5, емкость которого равна сумме всех входящих в него дисков, минус емкость одного диска, или даже RAID-10, емкость которого равна половине суммы всех емкостей его дисков, мы не говорим, что “всем был бы хорош RAID-5, вот только главный недостаток его в том, что емкость его на целый диск меньше, чем могла бы быть”.
Мы знаем, что “по другому быть не могло”.
Мы знаем, что уменьшение емкости на один диск (или даже на половину всех дисков в случае RAID-10), это не недостаток, а естественно присущее такому типу RAID свойство. Мы знаем, что взамен мы получаем более высокую устойчивость системы, более высокую, чем в случае простого набора дисков, а также большее быстродействие. За все этомы платим емкостью одного диска (или двумя для RAID-6, или половиной для RAID-10), что-ж, за все надо платить. Если нам нужна надежность, мы выбираем RAID и платим.
Но никто не трактует уменьшение емкости при создании RAID как “недостаток” RAID. Никто не ставит это в вину RAID, так как совершенно очевидно, что это свойство RAID, за счет этого он работает и обеспечивает свои дополнительные пользовательские преимущества, такие как быстродействие и повышенная, в сравнении с отдельным диском, или группой таких дисков, надежность, ради чего мы его и применяем.
Абсолютно точно также обстоит дело с Block Checksums в NetApp. Также как диск parity в RAID-5 это повышает надежность и добавляет функциональность (например позволяет дедуплицировать данные или использовать Oracle HARD), за счет некоторого уменьшения полезного объема. Это тоже не недостаток примененной NetApp модели использования дисков, это его свойство.
Роман, мне кажется сейчас ты занимаешься софистикой.
В случае с 512/520 байт в отличии от RAID5/3/4 - “по-другому быть могло” - но архитектура WAFL заточена именно так (я кстати не говорю что это плохое решение - вполне себе архитектурное решение)
одное решение в комментариях было
….. цитирую комментарии …..
ой 8-(( - погрызло весь мой большой коммент - попробую написать в мелких
> Роман, мне кажется сейчас ты занимаешься софистикой.
>В случае с 512/520 байт в отличии от RAID5/3/4 - “по-другому быть могло” - но архитектура WAFL заточена именно так
А RAID - “заточен по другому”, но суть та же. За функциональность надо чем-то платить. В обоих вышеупомянутых случаях платим raw-местом.
В чем софистика?
Прочитай свой же комментарий от 25 сентября 2010, 18:21 в посте http://blog.aboutnetapp.ru/archives/708
ты ссылаешься на архитектурные решения. Вторым вариантом например можно записывать 8-байт сразу в следующий сектор и выполнять ремаппинг аппаратно на переходниках SATA/FC или SATA/SAS. Все равно ведь читать/писать два сектора вместо одного пусть будут соседние.
А то вдруг у кого-либо из вендоров окажется что есть 52-байтные сектора на SATA дисках и емкость будет больше чем у NetApp?
Софистика в том, что RAID5 “по-другому” сделать не получится - это RAID5 8-)
А защиту чексуммой сделать можно и потери ~ 10% можно избежать - вопрос “цены”
> Софистика в том, что RAID5 “по-другому” сделать не получится - это RAID5 8-)
По моему у вас какая-то неконвенциональная трактовка понятия “софизм”. Ссылку на словарь приводить уж не буду, да?
> А защиту чексуммой сделать можно и потери ~ 10% можно избежать - вопрос “цены”
Как и в случае RAID, кстати. “?? чо?”
8-)
Софизм - ложное умозаключение, которое, тем не менее, при поверхностном рассмотрении кажется правильным.
Я говорю что твое утверждение -
{
Эффект “отбрасывания” каждого девятого сектора это будет для числа секторов коэффициент 0,88 “в периоде”.
Умножим паспортное количество секторов на 0,88… и получим:
}
Можно обойтись меньшими накладными расходами, примеры тебе привели - dixi. В RAID5 ты всегда “потеряешь” емкость одного диска - по-другому сделать нельзя - это будет не RAID5 8-)))
> Можно обойтись меньшими накладными расходами, примеры тебе привели
Там же я ответил, почему такой вариант не подходит. Это очень усложнит работу, ограничит функциональность, и ухудшит производительность.
> В RAID5 ты всегда “потеряешь” емкость одного диска - по-другому сделать нельзя - это будет не RAID5
Ну да, все верно, а тут - будет не NetApp. Полная аналогия.
Рассуждения же “а можно было бы сделать по другому, и тогда”, это все умствования и “разговоры в пользу бедных”. Что рассуждать, давайте реализацию, обсудим, посмотрим, и решим, лучше ли она и чем.
Тебе уже привели две реализации - обе видимо плохо ложатся на архитектуру WAFL.
1) Один сектор с чексуммами на каждые 64 блока
2) Писать последовательно 520 байт
для упрощения - возможно отказаться от интерфейса SATA у “канистры” с диском и использовать SAS/FC, всю трансляцию делать прозрачно для операционки - т.е. всегда отдавать 520-ый сектор. Что вызовет повышение стоимости ээ диска в системе например 8-) - варианты есть.
Конечно есть. ??спользовать SAS или FC-диски, например :) Там сектор может быть произвольного размера на самом диске.
Я бы с удовольствием бы выслушал “примеры реализации”, но не от “комментаторов в блогах”, так как это все голимое “пикейножилетничество”.
Если другая реализация была бы возможна, то она бы появилась, не у NetApp, так у кого-то еще. Вот когда появится - приходите, поговорим, обсудим, а пока это все толчение в ступе.
Роман, вторая реализация, насколько мне известно, применяется в EMC-ых системах хранения.
Алексей,
во первых, как я знаю, там не все так однозначно, как, по видимому, представляется тебе.
Во вторых я бы просил, несмотря на наше давнее знакомство, все же “придерживаться”, и если тебе хочется обсуждать детали технической реализации 520-байтового блока, то делать это в комментариях к соответствующему посту, а не “к последнему, неважно на какую он тему”, а здесь - комментировать только подятую топиком тему.
Для соблюдения порядка я постараюсь большую часть дискуссии сегодня перенести в комментарии к соответствующему посту, а здесь останется только то, что относится к данной теме.