LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

1

Здравствуйте товарищи.

я купил себе новый hdd, отформатировал его в ext4 и теперь хочу использовать его, но так, что бы даже не думать о том, что это физический другой диск. Просто хочу что бы размер /home был больше (на 1tb).

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

Думаю что это в целом возможно, но гугл не помог.


Для этого тебе нужен 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, но это я делать не пробовал.

Xenius ★★★★★ ()
Последнее исправление: Xenius (всего исправлений: 2)
Ответ на: комментарий от gasinvein

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

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

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

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

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

Xenius ★★★★★ ()

... Просто хочу что бы размер /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 )

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

vinvlad ()
Ответ на: комментарий от gasinvein

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

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

Xenius ★★★★★ ()
Ответ на: комментарий от Xenius

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

gasinvein ★★★ ()
Ответ на: комментарий от gasinvein

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

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

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

Xenius ★★★★★ ()
Последнее исправление: Xenius (всего исправлений: 3)
Ответ на: комментарий от Xenius

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

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

anc ★★★★★ ()
Ответ на: комментарий от Xenius

Ну я же не говорю что это (обновление 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.

vinvlad ()
Ответ на: комментарий от vinvlad

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

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

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

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

Xenius ★★★★★ ()
Последнее исправление: Xenius (всего исправлений: 1)

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

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. Во всех операционках каталоги из этой файлопомойки монтируются в хомяк. Соответственно, эти каталоги и там, и там общие, а настройки хранятся по отдельности.

meliafaro ★★★★★ ()
Ответ на: комментарий от Xenius

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

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

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

vinvlad ()
Ответ на: комментарий от meliafaro

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

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

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

anonymous ()
Ответ на: комментарий от gasinvein

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

sudo umount /home
sudo btrfs-convert /dev/sdX
sudo mount /dev/sdX /home
и объединять его с новым HDD командой
sudo btrfs device add /dev/sdY /home --force
А потом еще и /etc/fstab править. Найти там монтирование /home, изменить ext4 на btrfs и изменить UUID в начале строки на UUID показанный командой
ls -l /dev/disk/by-uuid | grep sdX

SR_team ★★★★ ()
Последнее исправление: SR_team (всего исправлений: 1)