@LRC25 окт 2011 в 13:56

Ставим Gentoo x64 + xen на диски размером 3Tb в Hetzner

4 мин

9.6K

Системное администрирование *

Из песочницы

+31

Комментарии 33

@alexander007 25 окт 2011 в 14:26

А blktap2 не пробовали?

@LRC 25 окт 2011 в 14:35

LVM по любому быстрее будет, нет лишней прослойки в виде файловой системы. Образ подключенный по blktap2 по любому будет лежать, на какой ФС, может иметь фрагменты и т.д., сама работа с ФС дает накладные расходы
Плюс LVM том, можно достаточно быстро и безболезненно превратить в drbd устройство, и уже виртуалка становиться облачной. Даже думаю об этом статью написать

@alexander007 25 окт 2011 в 14:52

Относительно скорости есть тонкий момент. В режиме PV Xen выполняет буферизацию. И при кратковременных всплесках операций чтения/записи я получал скорость которая превышала скорость физического носителя в 2-3 раза.

@LRC 25 окт 2011 в 15:08

Вот это каюсь не знал, я его последний раз пробовал пол года назад, его тогда активно допиливали, и он глючил безбожно, остался осадок, плюс я предпочитаю сразу все убирать на drbd, я как то прикипел к lvm

@citius 25 окт 2011 в 14:54

>Даже думаю об этом статью написать

Напишите, очень интересен такой опыт.

@alexander007 25 окт 2011 в 14:58

В принципе уже можете почитать Xen поверх DRBD

@LRC 25 окт 2011 в 15:03

Да, на Xgu есть не плохая статья, там только не освещено, как LVM тома с данными безопасно превращать в drbd, пока не написал статью, надо метаданные drbd хранить на отдельном lvm томе

@alexander007 25 окт 2011 в 15:12

К стати, для облачности/кластеризации что лучше использовать? LVM+drbd, iscsi или NFS?

@LRC 25 окт 2011 в 15:19

NFS вообще слабо представляю как применять, если виртуалка не Linux-like, а между iscsi и drbd есть свои плюсы и минусы, у iscsi ваша точка отказа перемещается в хранилище, которое каким бы оно брендовым не было, может умереть, drbd позволяет не иметь такого хранилища, и убрать последнюю «точку отказа».

@Sov1et 25 окт 2011 в 20:43

И добавить геморой с DRBD. Имхо лучше хорошая железка.

@icCE 26 окт 2011 в 05:42

GlusterFS

@citius 25 окт 2011 в 15:31

Вот именно момент превращения меня и интересует больше всего. :)
Сам принцип понятен.

@alex_www 25 окт 2011 в 15:25

Не понял зачем нужен efi раздел?

@LRC 25 окт 2011 в 15:36

efi нужен чтобы bios смог загрузиться c диска у которого таблица разделов GPT, таблица такая нужна чтобы можно было адресовать весь диск, так как у MBR есть ограничение d 2.2тб

@alex_www 25 окт 2011 в 15:46

Ставил недавно Debian testing и FreeBSD 9-rc1 на 8TB массивы, GPT разделы, родные инсталлеры, не наблюдаю efi раздела.

@alex_www 25 окт 2011 в 15:50

Вот собсвенно вывод gpart list | egrep ' Name| type:'

1. Name: da0p1
type: freebsd-boot
2. Name: da0p2
type: freebsd-ufs
3. Name: da0p3
type: freebsd-swap
4. Name: da0p4
type: freebsd-zfs
1. Name: da0

@Melkij 25 окт 2011 в 16:31

Первый раздел с какого сектора начинается?
Именно в этом вся фишка, если места хватает (от 256байт вроде надо), граб встраивается, не требуя отдельного раздела диска.

@Melkij 25 окт 2011 в 16:33

А дебиановский, по крайней мере, инсталятор, стартует первый раздел с 1мб отметки — для встраивания места хоть ложкой ешь.

@alex_www 25 окт 2011 в 16:40

Как ни меть MBR или GPT — всегда есть минимум 31 сектор в начале который не используется. Grub stage1 занимает вроде 16 секторов. Так что никакой efi раздел не нужен в Linux/FreeBSD установках на x86 платформе.

@Melkij 25 окт 2011 в 16:42

А вы пробовали?
Я — да. Grub не ставится, если первый раздел начинается, например у меня, с 40-го сектора и bios_grub не был предусмотрен.

@alex_www 25 окт 2011 в 16:47

Это вопрос скорее сколько надо для stage1 той или иной версии груб, и не имеет отношению к efi разделу. Если efi раздел и нужен, то я не понимаю зачем. Это и был изначальный вопрос.

@alex_www 25 окт 2011 в 16:37

GPT требует пропускать 32сектора (иди даже больше?) с начала диска (для protective mbr и legacy загрузчиков), потому, очевидно влазит stage1.

@Melkij 25 окт 2011 в 16:40

32 сектора, верно. 32 в начале диска и ещё 32 — в конце.
Но это только GPT.

Загрузчик ставится либо в раздел, маркированный как bios_grub в терминологии parted либо сразу после него.

@Melkij 25 окт 2011 в 16:45

после него === либо сразу после 32 секторов GPT; криво изъясняюсь.

@LRC 25 окт 2011 в 16:37

К сожалению на хетзнере проводить эксперименты накладно, они консоль дают только на 2 часа в неделю, намучу в офисе машину с efi биосом, попробую без этого раздела.

@mva 24 окт 2012 в 04:44

ну, сейчас они LARA дают не «в неделю», можно брать хоть подряд, но вот на просьбу забутать систему в EFI-enabled Rescue — сказали что не понимают что мне нужно и что у них нету rescue с поддержкой EFI.
Видимо, придётся «по старинке» :(

@arinoki 25 окт 2011 в 15:47

знаю о EFI только в контексте хакинтошей. глупый вопрос, но задам — значит ли наличие загрузчика на efi-разделе (efi-раздел обычно fat32) автоматом поддержку >3tb hdd?

@citius 25 окт 2011 в 16:13

Разве это не говорит только о том, что нужно загрузочный раздел разместить в пределах первых 2.2 ТБ?
ОС то потом все увидит.
Как во времена 32 гиговых хардов, тогда на них даже перемычки были особые.

@LRC 25 окт 2011 в 16:40

Документации по загрузке с GPT дисков, крайне мало на просторах инета, такой чтобы шаг за шагом, а по русски вообще проблематично найти, это меня и подвигло написать данную статью