Как увеличить размер /home используя раздел с другого hdd

но гугл не помог.

Ну да, ну да. Видимо у тебя другой гугл. Ищи как перенести хомяк на другой диск.

Ты хочешь сделать RAID или просто перенести /home на другой диск?

Он хочет LVM, который, видимо, не использовал при установке.

пацаны, он прикалывается, или это реальность?

man mount

но гугл не помог.

4.2

Подскажите как это сделать?

lvm2

Для этого тебе нужен LVM, но если тебя устраивает чтобы /home был полностью на другом диске, то можно без этого обойтись.

Если хочешь на одном диске, делаешь так — копируешь всё из /home на другой диск с правами (например rsync, fsarchiver; в крайнем случае tar или cpio; если просто cp, то даты файлов сбросятся), затем добавляешь в /etc/fstab строчку для него и перезагружаешься. В этом случае старый домашний раздел останется нетронутым как бекап пригодится.

Если хочешь чтобы всё вместе было, то тебе придётся удалить этот раздел ext4, создать вместо него LVM physical volume, на нём создать logical volume, отформатировать, смонтировать, перенести данные, как описано выше, затем, убедившись что всё на месте, удалить оригинальный раздел /home, на его месте создать ещё один physical volume, добавить его в volume group и расширить до упора logical volume, а затем через resize2fs можно расширить и файловую систему.

ЕМНИП можно так сделать и в zfs или btrfs без LVM, но это я делать не пробовал.

если просто cp, то даты файлов сбросятся

5 звёзд нафлудил, а про cp -a не слышал.

Для ТС ссылка на btrfs:

https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices

Действительно, тоже можно.

5 звёзд нафлудил, а про cp -a не слышал.

К сожалению, cp -a портит даты файлов, я им как раз таки и пользовался и именно поэтому не рекомендую.

портит даты файлов

И каким же образом?

Спасибо, видимо LVM это то, что нужно.

Просто перенсти на другой диск не вариант. у меня уже около 1tb в /home, нужно было именно расширить.

Кто писал про LVM, большое спасибо!

... Просто хочу что бы размер /home был больше (на 1tb).

Чтобы жить спокойно - без таких заморочек - нужно изначально ставить систему на LVM-тома.

Если на живую систему - без переустановки, - то можно разметить новый диск (хоть с LVM, хоть без), создать файловую систему, примонтировать её к какой-нибудь корневой директории в /etc/fstab - например к /newhdd. Потом в эту файловую систему скопировать /home-директорию:

$sudo bash (переходим в root-режим)
#cd /
#find home -depth -print | cpio -pdmv /newhdd
#exit

После этого нужно примонтировать /newhdd/home к /home в /etc/fstab добавив в конец строчку:

/newhdd/home  /home  none bind 0 0

Перед заключительной операцией /home-директорию на старом диске нужно почистить (лучше переименовать на случай отката и завести новую - пустую). Всё это (чистка /home и правка fstab) лучше сделать загрузившись в recovery mode. Перегрузится...

Ну и иметь LiveCD-флэшку под рукой на случай каких-либо заморочек.

Такая метода позволит при желании перенести на новый диск и какие-то другие системные директории. Недавно этим занимался, когда делил систему между SDD и HDD )

Вот как-то так... Естественно, все надо делать очень осторожно и внимательно - перепроверяя свои действия и результаты.

И каким же образом?

Попробуй сам, у файла три даты есть, cp -a меняет Access на оригинальном файле, сохраняет Modify и ставит Change у копии на текущее время. tar кстати так же делает. Осталось проверить cpio и rsync

cpio тоже портит change time, хотя сохраняет время модификации.

без СМС?

Ты же в курсе, что Change - это время изменения иноды, а Modify - данных? Учитывая, что при копировании создаётся новая инода, такое поведение совершенно правильное.

Учитывая, что при копировании создаётся новая инода, такое поведение совершенно правильное.

Но не обязательно желаемое, вот в чём проблема. В частности если это тот же файл, просто переносимый на новое место. При резервном копировании файлов хотелось бы сохранить все времена файлов как есть.

А вообще я думал, что ctime это creation time, а это оказывается change

не обязательно желаемое, вот в чём проблема

Называть корректное поведение, не желаемое лично тобой, «порчей», по меньшей мере некорректно.

хотелось бы сохранить все времена файлов как есть.

Всегда удивляла подобная привязка к дате. Ну для примера, навернулась у вас батарейка на матери, ребут, время хз какое, пока ntp его поправит... Это не единственный вариант возможного изменения даты, только самый простой...

Ну я же не говорю что это прямо очень плохо, дата изменения сохраняется, но всё же.

Пока ты ищешь как увеличить хоум, девушки увеличивают размер груди, вопрос что лучше?

Ну я же не говорю что это (обновление ctime) прямо очень плохо, дата изменения сохраняется, но всё же.

Вообще говоря, сохранение ctime непринципиально при переносе/восстановлении файловой системы. Разве что, у вас выполняется какой-то инкрементальный бэкап системы, заточенный и на изменение ctime - тогда это повлечет потом лишнее бэкапирование.

Кроме того, изменить ctime не так-то и просто. Ради интереса погуглил эту тему. Нарыл следующее:

http://lists.gnu.org/archive/html/coreutils/2010-08/msg00010.html

POSIX says that atime and mtime are user-settable to arbitrary times via the utimensat() family of syscalls, but that ctime _must_ unfakeably track the current time of any action that changes a file's metadata or contents (utimensat() being one of the a variety of actions that will alter ctime as a side effect, but so will write(), chmod(), ...). This is intentional - there are some algorithms that rely on knowing the last time a file was modified (ctime-based) and other algorithms that only care about the last time the file was (purported) to have been read or written (atime and mtime).

The _only_ way to fake a ctime change is to alter your system's current time, do an action that updates ctime to the current moment, then restore the system's current time. But since it is generally a privileged action to alter system time, that means that ordinary users cannot change ctime to anything other than the current time.

... Кроме того, изменить ctime не так-то и просто...

Имелось в виду «сохранить при копировании», «подделать»... )

Ну, fsarchiver должен справиться, rsync (даже от рута) может и нет.

Вообще говоря, сохранение ctime непринципиально при переносе/восстановлении файловой системы.

Ну пожалуй да, но всё же неприятно когда инфа теряется.

Так что да, получается, что ТС нужно создать volume group, physical и logical volume на другом диске, отмонтировать /home в single user mode, перетащить через fsarchiver, затем удалить оригинал и создать ещё одну physical volume и включить её в ту же volume group

Например, как у меня:

mount --bind /hdd2/Documents/ /home/meliafaro/Documents/
mount --bind /hdd2/Pictures/ /home/meliafaro/Pictures/
mount --bind /hdd2/Templates/ /home/meliafaro/Templates/
mount --bind /hdd2/Videos/ /home/meliafaro/Videos/
mount --bind /hdd2/Music/ /home/meliafaro/Music/
mount --bind /hdd2/Downloads/ /home/meliafaro/Downloads/
mount --bind /hdd2/Wine/ /home/meliafaro/Wine
mount --bind /hdd2/Samples/ /home/meliafaro/Samples/
mount --bind /hdd2/Mail_Ru/ /home/meliafaro/Mail_Ru/
mount --bind /hdd2/AppImages/ /home/meliafaro/AppImages/

Второй жёсткий диск подмонтирован в /hdd2. Во всех операционках каталоги из этой файлопомойки монтируются в хомяк. Соответственно, эти каталоги и там, и там общие, а настройки хранятся по отдельности.

А нужны ли такие заморочки?

Смонтируй диск в /home/$username/$foldername

Зато если вдруг что - будешь знать что и на каком диске у тебя лежит

Ну, fsarchiver должен справиться (сохранить ctime), ...

Это только если накатывать на новый раздел raw-данные - ну так тогда можно и dd задействовать ). Если при восстановлении менять тип файловой системы, или если восстановление всегда выполняется по файлам - размечается новая файловая система и файлики перезаписываются туда через обычное линуксовое api, - то тогда весьма сомнительно, что сохраняется ctime (вроде нет в api такой функции, с помощью которой можно было бы восстановить у файла старый ctime).

Ну и если уж вы рекомендуете использовать fsarchiver для пущей «надёжности» копирования, то не забывайте указывать на ОБЯЗАТЕЛЬНОЕ использование опций label=newlabel,uuid=newuuid при выполнении «fsarchiver restfs ...». А то у человека задублируются UUID-ы двух разных разделов и полезут потом всякие задницы ))). И концов не найдет...

Ну и зачем ты это сюда принёс?

Хочешь показать как не надо делать? Хотя для одиночного локалхоста с одним юзверем такое решение пройдёт, но не более этого. Если завтра будет 2 пользователя, а если больше тоже будешь биндить овер 100500 точек монтирования?

Смотри xdg-user-dirs и научись делать правильно!

Мне посрать, анон. Я не работаю эникеем в школе, поэтому могу выбирать наиболее простые и рабочие решения.

А ты нет.

Причем тут школа? Например домашний компьютер и ты, жена, дети.

Теперь ему придется конвертировать раздел хомяка в BTRFS командой

sudo umount /home
sudo btrfs-convert /dev/sdX
sudo mount /dev/sdX /home

sudo btrfs device add /dev/sdY /home --force

ls -l /dev/disk/by-uuid | grep sdX

У мну на разделе с /home давно место забито, выношу и симлинкаю поддиректории на NTFS-раздел по мере надобности; УМВР, кроме ненужного AppArmor.

жена, дети

С линуксом на хосте это не совместимо, только если муж тиран или подцепил жену на LUG.