разметка дисковой системы на рабочей станции

Нужен ли swap ?

Да. На HDD. Скорость свапу не нужна.

есть ли смысл выносить boot на отдельный раздел?

Только, если загрузчик не поддерживает ФС на /.

Как ПРАВИЛЬНО

/ - на ssd, отдельный /home не нужен, HDD монтируй туда, где надо хранить файлы с твоего выхлопа.

Этот херню пишет.

И свап файлом, а не разделом.

Размечай на lvm, потом переделаешь если что.

Конечно, мне до админа локалхоста далеко. 😉

мне до админа локалхоста далеко.

Как дорастёшь, так перестанешь свап держать на ssd, а /home на hdd.

/ и /home - на ssd, но в /home держи только профиль пользователя (дотфайлы и вот это вот всё), файлопомойку вынеси на hdd и монтируй куда удобно (я монтирую в /media)

На ssd накати Btrfs со сжатием lzo, опции монтирования следующие:

noatime,ssd,compress=lzo,max_inline=256

На HDD. Скорость свапу не нужна.

Отличный совет, ведь фризы из-за свопинга это так круто.

фризы из-за свопинга это так круто.

Свап не для того, чтобы его вместо оперативки юзать.
Если так происходит, то проблема точно, не с местом расположения свапа. И свап на ssd эту проблему не решит.

Свап не для того, чтобы его вместо оперативки юзать

Очень глубокая мысль. Только своп юзается, вот и всё. И когда он юзается, желательно чтобы это было без тормозов.

И свап на ssd эту проблему не решит.

А опыт показывает обратное. Например, когда у меня своп лежал на hdd, запуск тяжёлой игры приводит к мёртвому фризу системы минут на 10. С переносом свопа на ssd это прекратилось и теперь самое неприятное что происходит при запуске этой игры - музыка заикается.

запуск тяжёлой игры приводит к мёртвому фризу

*приводил

Спасибо... Швейк бессмертен! «Первый одно присоветует, второй - другое. А потом как поётся в нашем гимне - „Путь открыт к успехам!“» Но меня терзают смутные сомнения, что при попытке поставить swap на ssd и hdd одновременно испытаю приступ шизофрении. :)

Поэтому внесу некоторую ясность и задам новые вопросы. Извините, но один дурак может задать их больше, чем сто мудрецов их разрешить.

Машинка старая, поэтому только BIOS.

Уважаемый alexferman, поясните пожалуйста, следующие моменты:

1. в чём профит от Btrfs на ssd. Никогда этой ФС не пользовался. Читал только, что она уже в линуксе depricated. Это так? И тогда «ждут котёнка Гава во дворе неприятности»?

2. >/ и /home - на ssd, но в /home держи только профиль пользователя (дотфайлы и вот это вот всё), файлопомойку вынеси на hdd и монтируй куда удобно

Эту идеологию понимаю, да. Но я лох в линуксе. Поясните, как это выполнить практически. При установке системы с нуля делаю и / и /home на ssd. Кстати, если уж беттерфс, то на оба раздела? Как потом устроить файлопомойку на hdd, чтобы у юзеров из большие файлы данных писались именно на hdd.

в чём профит от Btrfs на ssd

Более производительная на многопоточной загрузке, прозрачное сжатие искаропки (у меня апдейты на Btrfs+lzo накатывались ощутимо быстрее, чем на Ext4), можно юзать снапшоты, динамическое выделение инодов (а не как на Ext4, где они могут кончиться при наличии свободного места), можно делать btrfs send хоть на удалённый хост - офигенная тема для бэкапов.

Читал только, что она уже в линуксе depricated. Это так?

Нет.

Как потом устроить файлопомойку на hdd, чтобы у юзеров из большие файлы данных писались именно на hdd.

Например, монтировать hdd в /media/data, создать каталоги /media/data/USER_1, /media/data/USER_2 и т.д. Дальше смотри файлы /etc/xdg/user-dirs.defaults и ~/.config/user-dirs.conf, там сообразишь.

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

В какую папку идет выхлоп в нее и монтируй hdd. Зачем эти /media всякие.

А кто тебя допустил вообще? О-О

Компьютер используется для моделирования задач электродинамики, рентгеновской оптики, томографии. Возникли вопросы по разбивке дисков, которых в системе 2. ssd 256 Gb+ hdd 1.0 TB. Интернеты эти ваши курил, но там рекомендации весьма противоречивые.

в чём профит от Btrfs на ssd. Никогда этой ФС не пользовался. Читал только, что она уже в линуксе depricated. Это так?

Её выкинули из ынтерпрайзных RHEL/CentOS. Причина:

To paraphrase the upstream opinion, btrfs has been «almost production ready» for many years now, but never quite got to the stage where it actually was ready.

И тогда «ждут котёнка Гава во дворе неприятности»?

Ну судя по ЛОРу, с btrfs довольно много неприятностей. Так что на компе, где что-то там связано с медициной, и который используют сотрудники разного уровня компьютерной подготовки, я бы посоветовал смотреть в сторону более стабильных ФС. Всё-таки не домашний компьютер.

force compress рекомендуют

Только своп юзается, вот и всё.

Чем юзается, дебил? Тебе в оп написано, что их проге не нужен своп, падает out of mem.

Очевидно, у Вас большой опыт использования Btrfs. И как оно в смысле надёжности при длительном (> года) использовании?

Пользовались ли снапшотами для бэкапа/восстановления системы? М.б. тогда особого смысла пользоваться clonezilla для создания образов/ восстановления из них уже и нет от слова совсем?

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

Причина в том, что у red hat политические и деловые тёрки с oracle, которая и стоит за btrfs, а какие якобы технические причины они притянули - неважно

Я бы очень хотел, чтобы мне админ систему настроил, а я только бы свои задачи запускал и смотрел, что получилось. Но таковых в радиусе 100 км не наблюдается.

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

Ключевое слово «пользовался». А почему перестали?

Так что на компе, где что-то там связано с медициной

Не понял, а причём тут медицина?

Перешёл на ext4, потому что подумал «а вдруг станет ещё быстрее грузиться и обновляться?». Стало медленнее, но возвращать всё обратно мне уже лень, тем более что на Manjaro необходимость в снапшотах отпала. Но сжатия не хватает, да.

Дык вроде же можно из ext4 мигрировать на Btrfs. Не?

в радиусе 100 км

Так вы в 100 км под землёй? В колайдере каком-то?

Можно, но лучше накатывать с нуля

Моё мнение – если данные представляют хотя бы минимальную ценность для владельца, то btrfs на рабочей станции противопоказан.

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

а какие якобы технические причины они притянули - неважно

Важно или неважно, но для production ready эта btrfs пока ещё не готова, да и для user-использования видимо тоже так себе, учитывая постоянный вой на ЛОРе «помогите восстановить» из-за внезапной потери питания.

Моё мнение – если данные представляют хотя бы минимальную ценность для владельца, то btrfs на рабочей станции противопоказан.

Моё мнение: если данные представляют хотя бы минимальную ценность, то они должны дублироваться и бэкапиться как минимум в пару мест, и на эфемерную надёжность файловой системы тут вообще плевать, ибо делегировать всё одной сущности и молиться на её устойчивость это какой-то даунизм. И потому от ФС требуются несколько другие качества, в том числе и простота дублирования/бэкапов, тут btrfs snapshot и btrfs send рулят.

Так вы в 100 км под землёй?

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

А самые интересные для нас программы - они под линукс. Так что надо ездить именно на нём.

У технарей (а я именно технарь) есть поговорка: всё, что может сломаться, обязательно сломается. Всё, что сломаться не может, всё равно сломается.

В общем понял. берешь, используешь asis, на свой страх и риск. Но в линуксе же всё так. И я не говорю, что меня не предупреждали. Предупреждали, я принял к сведению.

Моё мнение – если данные представляют хотя бы минимальную ценность для владельца, то btrfs на рабочей станции противопоказан

Если данные представляют хотя бы минимальную ценность, то кроме Btrfs/ZFS вариантов нет. Остальные поделки с радостью похерят твои данные во имя консистентности метаданных.

Поэтому лучше используйте проверенную годами файловую систему, ext4, например.

Только учтите, если у вас в работе будет создаваться много файлов, то в случае ext* файловых систем вы можете столкнуться с ограничением количества inodes, это служебные блоки, которые служат для хранения информации о файлах и количество этих блоков зависит от размера файловой системы, чем она меньше - тем меньше блоков.

Ну и backup`ы важной информации в любом случае не забывайте делать.

Если выберешь ext4, то монтируй её с такими опциями:

noatime,journal_checksum

Но только если проц умеет аппаратно crc32, иначе тормозить будет (наверное)

Вариант «production ready fs + regular backups» надёжнее варианта «meh brtfs + regular backups».

production ready fs

Мне эти баззворды неинтересны, я магическим мышлением не страдаю.

Правильно, поэтому нужно учитывать суммарный опыт использования. И у btrfs тут позиции довольно слабы в плане надёжности.

поэтому нужно учитывать суммарный опыт использования

Статистику в студию, поизучаем. Что-нибудь уровня Backblaze.

Статистику в студию, поизучаем.

Читай @ изучай. Подшивку ЛОРовских тредов по одноимённым тегам тоже не забудь.

Что-нибудь уровня Backblaze.

Что-то ты слишком много хочешь. Для этого нужно, чтобы btrfs была интересна компаниям, подобным Backblaze. Ибо сейчас ситуация:

Storing Shards

Each of the drives in a Vault has a standard Linux file system, ext4, on it. This is where the shards are stored. There are fancier file systems out there, but we don’t need them for Vaults. All that is needed is a way to write files to disk, and read them back. Ext4 is good at handling power failure on a single drive cleanly, without losing any files. It’s also good at storing lots of files on a single drive, and providing efficient access to them.
(c) https://www.backblaze.com/blog/vault-cloud-storage-architecture/

Читай @ изучай. Подшивку ЛОРовских тредов по одноимённым тегам тоже не забудь.

Ты предлагаешь мне читать десятки вариаций тех же самых попугайских штампов аля «продакшен рэди» и историй успеха эникейщиков типа «я нажала и у меня всё сломалось»?

Что-то ты слишком много хочешь

Просить нормальную статистическую базу = хотеть слишком многого, ок.

Ещё минус ext4 – когда в одном каталоге создаётся (и уничтожается) большое количество файлов.

Тормоза ext4

И таких тредов на лоре немало.

Можно несколько swap сделать с разными приоритетами.

btrfs наоборот - эксперементальный. Почти везде. Только suse, вроде, стабилизирует для своего платного дистрибутива.

noatime

strictatime, lazytime

Что-то слишком много:

историй успеха эникейщиков типа «я нажала и у меня всё сломалось»

Для ФС, которая не очень-то популярна.

Просить нормальную статистическую базу = хотеть слишком многого, ок.

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

А пока она так и остаётся нестабильной и статистики не будет.

Если ты обслуживаешь ряд серверов - то вперёд используй на них btrfs и собирай статистику. Только про backup`ы не забудь.

Раз в квартал - ни разу не много