Читай всё и делай свои выводы. На блюдечке то, что надо именно тебе, никто не принесёт. Единственное, что не подлежит сомнениям, это то, что хорошо разделить разную информацию по разным разделам по принципу «тут постоянно пишется, это на один раздел; тут никогда не пишется, это на другой раздел». Ещё может играть количество файлов, принадлежность файлов (например, отдельный раздел для данных СУБД) и т.п.
/sys/power/image_size controls the size of the image created by the suspend-to-disk mechanism. It can be written a string representing a non-negative integer that will be used as an upper limit of the image size, in bytes. The suspend-to-disk mechanism will do its best to ensure the image size will not exceed that number. However, if this turns out to be impossible, it will try to suspend anyway using the smallest image possible. In particular, if «0» is written to this file, the suspend image will be as small as possible.
Reading from this file will display the current image size limit, which is set to 2/5 of available RAM by default.
«For more modern systems (>1GB), your swap space should be at a minimum minimum be equal to your physical memory (RAM) size „if you use hibernation“, otherwise you need a minimum of round(sqrt(RAM)) and a maximum of twice the amount of RAM. The only downside to having more swap space than you will actually use, is the disk space you will be reserving for it. »https://help.ubuntu.com/community/SwapFaq
В принципе конечно можно уходить и с меньшим swap, но это не рекомендуется. На ArchWiki по этому поводу написано: Even if your swap partition is smaller than RAM, you still have a big chance of hibernating successfully.
От себя могу добавить, что мой MSI X320 категорически не хотел спать с маленьким swap'ом, но после его доведения до размера RAM проблема исчезла сама собой.
Ооо, нет)) Слушай, я не утверждаю, что большой swap принципиально необходим. Просто ссылки, которые я привел, и личный опыт наводят на мысль, что лучше бы он был больше; тогда проблем будет меньше. А так да. Наверное там было что-то неправильно настроено.
Лол, как будто без LVM, XFS или EXT4 кто-то не позволяет.
ну без LVM увеличение разделов (не последнего раздела) доставляет дикую боль, так что да, не позволяет. с btrfs и zfs ситуация меняется, но я не в курсе пользуется ли ими хоть кто-то кому есть чем заняться кроме как пробовать новые fs.
Расскажи пожалуйста, сколько по времени займет увеличение раздела с 500 ГБ до 600 ГБ, находящегося в начале 2 ТБ диска, за которым есть один раздел на 1 ТБ, на сколько для этого придется остановить всю деятельность и сколько ручных операций придется для этого сделать. Если для тебя это норма - ок, у тебя высокий болевой порог и для тебя лично это не боль.
А если я хочу много данных качать себе с интернета, а у меня в Home не такуш много места будет?
Фильмы музыку и т.д и что бы всё работало очень хорошо и что бы багов не было и у меня пока без SSD, как мне разбить 2ТБ, а потом я думаю взять SSD на 180GB
Как мне тогда всё разметить?
SSD под систему, Хомяк - монопенисуально, файлопомойку как и советовали отдельным разделом.
По личному опыту могу сказать - вообще всё разбивается в автоматическом режиме. По поводу файлопомойки и хомяка не комплексую, ибо бакаплюсь, а кое-чего чотбы точно было - в облако. Правда привычку бэкапиться вырабатывал долго, как и не жопиться на второй винт для бэкапов. Но когда «всё пропало» - вырабатал сразу.
ну сделай два мановения мышью в gparted, раз у тебя такой болевой порог.
на сколько для этого придется остановить всю деятельность
2015й год на дворе, сколько 100ГБ копируются, столько и будет.
Если для тебя это норма
разделы увеличивать? нет. у меня, быть может, FS меньше, чем носителей. это фанаты LVM создают себе много разделов, потом мучаютс с ними да LVM нахваливают.
Ты сначала в live cd загрузись, а то без него / не особо подвинешь, ну и перемещать ты будешь минимум терабайт в моём примере, а если внезапно пропадает свет - ты будешь плакать очень громко
Ну и физических разделов у меня ровно столько сколько носителей, а ФС столько сколько мне нужно, а не столько сколько было сделано пять лет назад при установке системы
размести / первым разделом и двигать его никуда не надо будет. а лучше вообще единственным.
Жизнь такова, что вчера он был первым, а через пару лет оказывается последним. А про возможность иметь несколько инсталляций одновременно я вообще молчу
врешь ведь
И где у тебя сдвиг второго раздела, чудик? Или ты решил что терабайт данных никому не нужен?
Жизнь такова, что вчера он был первым, а через пару лет оказывается последним. А про возможность иметь несколько инсталляций одновременно я вообще молчу
Ну а тогда уже и live-cd не нужен. Point not valid, next!
И где у тебя сдвиг второго раздела, чудик?
Нет. Как и втjрого раздела. Это тестовый лог того, как один единственный забитый под завязку раздел был сдвинут назад наращиванием назад и сокращением размера. Это наглядно подрывает твои доисторические взгляды на перемещение разделов. Мне жаль, что ты неправ, но ты бы хотя бы почитал бы да разобрался. Next!
Ну а тогда уже и live-cd не нужен. Point not valid, next!
ты не допускаешь возможности что две системы было в прошлом а сейчас одна? OKAY
Нет. Как и втjрого раздела. Это тестовый лог того, как один единственный забитый под завязку раздел был сдвинут назад наращиванием назад и сокращением размера. Это наглядно подрывает твои доисторические взгляды на перемещение разделов. Мне жаль, что ты неправ, но ты бы хотя бы почитал бы да разобрался. Next!
ну ок, в случае некоторых fs на разделе может быть меньше 1 ТБ, но в моем примере никаких fs не было указано, так что в общем случае будет тот же 1 ТБ.
Корень - 50Gb - определено эмпирически. swap - количество оперативки + 0.5G. Обоснование размера - туда можно hibernate делать, потому лчуше не делать его меньше оперативки. home - осталное.
Если тебе понадобится что-то более сложное, ты об этом сам будешь знать.