Риск есть всегда. Любая программа разметки пару раз предупредит, чтобы сохранили копию. Переразметить можно. А вот крошить на хоме и свап совсем не советую. Отрежь один раздел, для корня. Свап файл можешь создать на любом разделе, на корневом или с данными. Вместо хоме, если так уж чешется, приспособишь раздел с данными.

Думаю, да. Убрать данные в другое место. Загрузиться с live-cd открыть, например, - gparted и там уменьшить диск. Появится свободное место, которое форматнуть в нужное (swap/home). Потом загрузиться и вернуть данные.

Еще подключить нужно будет в fstab чтобы система знала, какой раздел куда монтировать при загрузке..

почти полностью

Цифра то какая?

man gparted

Можно ли разбить его

Можно, я разрешаю.

98,5 %

Можно, только если ты данные куда-нибудь переместишь временно, иначе никак.

98,5 %

Отказать. Только предварительно скопировать куда-то некритичные данные.

Просто установи туда свою систему. Разве что с загрузчиком будет туговато, но если есть хоть мегабайт неразмеченного, этого хватит для ESP под GRUB, а иначе только флэшка.

Можно в оперативку скопировать временно сколько влезет. Если это поможет.

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

Переразбивка наживую в любом случае опасна и делается костылями. Хотя как правило и срабатывает.

Чето вспомнилось как я делал такое с зеркалом mdadm:

• вытащил диск из райда
• создал на нем другую таблицу разделов и сделал из них новый degraded raid
• скопировал с одного degraded райда на другой degraded райд
• переразбил 2й диск и засунул его в райд синхронизироваться.

Но даже в такой схеме было ссыкотно. :)

Если там ФС, размер которой можно уменьшать, например ext4, то можно попробовать так:

1. Максимально уменьшить ФС. В идеале на 1.5%.
2. Уменьшить раздел.
3. Создать новый раздел.
4. Скопировать туда 1.5% или сколько вместится данных.
5. Максимально уменьшить ФС первого раздела. В идеале ещё на 1.5%, которые были скопированы оттуда.
6. Уменьшить первый раздел.
7. Увеличить второй раздел.
8. Увеличить ФС второго раздела.
9. GOTO 4. Повторять, пока не добьёшься нужного результата.

Это займёт уйму времени, это будет неплохим тестом алгоритмов изменения размера ФС, есть ненулевой шанс потери данных, есть ненулевой шанс, что из-за фрагментации в какой-то момент весь процесс застопорится. 1.5% это прям совсем мало, было бы у тебя 10% свободно, может быть был бы смысл в таком подходе.

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

теперь я твой фанат

Это просто супер-вау «решение»: память же не требуется при перекройке диска, её безусловно в избытке (там всего-то около террабайта каких-то файлов. зато озу, наверное, 16 или даже больше гигабайт) внезапное отключение питания

В двух словах: ничто не может выйти из-под контроля //ага-ага//

Оно того стоит? Зачем тебе ещё 1 милипиздрючески маааленький раздельчик?

может у него сервак с 250 гигами, я же написал если поможет, так что не тупи

есть ненулевой шанс потери данных, есть ненулевой шанс, что из-за фрагментации в какой-то момент весь процесс застопорится

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

Зачем тебе ещё 1 милипиздрючески маааленький раздельчик?

Вот кстати да. Все эти «система отдельно, хоум отдельно, ещё и под своп давайте раздел сделаем» – хз какой смысл оно имело на заре человечества, а щас проще всего забабахать один общий раздел на всё, а своп не нужен – в файл (если таки действительно нужен).

Не, ну если сразу делать то ок. А лучше не разделы а вообще диски отдельные, у меня два IDE 80 гиговых система + своп (который если мне надо превращается во что угодно, а потом опять в своп если надо) и отдельный полтора литра чисто хомяк. Ну это просто с помойки :) считай диски достались вот и подцепил. А так если система уже обжитая и там всё в одном, никакого смысла разбивать его нет, тем более что он забит считай уже битком. А если оставшееся место отжать то… всё, куда всё будет писаться то? Встанет всё колом и всё, зато чистый раздел на пару гигов (в лучшем случае) есть… на кой то хер :D

Не, ну если сразу делать то ок.

Да ну… Приспичит чуть места у системы забрать и хомяку отдать – и начинаются пляски секс секс с плясками эротические танцы стриптиз похабный: «можно ли переразбить диск, почти полностью занятый данными?»

А лучше не разделы а вообще диски отдельные,

В RAID0, гыгы. Шутка! RAID0 это дичь.

Т.к. лично у меня никаких специальных дисковых массивов не наблюдается, и подход к накопителям предельно тупой – купил-воткнул, то я плюсую отдельные диски, правда видимо вкладываю в это несколько другой смысл: у меня система с хомяком – на зеркале, а всё остальное – тупо отдельные диски под файлопомойки различные.

Я когда-то делал такое. Заняло несколько суток. Объем винта не помню, но сильно меньше 500гб.

Нынче винты пошустрели и потолстели, так что несколько суток = const.

RAID

Ненужно

Раньше у меня был 1 диск. Всё и было на 1 разделе я не парился, появились диски, стёр систему с основного полностью отдав его хомяку и накатил на другой вот и всё. Потом я несколько раз по дистрам прыгал перезатирая тот который чисто под систему, а диск с хомяком сам по себе. Параллельно да есть ещё пару просто воткнутые под разный хлам. Плюс отдельных дисков ещё в том что рано или поздно один из них начнёт сыпаться и можно оперативно всё с него скопировать. Вот прошлый раз у меня диск с системой сказал давай досвидания только RO и всё тут, SMART зашкалил как шакал я тупа всё с него скопировал в другой считай пустой, fstab поправил, grub дёргнул, перезагрузился и всё.

Вот кстати да. Все эти «система отдельно, хоум отдельно, ещё и под своп давайте раздел сделаем» – хз какой смысл оно имело на заре человечества, а щас проще всего забабахать один общий раздел на всё, а своп не нужен – в файл (если таки действительно нужен).

В OpenBSD это используется для безопасности. Во-первых чтобы переполнение /var/log, например, никак не влияло на другие разделы. Во-вторых чтобы монтировать разные точки монтирования с разными параметрами (ro, noexec и тд). В линуксе второе вряд ли применимо, что-нибудь, да поломается.

Про своп в файле - вроде раньше были проблемы с хибернейтом. Впрочем я точно не знаю. Вроде сейчас должно работать. Хотя я не вижу проблем сделать своп отдельным разделом. Ты же сразу определяешься, какой своп какого размера тебе нужен, ну и сразу место под него отдать на диске. Если бы линукс умел динамически размер своп-файла менять, как винда, тогда смысл в своп-файле был бы, а так - хз.

Да ну… Приспичит чуть места у системы забрать и хомяку отдать – и начинаются пляски секс секс с плясками эротические танцы стриптиз похабный: «можно ли переразбить диск, почти полностью занятый данными?»

Я считаю, что для такого юз-кейса нужно использовать LVM и наращивать размеры по мере их заполнения. Может быть даже как-то автоматически это сделать, точно не знаю, можно ли. Что-то вроде: если осталось меньше 10 гигабайтов свободного места на разделе, то плюсануть ему ещё 10 гигабайтов сверху. Если «тупо» - то по крону раз в минуту, например. Но лучше, конечно, каким-то коллбеком.

Во-первых чтобы переполнение /var/log, например, никак не влияло на другие разделы.

Логично. Пару месяцев назад я пропатчил lightdm, отключив ~/.xsession-errors, т.к. после пробуждения VLC частенько засирает его весь диск под завязку.

Во-вторых чтобы монтировать разные точки монтирования с разными параметрами (ro, noexec и тд).

Про это забыл.

Про своп в файле - вроде раньше были проблемы с хибернейтом. Впрочем я точно не знаю. Вроде сейчас должно работать.

Хм, про это тоже забыл: у меня, помнится, не работало пару-тройку лет назад. Заглянул в fstab – сейчас у меня своп – раздел на каком-то стареньком SSD, исключительно хибернейта ради.

Я считаю, что для такого юз-кейса нужно использовать LVM

За много лет так и не осилил разобраться, что это за зверь такой странный. Пробовал читать доку из-за того, что cryptsetup его зависимостью тянет – и чёт бросил.

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

Лучше купить новый диск. Какого объёма - отдельный вопрос, либо маленький под те нужды куда он собирался создавать новые разделы, либо большой (больше чем тот что сейчас, т.к. на тот что сейчас очевидно ничего не дозаписать независимо от переразбивок) если где-то всего 1 sata разъём и надо всё на одном устройстве. Это будет не так уж дорого.

Да и иметь ТБ диск без резервирования на второй это полная глупость - либо получается на нём ненужные данные - отформатируй его и будет место, либо постоянный риск потерять целый ТБ чего-то важного.

Да ну… Приспичит чуть места у системы забрать и хомяку отдать – и начинаются пляски секс секс с плясками эротические танцы стриптиз похабный: «можно ли переразбить диск, почти полностью занятый данными?»

И тут решение элементарное и единственно верное: воткнуть новый диск. Если у тебя закончилось место - надо его добавлять, а не заниматься вот этой всей фигнёй.

Система обычно занимает меньше 10% (а то и 1%) от общего объёма накопителей, что ты там у неё выкроишь? И зачем? Ты ж в начале выделил ей это место - значит нужно. Или от балды выделил 1ТБ под систему и 100ГБ home? Ну тут уже мало что поможет.

98,5 %

Архиваторами не пробовал пользоваться?

В OpenBSD это используется для безопасности. Во-первых чтобы переполнение /var/log, например, никак не влияло на другие разделы. Во-вторых чтобы монтировать разные точки монтирования с разными параметрами (ro, noexec и тд). В линуксе второе вряд ли применимо, что-нибудь, да поломается.

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

1. маленькая и быстро пройдёт fsck если что
2. мало меняется, а значит fsck возможно и не понадобится из-за read-only либо успешно прочитанного журнала (на активно записывающихся разделах с журналом бывали накладки), и т.д.

Смонтировать home и его аналоги в read-only, всё запустить и уже потом, не торопясь, делать fsck home и вообще что угодно, что потребуется для восстановления. А если на компе есть несколько малозависимых, на тяжёлых для файловой системы задач - лучше и их в разные разделы разнести, по тем же причинам.

Про своп в файле - вроде раньше были проблемы с хибернейтом. Впрочем я точно не знаю. Вроде сейчас должно работать.

Это просто непрозрачно. Раздел это просто место на физическом диске, от такого и до такого сектора. Файл это штука, спрятанная за кучей логики (драйвер файловой системы + дисковый кеш, пусть даже и полуотключённый для свапфайла), причём эта логика может зависеть от системы управления памятью, которой в свою очередь нужен свап. Даже если это всё работает сейчас - тут всё равно куча потенциальных точек отказа, нельзя так на рабоей системе делать.

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

не даёт нормально и прозрачно изолировать друг от друга разделы.

Это как это? Очередной конь в вакууме назревает?

Это, должно быть, шутка?

Спасибо, что не 146%

в случае ext2/3/4 можно освободить 5%, по умолчанию зарезервированное под системные нужды, командой

tune2fs -m 0 /dev/sda

/sda как пример, см. df -h

Можно в оперативку скопировать временно

Казалось бы, что может пойти не так.

Все может пойти не так, как и всегда, ничего нового.

Можно наверное, но готового решения не знаю

но готового решения не знаю

Что значит «не знаю»? Все знают и молчат! Удаляешь некоторые раздачи, пока не освободится 10%. Изменяешь разделы. После этого снова закачиваешь удалённые раздачи.

Надо читать сообщение полностью а не вырывать фразу из контекста. Выше было разъяснено (для свапа): раздел имеет чётко указанные начальный и конечный сектора, и для любой работы с разделом достаточно посекторного доступа к физическому диску (либо RAID(не 0)-массиву из некольких одинаковых физических дисков) + знания этих двух чисел. Любые усложнения тут излишни.