Хочу заменить православные обычные разделы на LVM, отговорите

не могу, ты мне нравишься.

Я сам так нарывался. Потому и не советую LVM на много дисков без RAID.

Уйди, противный

А случай с UEFI чем будет отличаться? У самого UEFI, интересно.

Я всё никак не попробую, но, скорее всего, тем, что отдельного /boot не понадобится, но будет нужен раздел /boot/EFI с соответствующими кишками. Так что особых различий нет и для загрузки с LVM таки нужен отдельный раздел. Ну или глубокое знание мануалов.

Кто тебе мешает зеркалировать средствами LVM?

Мой пробел в мат. части по этому аспекту. Надо почитать.

Хочется нормального, всегда так делаю.

Лорчую этого сэра. PS. СУ!

Вот это у людей проблемы. Обычные разделы или lvm :)

Пока диск один, в плане надёжности разницы нет, но одного диска со временем становится мало, появляется второй, который надёжность системы уменьшает

Уменьшает совсем незначительно, случаев, когда файл начинается на одном PV, а заканчивается на другом, вряд ли будет много. Да, усложняется восстановление оставшихся данных (в случае отдельных дисков восстановления вообще нет, а тут надо ручками шевелить), но не сказать, что очень сильно, вся инструкция на экране помещается - https://www.novell.com/coolsolutions/appnote/19386.html
Но диски очень редко делают мгновенный «чпок» (например, я про такое только слышал, лично сталкиваться ни разу не доводилось, а дисков через меня не одна сотня прошла), обычно это процесс постепенный и начинается с появления перемещённых секторов. А в этом случае с LVM всё просто шоколадно, ввод нового диска в массив и вывод старого делается элементарно и без прерывания работы, кроме двух перезагрузок, а так как копирование данных происходит на уровне устройства, а не фс, то и быстрее (в случае большого диска с кучей мелких файлов и/или сильной фрагментацией - в разы быстрее).

sdio> Отговариваю. Если все перейдут на LVM, то над кем мы будем потешаться в вопросах «Не хватает места на разделе, как увеличить?»

dhameoelin> Над теми, кто не читает маны и удивляется, что у него online-resize не работает, ессно...

а кстати! если появился знающий человек в теме..

какой мне надо почитать мануал, чтобы уменьшить размер корневой файловой системы (EXT4) ?

цель: нужно откусить кусочек от неё (от правой стороны), чтобы добавить этот кусочек в другое место.

размонтировать её не могу, так как файловая система для корня (/).

загрузиться с LiveDVD — тоже не могу так как это удалённый компьютер, к которому не имею физического доступа (есть только ssh root).

Если мне склероз не изменяет, то запланированный ресайз произойдёт при перезагрузке. Но как добиться этой запланированности - навскидку не скажу. И, да, там же ещё FS предварительно надо уменьшить. Задачка... Sudo cast sdio

во-первых рут-раздел не уменьшают.

впрочем данную задачу просто решить средствами lvm. создаем новый lv меньшего раздела, копируем на него текущий / и меняем запись в новом fstab и в grub'e.

Мне стыдно. Об очевидном решении сразу не подумал.

смени оперативку кошерную

на lvm смысла мало, а вот на таблицу btrfs с подтомами было бы очень не плохо.

lvm есть смысл держать только от 2 дисков, на 1 диске куда больше btrfs смысл имеет.

читай маны начиная с man lvm и далее по ссылкам SEE ALSO. Отговаривать тебя мама будет

у тебя устаревшая лет на 10 информация

Что же ты сразу не сказал. Для меня ноутбук как смартфон или публичный комп. Я его не настраиваю, не меняю конфигурацию и не храню на нем ничего ценного. Сломается, потеряется — забыли!

Ну какая-то информация всё равно остаётся. У меня том с шифрованием luks, внутри него - PV том. Раз в неделю снимаю снапшот /home и копирую на домашний сервер

А кто в здравом уме будет использовать LVM без raid на два и более hdd не для миграции?

А ничего что наличие здравого ума позволяет делать и не такое, и без повышения риска потери данных?

Если в качестве PV томом используется не raid, не стоит растягивать один LV на несколько PV. В случае, если помрёт один PV, всегда можно сделать vgreduce --removemissing, потерять LV, которые были на вылетевшем томе, но сохранить все остальные

Если так велик шанс просрать данные, зачем мне использовать btrfs или LVM?

Я предлагаю посмотреть на вопрос шире - зачем тебе компьютер?

Кто тебе мешает зеркалировать средствами LVM?

А есть документация и случаи успешного использования? Меня терзают сомнения, как восстанавливать зеркало LV после сбоя

И что использовать вместо ?

какой мне надо почитать мануал, чтобы уменьшить размер корневой файловой системы (EXT4) ?

Уменьшить размер ext* без размонтирования невозможно. Только увеличить

А ничего что наличие здравого ума позволяет делать и не такое, и без повышения риска потери данных?

А ничего. Ты только что описал почему.

Я, конечно, утрирую, но смысл в том что потеря данных с ноутбука не заставит даже посочувствовать, всё сразу копируется во внешний мир.

Но диски очень редко делают мгновенный «чпок»

Клинит механнику. Сталкивался довольно часто. Информацию можно попытаться восстановить в специальных лабораториях. Но затея это очень дорогостоящая и практически всегда с отрицательным результатом. Хотя один раз, в моей практике был случай, когда сотрудники лаборатории все же выудили всю информацию.

За двадцать лет возни с компами не только не разу не встречал такое, но и не встречал никого, кто бы с этим лично сталкивался. Может не стоит дисками гвозди забивать?

При linear томе в случае потери одного HDD пропадают данные с него, но не весь LV. Мало отличается от потери данных с одиночного HDD.

От файловой системы зависит. Если, например, linear том из двух hdd, а поверх xfs, то при выпадении одного hdd от данных не останется ничего.

впрочем данную задачу просто решить средствами lvm. создаем новый lv меньшего раздела, копируем на него текущий / и меняем запись в новом fstab и в grub'e.

да. способ нормальный. согласен!

но в моём случае тогда есть ещё одно доп условие (то что я его сразу не назвал — это моя оплошность):

доп условие: свободного места полно внутри файловой корневой системы. но свободного места нет вообще ни где кроме корневой файловой системы.

вся разметка жёсткого диска занята только этим корневым разделом (очевидно это придумал какой-то дурак, так я думаю :)).

Поскольку ограничение на онлайн уменьшение корневой фс никак не связанно с lvm, то уменьшать fs по-любому придется в оффлайн режиме.

У нормальных линуксоидов / имеет размер 512Мб, все остальное на отдельных lv и таких проблем просто не возникает.

Ошибки дизайна/планирования в твоей задаче налицо, следовательно ты должен страдать :-)

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

512 мало как то, я делаю на кальке:
/boot/efi 200mb fat32
/boot - 600 mb
/ - 4 Gb
/var - 18 Gb
/var/log - 4 Gb
/tmp - 6 Gb
/var/calculate - 28 Gb
/var/calculate/tmp - 12 gb
swap - 8 Gb
/usr - 20 Gb
/usr/local - 8 Gb
/usr/portage - 20 Gb
/opt - 24 Gb
/home - оставшееся.
везде btrfs. Калька увы не умеет жить на таблице разделов btrfs. А на fedora :
/boot- 800
/ - 10 gb
/var - 38 Gb
/var/log - 6 Gb
/tmp - 8 Gb
/usr - 30 Gb
/usr/local - 30 Gb
/opt - 34 Gb
/home - оставшееся.
таблица разделов btrfs, и везде btrfs.
Всё прекрасно работает.

Если, например, linear том из двух hdd, а поверх xfs, то при выпадении одного hdd от данных не останется ничего.

Точно ли? У меня не так давно сыпался один винт и при переносе данных с него часть блоков физически похерилась. Часть файлов просто пропала, оставшиеся — без ошибок. Это именно xfs на linear lvm. Безошибочность оставшихся подтверждается пересчётом хешей — это всё на торрент-разделе было :)

у меня ссд 240 гб +2тб диск, мне экономить незачем.

От файловой системы зависит.

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

Ты полгода назад еще только слышал о zfs, но еще не пробовал, а теперь авторитетно рассказываешь что произойдет с xfs на lvm (а в тредах о zfs ты весьма посредственно понимал lvm)

Не экономь, тут о тебе никто вообще не говорит. / самая ограниченная в плане потыкать online, и если ее можно сделать минимальной и не трогать, то почему этого не сделать. Я также имею привычку делать копию этого маленького / и всегда иметь под рукой систему в которую можно загрузиться, даже если основной / убьется апгрейдом/ошибочной командой/чем-то еще.

Ошибки дизайна/планирования в твоей задаче налицо, следовательно ты должен страдать :-)

Ды и сам вижу что налицо :-) ..

Вот и я думаю что дурак конструировал этот сервер..

Значит ты не сталкивался с дисками серии DTLA. Хотя странно, если опыт 20 лет. Так те диски так и звали «дятлы», уж очень часто они делали «чпок» при самой осторожной эксплуатации. Странно, что ты не застал WD в 2000-2001. Они тогда тоже частенько дохли внезапно от перегрева. Опять же были знаменитые партии смертников и от Maxtor, и от Seagate и от многих других. А ты не втречал. Маленький поток проходит через твои руки. Даже сегодня попадаются отдельные экземпляры, у которых просто может заклинить головка/движок. Нельзя расслаблятся, это может случится с каждым. И нужно заранее быть готовым к любим непредвиденным ситуациям. Для этого и нужен Raid.

Сам с дятлами дел не имел, действительно. Что дохли, как мухи, слышал, но о причинах не интересовался. Но не при осторожной эксплуатации, у всех, кто озаботился их здоровьем, спокойно прожили долгую и счастливую жизнь, страдали, в основном, те, кто относился к ним, как к обычным тогдашним винтам — возили системники транспортом, не сняв винта, таскали по друзьям и т.д. И от перегрева ни один не умер, может оттого, что я не допускал перегрева.

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

4.2!!!
Даже IBM в то время призналась, что серия получилась неудачная, и все вышедшие из строя винты в гарантийный период, бесплатно меняли на винты другой серии. Причин было много.

Во первых, не совместимость внутреннего контролера жесткого диска с некоторыми чипами южного моста - в этом случае хоть как бережно ни относись к жесткому диску - дни его сочтены.

Вторая причина, отключение жесткого диска сразу после получения команды на отключение, несмотря на то, что в кеше диска остались не записанные данные, и не смотря на то, что головка еще не припаркована, что тоже приводило к выходу из строя жесткого, хоть как бережно ни относись к нему.

Диски других производителей этим не страдали, а при получении команды на отключение, сначала записывали содержимое кеша на магнитную поверхность, потом парковали головку, и лишь потом отключались, о чем рапортовали ОС, которая после этого посылала команду на отключения блоку питания. Кстати эта проблема лечилась и средствами самой ОС - Microsoft, хоть и с опозданием, но выпустили патч, который увеличивал задержку на отключение диска, что бы жесткий успел записать содержимое кеша.

Ну и третья причина, в DTLA использовалось стекло и керамические подшипники. Кармические подшипники очень быстро изнашивались и «сыпались», что приводило к микрокрену пластины, при котором стеклянная пластина была более подвержена выходу из строя, нежели алюминиевые или пластиковые пластины других производителей. Кроме того, изношенные подшипники также не редко приводили к заклиниванию шпинделя.

Согласись, что из всех приведенных причин, ни одна не зависит от бережности хозяина. Во всех приведенных случаях, диск делал «чпок» внезапно. И причин на самом деле намного больше, при которых жесткие диски делают «чпок» и сегодня. Внезапный «чпок» сегодня, наверное не делают только SSD диски, но они очень быстро изнашиваются просто потому, что у них ограниченное число циклов перезаписи сектора.

Точно ли?

Достаточно при записи на «linear lv + xfs» посмотреть iostat, записываемый файл «размазывается» равномерно на оба hdd. Если при прочих равных писать на ext4, то пишет последовательно, пока первый hdd не заполнится второй курит.

Хотя, возможно, у тебя на xfs мало agcount, тогда может писать последовательно. В случае с agcount=1 именно так и будет, но тогда теряется важная фича xfs - распараллеливание потоков данных. Я при создании xfs задаю agcount>=32.

Достаточно при записи на «linear lv + xfs» посмотреть iostat, записываемый файл «размазывается» равномерно на оба hdd

Кем размазывается? LVM не может размазывать, потому что это linear. xfs не может размазывать, потому что работает на более высоком уровне.

В случае с agcount=1 именно так и будет, но тогда теряется важная фича xfs - распараллеливание потоков данных

Сейчас посмотрел — agcount=16

Я при создании xfs задаю agcount>=32

Ну так к LVM и xfs тогда никаких претензий. Если оно у тебя работает так, как ты расписал, то ты своими руками делаешь stripe — какие тогда вопросы к надёжности?

...

Правда, у себя я такого не наблюдаю.

Если не пугает фрагментация http://bisqwit.iki.fi/source/lvm2defrag.html и невозможность восстановления данных из Windows, то валяйте.

xfs не может размазывать

Ну как же не может? делаем linear VG из двух hdd (не stripe!), создаем LV, допустим на весь том. На LV создаём ФС XFS с достаточно большим agcount, затем пишем на XFS.

потому что работает на более высоком уровне.

Файловая система понятия не имеет о том на каком уровне она находится. Она заняла весь LV и пишет данные одновременно в несколько областей раздела. iostat показывает примерно равномерную запись на оба hdd.

Use ZFS, Mr. Smith

Поскольку ограничение на онлайн уменьшение корневой фс никак не связанно с lvm, то уменьшать fs по-любому придется в оффлайн режиме.

У нормальных линуксоидов / имеет размер 512Мб, все остальное на отдельных lv и таких проблем просто не возникает.

Ошибки дизайна/планирования в твоей задаче налицо, следовательно ты должен страдать :-)

короче — сам отвечаю на свой вопрос.

как уменьшить корневую EXT4-файловую-систему(?), в случае если она занимает весь (единственный) физический HDD. и при этом нельзя загрузиться с LiveDVD, так как нет физического доступа к компьютеру (нельзя вставить накопитель.. только удалённый доступ есть) ???

отвечаю. придумал такой вариант:

1. нужно подготовить специальный initrd-файл , внутри которого сделать BASH-скрипт который будет вместо загрузки операционной системы — переразмечать файловые системы (корневой раздел уменьшать).

2. затем загрузить этот initrd-файл в оперативную память — через команду kexec. ну и выполнить (через kexec).

такой вот хитрый план :-)