Я всё никак не попробую, но, скорее всего, тем, что отдельного /boot не понадобится, но будет нужен раздел /boot/EFI с соответствующими кишками. Так что особых различий нет и для загрузки с LVM таки нужен отдельный раздел. Ну или глубокое знание мануалов.
Пока диск один, в плане надёжности разницы нет, но одного диска со временем становится мало, появляется второй, который надёжность системы уменьшает
Уменьшает совсем незначительно, случаев, когда файл начинается на одном PV, а заканчивается на другом, вряд ли будет много. Да, усложняется восстановление оставшихся данных (в случае отдельных дисков восстановления вообще нет, а тут надо ручками шевелить), но не сказать, что очень сильно, вся инструкция на экране помещается - https://www.novell.com/coolsolutions/appnote/19386.html Но диски очень редко делают мгновенный «чпок» (например, я про такое только слышал, лично сталкиваться ни разу не доводилось, а дисков через меня не одна сотня прошла), обычно это процесс постепенный и начинается с появления перемещённых секторов. А в этом случае с LVM всё просто шоколадно, ввод нового диска в массив и вывод старого делается элементарно и без прерывания работы, кроме двух перезагрузок, а так как копирование данных происходит на уровне устройства, а не фс, то и быстрее (в случае большого диска с кучей мелких файлов и/или сильной фрагментацией - в разы быстрее).
Если мне склероз не изменяет, то запланированный ресайз произойдёт при перезагрузке. Но как добиться этой запланированности - навскидку не скажу. И, да, там же ещё FS предварительно надо уменьшить. Задачка... Sudo cast sdio
впрочем данную задачу просто решить средствами lvm. создаем новый lv меньшего раздела, копируем на него текущий / и меняем запись в новом fstab и в grub'e.
Что же ты сразу не сказал. Для меня ноутбук как смартфон или публичный комп. Я его не настраиваю, не меняю конфигурацию и не храню на нем ничего ценного. Сломается, потеряется — забыли!
Ну какая-то информация всё равно остаётся. У меня том с шифрованием luks, внутри него - PV том. Раз в неделю снимаю снапшот /home и копирую на домашний сервер
А кто в здравом уме будет использовать LVM без raid на два и более hdd не для миграции?
А ничего что наличие здравого ума позволяет делать и не такое, и без повышения риска потери данных?
Если в качестве PV томом используется не raid, не стоит растягивать один LV на несколько PV. В случае, если помрёт один PV, всегда можно сделать vgreduce --removemissing, потерять LV, которые были на вылетевшем томе, но сохранить все остальные
Клинит механнику. Сталкивался довольно часто. Информацию можно попытаться восстановить в специальных лабораториях. Но затея это очень дорогостоящая и практически всегда с отрицательным результатом. Хотя один раз, в моей практике был случай, когда сотрудники лаборатории все же выудили всю информацию.
За двадцать лет возни с компами не только не разу не встречал такое, но и не встречал никого, кто бы с этим лично сталкивался. Может не стоит дисками гвозди забивать?
впрочем данную задачу просто решить средствами lvm. создаем новый lv меньшего раздела, копируем на него текущий / и меняем запись в новом fstab и в grub'e.
да. способ нормальный. согласен!
но в моём случае тогда есть ещё одно доп условие (то что я его сразу не назвал — это моя оплошность):
доп условие: свободного места полно внутри файловой корневой системы. но свободного места нет вообще ни где кроме корневой файловой системы.
вся разметка жёсткого диска занята только этим корневым разделом (очевидно это придумал какой-то дурак, так я думаю :)).
Если, например, linear том из двух hdd, а поверх xfs, то при выпадении одного hdd от данных не останется ничего.
Точно ли? У меня не так давно сыпался один винт и при переносе данных с него часть блоков физически похерилась. Часть файлов просто пропала, оставшиеся — без ошибок. Это именно xfs на linear lvm. Безошибочность оставшихся подтверждается пересчётом хешей — это всё на торрент-разделе было :)
Ты полгода назад еще только слышал о 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 — какие тогда вопросы к надёжности?
Ну как же не может? делаем linear VG из двух hdd (не stripe!), создаем LV, допустим на весь том. На LV создаём ФС XFS с достаточно большим agcount, затем пишем на XFS.
потому что работает на более высоком уровне.
Файловая система понятия не имеет о том на каком уровне она находится. Она заняла весь LV и пишет данные одновременно в несколько областей раздела. iostat показывает примерно равномерную запись на оба hdd.
Поскольку ограничение на онлайн уменьшение корневой фс никак не связанно с lvm, то уменьшать fs по-любому придется в оффлайн режиме.
У нормальных линуксоидов / имеет размер 512Мб, все остальное на отдельных lv и таких проблем просто не возникает.
Ошибки дизайна/планирования в твоей задаче налицо, следовательно ты должен страдать :-)
короче — сам отвечаю на свой вопрос.
как уменьшить корневую EXT4-файловую-систему(?), в случае если она занимает весь (единственный) физический HDD. и при этом нельзя загрузиться с LiveDVD, так как нет физического доступа к компьютеру (нельзя вставить накопитель.. только удалённый доступ есть) ???
отвечаю. придумал такой вариант:
1. нужно подготовить специальный initrd-файл , внутри которого сделать BASH-скрипт который будет вместо загрузки операционной системы — переразмечать файловые системы (корневой раздел уменьшать).
2. затем загрузить этот initrd-файл в оперативную память — через команду kexec. ну и выполнить (через kexec).