На самом деле правило простое -- для создания такого раздела не надо использовать разбивалку, встроенную в анаконду (RHEL5), а создать раздел стандартными cfdisk/mkfs.ext3. В установщике этой супер-пупер-энтерпрайс системы кто-то докагадался под размер отвести переменную типа float со всеми вытекающими :) Про другие дистрибутивы не в курсе.
>Чтобы пользоваться GPT,необходимо включить ее поддержку в ядре; если этого не сделать, то при перезагрузке сервера либо файловая система окажется немонтируемой, либо GPT таблица окажется поврежденной.
Прелестно... А я-то думал, чего народ валом к нам валит с закоррапчеными партишн-тейблами. И у всех вольюмы такие здоровые-прездоровые :)
Прийди ко мне скатинка! Я тебе покажу /dev/sdg объемом 5 Тб.
Откуда? А ты на мир посмотри. По-гугли что такое SAN, NAS, DAS. Тогда ты наверно поймешь что-то своим тупым умишком!
Автору пять. Толково и доходчиво.
Типа на фига мне 5 Тб? Бакапы там у меня. Типа стриммер лучше? А вы с него данные восстанавливать пробовали? Если нет, то засуньте сами знаете что, сами знаете куда.
Половые проблемы и нарушения логических цепей отдельным анонимных личностей мало волнуют комьюнити, как только представишь _диск_ размером >1.0x(2^32) байт, тогда и честный тройбан в зачётку поставим.
Ай-яй-яй, а самое главное-то забыли. Новые разделы - хорошо, а со старыми что делать?
Я пару недель назад решал куда более сложную задачу: есть 5 рейд из 5 дисков 400 гб -> 2 тб данных (на одном разделе на весь диск). Нужно увеличить емкость. В свое время увеличение с 4 до 5 дисков и с 1.5 тб до 2 тб прошло прекрасно, благо рейд-контроллер аппаратный и все это отлично поддерживает, причем в онлайне. Ну добавил 6 диск, расширил общее пространство до 2.5 тб - все отлично (если не считать того, что под непрерывной загрузкой он безумно медленно расширение делал, почти сутки заняло - без нагрузки часика за 4 справляется..). А раздел-то дальше 2 тб не увеличивается, dos partition table, знаете ли! Погуглил, узнал про gpt. Превосходно. Но эээ.. gpt предлагается ставить на ЧИСТЫЙ диск! mbr и его разделы оно сносит. А у меня там данные, вообще-то. И сбэкапить такой объем совершенно некуда (а два терабайта почти под завязку были забиты). Узнал что во фре, вроде есть создавалка gpt, которая может создать гибридный gpt+mbr, или просто gtp так, чтобы старый раздел сохранился. Но линукс - не фря, портировать подобную утилиту желания нет, а parted ничего подобного не умеет.
Свою задачу я, конечно, решил. hex-редактором, калькулятором и докой по mbr и gpt сделал так, что никто ничего и не заметил - а у меня уже gpt тем временем. И расширился он прекрасно, вот так:
$ df /mnt/media/
Файловая система 1K-блоков Исп Доступно Исп% смонтирована на
/dev/sdb1 2441298552 2076759876 364538676 86% /mnt/media
Конечно же, там не ext3.
$ mount|grep media
/dev/sdb1 on /mnt/media type jfs (rw,noatime)
А мораль сей басни - делайте gpt ПРЯМО СЕЙЧАС, господа! Пока не поздно. Никакого смысла держаться за морально устаревший mbr нынче нет, разве что некоторые ОС не могут загружаться с диска с gpt. gpt держит и современная винда, а в dragonfly собираются переходить на него по дефолту. Будьте на острие прогресса, и вам не будет очень больно в тот момент, когда без gpt дальше будет просто никак. mbr уже отжил свое...
>Я пару недель назад решал куда более сложную задачу: есть 5 рейд из 5 дисков 400 гб -> 2 тб данных (на одном разделе на весь диск). Нужно увеличить емкость. В свое время увеличение с 4 до 5 дисков и с 1.5 тб до 2 тб прошло прекрасно, благо рейд-контроллер аппаратный и все это отлично поддерживает, причем в онлайне. Ну добавил 6 диск, расширил общее пространство до 2.5 тб - все отлично (если не считать того, что под непрерывной загрузкой он безумно медленно расширение делал, почти сутки заняло - без нагрузки часика за 4 справляется..). А раздел-то дальше 2 тб не увеличивается, dos partition table, знаете ли! Погуглил, узнал про gpt. Превосходно. Но эээ.. gpt предлагается ставить на ЧИСТЫЙ диск! mbr и его разделы оно сносит. А у меня там данные, вообще-то. И сбэкапить такой объем совершенно некуда (а два терабайта почти под завязку были забиты). Узнал что во фре, вроде есть создавалка gpt, которая может создать гибридный gpt+mbr, или просто gtp так, чтобы старый раздел сохранился. Но линукс - не фря, портировать подобную утилиту желания нет, а parted ничего подобного не умеет.
Похоже что проблема переросла в глобальную! Народ не может осилить документацию по RAID контроллерам (SAN и т.п.) и ищет приключения на свою задницу. Не может сообразить, что с нормальными устройствами не нужны ни разделы, ни LVM, ни чего подобного (за исключением 1-го диска размером в 500МБ с разделом /boot для загрузки), а все эти функции разбиения надо выполнять с помощью программного обеспечения контроллеров, и под задачу создавать не раздел, а сразу диск, и файловую систему делать на чистых дисках без таблицы разделов.
Во-первых, множество SANов для системы видно как один монолитный диск. А как оно там внутри устроено - личное дело аппаратного контроллера.
Во-вторых, просто неудобно работать с кучей ФИЗИЧЕСКИХ устройств. Намного удобнее логические устройства типа LVM2, с которыми можно сделать и snapshot и их геометрию при необходимости поменять можно.
> И сбэкапить такой объем совершенно некуда
В смысле? Вы не бэкапитесь? На продакшене?
Ну тогда эти 2 Тб данных можно было просто стереть. Потому как ценности не представляют.
>А мораль сей басни - делайте gpt ПРЯМО СЕЙЧАС, господа!
Ну уж нет. Райзерфсу накушались.... Годков эдак через пяток посмотрим что из этого GPT выйдет.
>Во-первых, множество SANов для системы видно как один монолитный диск. А как оно там внутри устроено - личное дело аппаратного контроллера.
Признайтесь, вы не видели ни одного SAN. И для системы он может показать как один логический диск, так и 10 - как настроишь.
>Во-вторых, просто неудобно работать с кучей ФИЗИЧЕСКИХ устройств. Намного удобнее логические устройства типа LVM2, с которыми можно сделать и snapshot и их геометрию при необходимости поменять можно.
На мой взгляд нет разницы с чем иметь дело: с диском под названием /dev/sda или /dev/storage/root. А RAID контроллеры позволяют менять и размеры логических дисков, и снапшоты делать, и write barriers поддерживают, в отличии от LVM.
>Ты про перемотку ленты? Ну в принципе я к этому морально готов. Из рассчета что восстановить надо часа за 4.
Ага, особенно плохо, если нужно несколько файлов восстановить, да еще и с инкрементальными бэкапами. Прямо вспоминаю детство с кассетным Спектрумом. Ну и в случае физического повреждения ленточки все еще дольше.
Кроме того, ленточки еще руками ставить надо в стример :) А с SAN для бэкапа все уже и так работает, даже если я в этот момент дома.
Ну и по цене - нормальные стримеры стоят около $5000, на эти деньги, AFAIR, можно купить что-то около 5Tb дискового хранилища.
В переменной указывается размер в мегабайтах? Сколько мегабайтов можно представить в float?
А разбиение идет через parted (см. PartedUtils.py)
Корень зла наверно здесь
def getDefaultDiskType():
"""Get the default partition table type for this architecture."""
if rhpl.getArch() == "i386":
return parted.disk_type_get("msdos")
elif rhpl.getArch() == "ia64":
return parted.disk_type_get("gpt")
Именно поэтому я и говорю стриммерам "ФИ", при всех их достоинствах.
Приличный стриммер с роботом стоит примерно столько же, сколько и дисковое хранилище. Кассета строит дороже диска идентичной емкости и в отличие от винчестера на любом углу не продается. кассету надо, заказывать, то, сё... Винт SATA продается в любом компьютерном киоске. :)
Да дисковый массив жрет больше эл-ва. Да, винты как кассету легко не унесешь в кармане. Но в при начальном условии "восстановление за минимальное время" стриммеры не годятся совсем. Только если нужно долговременное хранение.
Кто хранит данные фиг знает сколько и изредка их восстанавливает, тому стриммеры пожалуй подойдут. Но для бакапа боевых серверов и баз данных я бы не рекомендовал стриммер. Восстанавливаться будет ОЧЕНЬ долго. Проверено многократно. Отчасти поэтому планируем купить в след.году массив на 20 Тб.
> В смысле? Вы не бэкапитесь? На продакшене? Ну тогда эти 2 Тб данных можно было просто стереть. Потому как ценности не представляют.
Да какой там продакшен ;) Это мой домашний NAS-сервер с большим мультимедийным архивом. Просто когда он вырос дальше какого-то объема, бэкапиться стало совершенно нереально, да и глупо большую часть данных там бэкапить, а потерять все - больно, поэтому сделал raid 5, а бэкаплю только систему. Много сил, кстати, положил в него, пока получил максимально возможную на одной гигабите производительность по nfs, в итоге добился своего: 120 мегабайт/с чтение, 95 мегабайт/с запись (дальше уже нужно две карты связывать, но с учетом того, как я к этим значениям шел, оно в два раза быстрее точно не будет, даже в полтора вряд ли).
> Годков эдак через пяток посмотрим что из этого GPT выйдет.
По-моему он уже не меньше пятка лет существует ;) С итаниумами появился.
Гы. Выпей водки, полегчает
Контроллер ничего не знает про reiser,ext4,xfs Его задача ето по сути lvm и может он только 2 вещи объеденить в райд или lvm. Т.е. объеденить диск так, что ты увидешь один монолитный /dev/sda объемом 2ТБ. А вот дальше ты должен придать ему логическую структуру в виде файловой системы, так вот стандартным fdisk'ом просто нельзя получить раздел больше двух теров ну не будет у тебя sda1 > 2 ТБ, на который ты в последствии поставишь ext,reiser,jfs,xfs,ntfs, и чего ты тогда делать будешь? Ты будешь делать то, что делал товарищь в посте.
>Гы. Выпей водки, полегчает Контроллер ничего не знает про reiser,ext4,xfs Его задача ето по сути lvm и может он только 2 вещи объеденить в райд или lvm. Т.е. объеденить диск так, что ты увидешь один монолитный /dev/sda объемом 2ТБ. А вот дальше ты должен придать ему логическую структуру в виде файловой системы, так вот стандартным fdisk'ом просто нельзя получить раздел больше двух теров ну не будет у тебя sda1 > 2 ТБ, на который ты в последствии поставишь ext,reiser,jfs,xfs,ntfs, и чего ты тогда делать будешь? Ты будешь делать то, что делал товарищь в посте.
Консолидация накопления данных и серверов позволяет сэкономить
Vtrak M210p/M310p/M500p обладает возможностями кластерной поддержки, такими, как улучшенные отображение и маскировка LUN. Благодаря поддержке до 256 логических дисков (LUNs) на массив и 32 LUNs на физический диск, M210p/M310p/M500p предоставляет надежную, универсальную платформу для консолидации накопления данных и серверов, что позволяет уменьшить совокупную стоимость хранения. Через разделение источников накопления данных между несколькими серверами, пользователи смогут воспользоваться преимуществами доступных конфигураций и экономичных решений накопления данных и максимально использовать доступную ёмкость.