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

Я ещё делаю /mem на tmpfs для всякого временного дерьма, которое скачивает браузер и т.п.
Ты вообще поменьше слушай ЛОРовцев. Здоровее будешь.
Сейчас тебе расскажут про /boot /tmp и прочие ужасы маразма.
Про готовый рейзерФС и про то, что у солярки есть то, о чём мечтает БСДя.
Бойся ЛОРа, маразм приносящего!

да не, я БСДел в рогах и копытах давно, уже 10 лет назад. на ПК-роутере, вместо сервера...

и уже не помню что и как размечал, но в виду ограниченности ресурсов.. там было 2 харда, а бэкапился я на вин-сервер. там было поболее жестких дисков.

А теперь вот разобрало любопытство, как сейчас всё держать stupid simple, а не наворачивать горы блотварного шлака.

Раньше зачем-то выделял /home (так надо же, говорят), теперь один /

Ну и /boot в FAT32, для ядра (чтобы загружать в efi)

Для мультибута отдельный /boot актуален.

Для мультибута

Не, понятно, что для необычных конфигураций приходится иногда городить необычные костыли. Но это ведь не повод советовать такое другим.

LVM минималка гигов на 10 под /, так как не подвигать тазом онлайн, все пишущие приложения, /var, swap раскидать на одноимённые тома LVM, всё остальное место свободное. Для рабочей станции ещё /home отдельным томом, если нужно.

Десктоп:

SSD: / в ext4

RAID1 из двух HDD: /home в ext4

ещё один HDD: /var/cache/pacman в ext4 + раздел под файлопомойку (то что разбирать и в основном удалять) в xfs + раздел под файлопомоку для (то что лежит, удалять не нужно, но легко востановимо, так что на RAID смысла нет тащить) в xfs

А систему ты как переставляшь?

(Вангую: «линукс штабилен, у меня аптайм 7 лет.»)

2015

Посмотри, какой год на дворе!

GO GET A LIFE

Я ещё делаю /mem на tmpfs для всякого временного дерьма, которое скачивает браузер и т.п.

Почему просто не складывать это в /tmp?

зобаннего ктулху

О, а я и не заметил. То то в толксах стало чисто и свежо.

2015?

«каждый чертов носитель» - btrfs

а она точно готова для десктопа?

нет, не точно.

Вангую, что как хочет, так и переустанавливает, а потом разворачивает из бэкапа нужное подмножество содержимого /home. У нас тут 21 век, уже есть куда бэкапиться.

У меня /home отдельно, но переустанавливать пока не тянет. С другой стороны он стоит всего 6 лет, а не 7.

на десктопе сейчас уже совершенно все равно как разбивать с точки зрения производительности или надежности

на сервере обычно / и /var отдельно

Ну там и так страшный срач. Туда же пишут все кому не лень. Как потом там что-то найти?

у меня и для дома и для сервера разметка такая:

/dev/sda1 /boot EFI-раздел размером 512мб, точнее, помечен fdisk'ом как EFI, но все мы знаем, что это fat32. для ядра размером 10мб это с избытком, поэтому используется оно у меня как и любой другой раздел для всякой всячины. там может лежать всякий временный мусор %) кстати ноутбук уже старенький и UEFI не поддерживает, но раздел всё равно помечен как EFI, это лишь формальность, а таблица разделов MBR. загрузчик lilo.

/dev/sda2 SWAP размером 512мб, вспомогательный своп, а то бывает люблю поставить обновляться систему, заодно ядро пересобирать и смотреть котиков на ютубе в этот момент. лишь однажды в жизни мне нехватило 4гб памяти, с тех пор использую резервный своп на 512мб.

/dev/sda3 собсна линукс, корневая система, fdisk'ом выделяю резеревные +10GB, но затем установив систему выполняю

# e2fsck -f /dev/sda3 ; resize2fs -Mp /dev/sda3

эти волшебные команды урезают ext4-раздел до возможного минимума, сейчас у меня /dev/sda3 раздел размером 757мб, я уже удалил /usr/share/man страницы, документацию /usr/share/vim/doc, и хочу чтобы этот раздел целиком умещался на cd-r диск. думаю. чего-бы ещё удалить...

только когда места уже будет нехватать, тогда возьму fdisk, пересоздам раздел чуть большего размера, выполню resize2fs /dev/sda3 и раздел увеличится до указанного fdisk'ом.

и да, согласен, lvm не нужен. =)

а дальше у меня идут расширенные логические разделы.

/dev/sda4, если таблица разделов MBR, то понятно, это Extended раздел, а если таблица разделов GPT, то /dev/sda4 размером 2048 секторов просто висит без дела как резервный, чтобы не ломать всю структуру. система легко переносится с винта на винт. потому что когда возникает необходимость перенести систему с GPT раздела на MBR, ибо железка другого не умеет, то важно сохранить позицию каждого раздела.

а вот далее следует всякий трэш )

/dev/sda5 для /home 50гб, /dev/sda6 для /srv 50гб

/dev/sda7 не используется пока-что, зарезервировано.

/dev/sda8 это ещё один swap, который выполняет роль гиберанции, размером 4гб по количеству оперативной памяти. в опциях загрузки ядра указана опция resume=/dev/sda8, — ядро знает, где надо спать =)

/dev/sda9 на весь оставшийся винт, выполнять роль мусорной корзины. тут у меня и /usr/src, и /usr/ports примонтированы для сборки и обновления системы. и просто всякие файлики, торренты качаются сюда.

кроме первого efi-раздела с fat32, в остальных случаях везде файловая система ext4 без настроек и тюнинга, просто дефолтная mke2fs -t ext4 /dev/sda*.

и да, опять же повторюсь, lvm пока небыло возможности/необходимости ковырять, ext4 прекрасно ресайзится — можно и увеличить, и уменьшить через resize2fs, главное заранее зарезервировать fdisk'ом разделы.

кстати, делюсь рецептом. когда надо систему перенести, лучше всего не извращаться никакими tar, rsync'ами, а переносить весь раздел с системой целиком. используя dd.

но бывает так, что система занимает всего 5гб на диске, разделом выделено 50гб, а флешка у нас всего на 8гб.

вариант а) остановить все службы, в частности syslogd, чтобы ничто не дёргало жёсткий диск, затем монтировать корневой раздел в «только чтение» mount -o remount,ro /.

вариант б) загрузиться в live-систему и не мучиться.

выполнить команды чтобы уменьшить файловую систему до минимума

# e2fsck -f /dev/sda3

# resize2fs -Mp /dev/sda3

по завершению resize2fs сообщит количество блоков по 4096 байт, сколько находится в файловой системе. берём это число и считаем echo $((число * 4096 / 1024 / 1024))

файловая система уменьшилась, но раздел по прежнему большой, для этого надо fdisk'ом переразметить его. когда fdisk спросит, какого размера создать раздел, указываем получившееся в результате вычислений число.

затем выполняем снова

# e2fsck -f /dev/sda3

если e2fsck будет ругаться на сломанную систему — не пугайтесь, просто остановите выполнение Ctrl + C, пересоздайте fdisk'ом чуть больший раздел и снова проверьте e2fsck — он должен выполниться в конце концов без ошибок, сообщить что файловая система впорядке.

теперь весь этот раздел уменьшинного размера при помощи dd if=/dev/sda3 of=/dev/sdb можно тупо перенести на флешку.

а потом с этой флешки записать обратно на другое железо, или просто хранить как бэкап. =)

такие пироги.

reiserfs, 1 диск == 1 раздел.

своп

Зачем? У тебя 512МБ оперативки?

ах да, источник: опыт. только что пять минут назад игрался с разделом: сломать его не удалось, система работает, сам раздел из 10гб сделал размером всего в 757мб, записал на флешку и перенёс на другой ноутбук.

поэтому пока ещё «горячо», пишу такие огромные посты, делясь опытом. %)

/ — ext4, SSD
swap — 8GB, HDD (не знаю зачем он нужен, но мне не жалко)
/boot — ext2, HDD
/home — ext4, HDD
А ещё есть 100 гигов неразмеченного места на HDD, которые я не знаю куда приспособить.

кстати ещё к слову о GPT vs MBR, UEFI vs LILO.

до тех пор, пока в наличии нет жёсткого диска на 2тб, — не вижу причин переходить на использование GPT и загружаться с UEFI.

для минималистичной системы lilo всем прекрасен, у него всего одна зависимость libdevmapper, а efibootmgr попросит efivars, popt, и вам спецом надо держать dosfstools, опционально elilo (лол!).

ящитаю, что неправильно говорить «вот мы перешли на uefi и наконец избавились от лишней прослойки сущности — загрузчика», да нифига мы не избавились, а вместо одного компатного lilo приходится держать несколько штук других пакетов. и не забывать включать efistub в ядре linux, если хотим грузиться без elilo (лол!).

слава богу, хоть fdisk умеет в gpt разметку, gdisk и уж тем более ужасный parted нафиг не нужны.

в общем, единственная киллер-фича gpt — использование дисков более 2тб, которых к сожалению, пока ещё нет в виде ssd и редко встречаются на десктопах.

киллер-фич у uefi нет вообще. туева хуча пакетов всё равно нужна. раньше достаточного было lilo.

ну а если вы не ставите целью иметь компактную систему, то вам наверное всё равно. =)

/ + swap === profit ? А еще было бы лучше только / и свапфаил как на макос и шиндошс, потому что отдельным разделом на диске нахрен не нужен.

в былое время «файл подкачки» pagefile.sys лежал на диске цэ.

в линуксах тоже ничего не мешает создать такой файл

dd if=/dev/zero of=/home/username/pagefile.sys bs=1MB count=512

mkswap /home/username/pagefile.sys

swapon /home/username/pagefile.sys

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

С:\

# lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
|-sda3   8:3    0   640M  0 part /

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       502M  446M   12M  98% /

640 мегабайт хватит всем. а меньше уже некуда, увы. если говорить фактически, 446мб занимает на диске дистрибутив CRUX.

удалил /usr/share/man и /usr/share/vim/doc, что ещё нинужного посоветуете удалить?

/ - 120 GB SSD

/media - 2 Tb HDD

Раздел фиксированное место занимает, а размер файла может варьироваться в зависимости от потребности, не нужен фаил подкачки - весит 0 байт, нужно какой то программе дополнительное место - стал весить 50/100/(сколько_там_нужно) мб, а то и вообще туда все неактивные висящие в фоне скидывать, да чтоб у каждого отдельный фаил. Помоему как то примерно так в мак ос и сделано и все данные спасаются при аварийном выключении.

/boot - ext4
/boot/efi - fat32
/ - ext4 (LVM)
/home - ext4 (LVM)
swap - swap (LVM)

кстати, делюсь рецептом. когда надо систему перенести, лучше всего не извращаться никакими tar ... blablablablabla...

слишком длинный метод.

если e2fsck будет ругаться на сломанную систему — не пугайтесь

это вобще хрень. такие вещи должны быть простые.

Обычный способ: Разбить новый диск и просто сделать tar -cf / tar -xf, chroot, сменить uuid девайсов и grub-install. Все.

Вобще тред скучный. Хоть бы кто сказал, что lvm cache на SSD использует.

Хоть бы кто сказал, что lvm cache на SSD использует.

а ты используешь? расскажи же. =)

я ничего не знаю об lvm и было бы интересно послушать историю успеха.

серверов у меня нет, но чисто теоретически
ссд - / ехт4

если это сервер, то нужно размещать на SSD часто загружаемые данные или использовать его под кеш. программы на сервере стартуют не часто.

и делать просто образы диска любой коммерческой утилитой, а может и какой бакулой.

lvm snapshot удобнее

/srv + /home - raid

raid везде, в т.ч. на SSD

железный или чипсетный + что-то похожее на ZFS, вместо ФС,

т.е. подсознательно не связываюсь с LVM... // меня уволили? или для ЧП-рога-корыта сойдет?

если у тебя просто один диск испорится - то это ни для кого не помеха. а если скажем питание дернут и у одного из дисков механика откажет, у второго пойдет рассинхронизация метаданных, потому что когда выключили питание метаданные были в кеше, то ты можешь оказаться в плохой ситуации. поэтому иногда использование hardware raid с flash или bbu оправдано. LVM в этом случае лучше, чем zfs поверх hardware raid.

Я уже отрепетировал использование LVM cache для кеширования больших жестяков и вот как раз собираюсь попробовать дома. Так что может скоро будет такая история.

С LVM история успеха в том, что он очень стабилен и он делает свою работу. Как-то я на ходу (на запущенном сервере) поменял поочереди все диски.

Снапшоты - отличное средство для [горячего] бекапа.

Как я понимаю, в LVM есть все функции работы с блоками, как в zfs/btrfs. Эти функции не интегрированы со всем остальным - их можно гибче использовать, меньше ограничений с чем можно комбинировать, хотя перфоменс может быть ниже за счет отстуствия единого менеджмента.

сделать tar -cf / tar -xf

в этом кстати моя неприязнь к tar и rsync, в файловых системах существуют расширенные аттрибуты, которые до недавнего момента tar не сохранял, решается даже неофициальным патчем и во многих дистрибутивах оный отсутствует.

# find / -type f \( -perm -4000 -o -perm -2000 \) -print

поэтому пока для меня ещё перенос системы — тёмный лес, я не могу доверять ничему, кроме физического копирования раздела с помощью dd.

если уж на то пошло, то vfs в linux - это такое наслоение технологий. реализовано все что можно, а как этим пользоваться консистентно не понятно. unix permissions, extended attributes, acls, selinux... просто каша. Твоя неприязнь к конкретным тулзам - это камень не в тот огород. Проще как раз игнорировать exattr и использовать линукс с примитивными permissions, чем выжимать из него что-то еще.

если dd, то lvm snapshot - твой друг.

«линукс штабилен, у меня аптайм 7 лет.»

Именно так, а если что-то не так, в первую очередь удаляется мусор ".*" (всякие .kde4/, .config/) из /home, после чего система опять как новая.

ну ты ламер :-) сломается у тебя система, так что проще переустановить чем починить - ты свой /home с данными на терабайт тоже удалишь? xDD

имхо надо так:

/boot - 1000Мб (не 300, потому что а вдруг на этот же диск придется ставить Шиндовс, она на мелкий диск может отказаться создавать системные файлы)
/swap - 1Гб (даже если 128 гигов рамы, ибо линукс такой линукс)
/ - не менее 50Гб
/home - не менее 50Гб - тактическая инфа
/data - все остальные терабайты - стратегическая инфа

темп в раму. Но надо помнить, что если много рамы (скажем 64 гига уже актуально) - надо зарезервировать ведру 10 гигабайт под себя лично, иначе просядет на нагрузке.

плюс важно разделение между SSD и HDD. Такие вещи как кэш IntelliJ IDEA и git нужно класть на SSD. Если есть несколько SSD желательно git положить на отдельный чтобы там не лежало ничего кроме него (замусоривает файловую систему, когда начало тормозить - можно форматнуть SSD и склонировать проекты заново). То же самое под кэши JBoss/Wildfly и прочих серверов, делающих темповые директории из миллионов мелких файлов общим объемом в гигабайты - файлуха с них вешается.

плюс важно разметить отдельные физические (логические) диски под виртуальные машины, т.к. файловые жесткие диски жутко тормозные. И не в коем случае не класть такие диски в рейды, они должны быть строго последовательными.

сломается у тебя система, так что проще переустановить чем починить - ты свой /home с данными на терабайт тоже удалишь?

Почему просто не удалить все папки, кроме /home, зачем обязательно удалять/форматировать?

Оно только в рамках одного VG работает? Если харды в одном VG, а SSD в другом, то получится такой cache прикрутить?

нормальные пацаны все хранят на внешнем nas с рейдом, а у тебя детский сад и дешевые понты :)

да, нужно в одной vg. вот вчера разбирался что делать, если ssd уже отдан в другую vg. собираюсь сделать shutdown, vgsplit (отщепить группу или две) и потом уже для каждого hdd vg делать кеши.