debian etch - / on LVM2 on RAID1
- tes+or
- Неотъемлемая часть форума
- Сообщения: 535
- Зарегистрирован: 16 дек 2004, 17:47
- Откуда: minsk
- Контактная информация:
debian etch - / on LVM2 on RAID1
да, я знаю что вобщем-то тема пройдена, но не в контексте дебиана.
во первых - LVM в принципе не обязательно, хотя если это не стоит большого труда, то почему бы и нет, вещь приятная во всех отношениях.
важный момент - я вобщем-то сторонник сваливать все на одну ФС и даже своп там делать в виде файла, свои недостатки в этом конечно есть, но представить ось в виде такой монолитной абстракции всегда удобно, особенно в случае возникноения ситуаций всяческих нежелательных.
итак - строим логическую цепочку. граб грузит ядро, почитав в MBR где оно лежит. грузит он его только с простой FS, без всяких там рэйдов и LVMов(я прав?), значит без простого /boot, вне рэйда и ЛВМа, нам никак не обойтись, так? если да, то выделяем на одном диске мега 32 под бут, а на остальном создаем половинку рэйда. вторую половинку точно такого же размера создаем на втором диске и получаем 32 мега которые неизвестно куда девать. это норма? ладно, грузим с /boot само ядро, оно грузит inird, тот потом обсудим как находит RAID на котором находит LVM, монтирует это, запускает оттуда init и понеслась душа в рай по rc-скриптам, дальше уже от этой схемы ничего не зависит по большому счету, да?
а, да, инсталляция уже выполнена, поэтому мы потом обсудим миграцию, но для начала хотелось бы выяснить оптимальность сей схемы в принципе. LVM в принципе не обязательно, поэтому если это сильно упростит жизнь то можно и отказатся.
просто трудно как-то - у меня раньше было монолитное ядро самодельное, самодельный же инит и вообще все самодельное, а теперь все работает само и как этим управлять - непонятно.
разьясните плиз все в кратце и однозначно, дальше я сам разберусь.
во первых - LVM в принципе не обязательно, хотя если это не стоит большого труда, то почему бы и нет, вещь приятная во всех отношениях.
важный момент - я вобщем-то сторонник сваливать все на одну ФС и даже своп там делать в виде файла, свои недостатки в этом конечно есть, но представить ось в виде такой монолитной абстракции всегда удобно, особенно в случае возникноения ситуаций всяческих нежелательных.
итак - строим логическую цепочку. граб грузит ядро, почитав в MBR где оно лежит. грузит он его только с простой FS, без всяких там рэйдов и LVMов(я прав?), значит без простого /boot, вне рэйда и ЛВМа, нам никак не обойтись, так? если да, то выделяем на одном диске мега 32 под бут, а на остальном создаем половинку рэйда. вторую половинку точно такого же размера создаем на втором диске и получаем 32 мега которые неизвестно куда девать. это норма? ладно, грузим с /boot само ядро, оно грузит inird, тот потом обсудим как находит RAID на котором находит LVM, монтирует это, запускает оттуда init и понеслась душа в рай по rc-скриптам, дальше уже от этой схемы ничего не зависит по большому счету, да?
а, да, инсталляция уже выполнена, поэтому мы потом обсудим миграцию, но для начала хотелось бы выяснить оптимальность сей схемы в принципе. LVM в принципе не обязательно, поэтому если это сильно упростит жизнь то можно и отказатся.
просто трудно как-то - у меня раньше было монолитное ядро самодельное, самодельный же инит и вообще все самодельное, а теперь все работает само и как этим управлять - непонятно.
разьясните плиз все в кратце и однозначно, дальше я сам разберусь.
- tes+or
- Неотъемлемая часть форума
- Сообщения: 535
- Зарегистрирован: 16 дек 2004, 17:47
- Откуда: minsk
- Контактная информация:
вот неважно где один человек изрек два утверждения:
1.Загрузчик Grub про RAID ничего не знает. Но если его установить в MBR каждого диска, то работать будет.
2.Загрузчик Lilo знает про RAID уровней 0 и 1, соответственно умеет с них загружать систему.
>1.
как это, установить его в MBR? не, ну это понятно, но толку если он про рэйд ничего не знает, можно его хоть куда ставить. разьясните.
>2.
вот это уже более заманчиво. ценой отказа от ЛВМ можно полностью абстрагироватся от того на чем система установлена. просто создать рэйд и просто с него грузится. в чем подвох?
1.Загрузчик Grub про RAID ничего не знает. Но если его установить в MBR каждого диска, то работать будет.
2.Загрузчик Lilo знает про RAID уровней 0 и 1, соответственно умеет с них загружать систему.
>1.
как это, установить его в MBR? не, ну это понятно, но толку если он про рэйд ничего не знает, можно его хоть куда ставить. разьясните.
>2.
вот это уже более заманчиво. ценой отказа от ЛВМ можно полностью абстрагироватся от того на чем система установлена. просто создать рэйд и просто с него грузится. в чем подвох?
1) Для локально-доступной системы пользуем GRUB, ибо удобнее
2) Для удаленной lilo, ибо lilo -R работает как часики в отличии от.
3) И то и другое ставится на raid1 и работает с него. У меня RAID1 на /boot например дома.
4) Метки LVM находятся в конце раздела, и в теории не мешают загрузчику загрузить ядро и initrd.
Но в реальной жизни - /boot ext2 ro на raid1 или просто на разделе, все остальное полагаю ересью.
2) Для удаленной lilo, ибо lilo -R работает как часики в отличии от.
3) И то и другое ставится на raid1 и работает с него. У меня RAID1 на /boot например дома.
4) Метки LVM находятся в конце раздела, и в теории не мешают загрузчику загрузить ядро и initrd.
Но в реальной жизни - /boot ext2 ro на raid1 или просто на разделе, все остальное полагаю ересью.
Опыт растет прямо пропорционально выведенному из строя оборудованию
- tes+or
- Неотъемлемая часть форума
- Сообщения: 535
- Зарегистрирован: 16 дек 2004, 17:47
- Откуда: minsk
- Контактная информация:
1)вообще мы обсуждаем то, что будет стоять в датацентре, но к чему доступ есть раз в день-два.
2)это еще что? кажется что-то полезное. я что-то сходу доков по лило не нашел.
3)т.е. у меня может быть два диска, их полностью будет занимать один рэйд массив с одной ФС и граб меня с него загрузит? и лило тоже?
2)это еще что? кажется что-то полезное. я что-то сходу доков по лило не нашел.
3)т.е. у меня может быть два диска, их полностью будет занимать один рэйд массив с одной ФС и граб меня с него загрузит? и лило тоже?
- tes+or
- Неотъемлемая часть форума
- Сообщения: 535
- Зарегистрирован: 16 дек 2004, 17:47
- Откуда: minsk
- Контактная информация:
http://www.linuxsa.org.au/mailing-list/ ... /1270.html
ВО!
только все на одной фс, иначе у меня в голове все путается. кстати, а в самом деле, зачем разбивать систему на несколько партишнов? ну да, своп быстрее если он не поверх ФС работает, но стоит ли это того? и зачем отдельно boot var log?
ВО!
только все на одной фс, иначе у меня в голове все путается. кстати, а в самом деле, зачем разбивать систему на несколько партишнов? ну да, своп быстрее если он не поверх ФС работает, но стоит ли это того? и зачем отдельно boot var log?
tes+or, /boot - чтобы держать в ro дабы его никоеи образом в случае чего не зацепило. А дальше - кразным кускам файловой системы - разные требования. К примеру, /tmp хорошо бы держать noexec, все кроме / - nodev и nosuid, да и оптимальнее ext2 ничего не придумать. На /home нужный квоты, но не нужн atime, некоторый софт хочет atime в /var/ (скжем, некоторые MTA для своей очереди ЕМНИП), но оный atime совершенно вредем в /var/log, и уже тем более вреден для каталога почтой (т.е. хранилища) в случае если её _много_.
Во тебе пример из рпеальной жизни в виде гуманитарной помощи и пищи для размышления.
Во тебе пример из рпеальной жизни в виде гуманитарной помощи и пищи для размышления.
Код: Выделить всё
/dev/md0 on / type ext3 (rw,noatime,errors=remount-ro)
/dev/mapper/data_vg-log_lv on /var/log type reiserfs (rw,noexec,nosuid,nodev,noatime)
/dev/mapper/data_vg-home_lv on /home type ext3 (rw,nosuid,nodev,noatime,usrquota,grpquota)
/dev/mapper/data_vg-db_lv on /var/lib/mysql type ext3 (rw,noexec,nosuid,nodev,noatime)
/dev/mapper/data_vg-mail_lv on /var/mail type reiserfs (rw,noexec,nosuid,nodev,noatime)
Опыт растет прямо пропорционально выведенному из строя оборудованию
- Andrej Ramaszeuski
- Неотъемлемая часть форума
- Сообщения: 507
- Зарегистрирован: 28 ноя 2003, 11:42
- Откуда: Pardubice, CZ
- Контактная информация:
Andrej Ramaszeuski, есть, вроде как даже работает. Но в него до сих пор особо не верю. http://www.gnu.org/software/grub/manual ... ck-systems
Опыт растет прямо пропорционально выведенному из строя оборудованию