Не так давно я писал про установку Elementary OS, и в комментариях зашёл разговор про файловые системы и особенно про SSD. Честно говоря, не думал, что у кого-то это вызывает сомнения, а сейчас даже задумался - что если я и сам всё делаю неправильно? И вот, хочу поделиться своим жизненным опытом, рассказать, как и почему я разбиваю файловую систему на своём SSD, как и что монтирую и почему я выбрал именно такой путь.
Когда-то давным-давно, когда у меня только появилась первая в моей жизни SSD-шка от Samsung, я толком ещё не знал, что с ней делать. Поддержка в ядре была на уровне “так себе”, если вообще была, и большинство людей пользовались fstrim. Про fstrim я тогда вообще не знал, но никаких неудобств мне это не доставляло. Итак, первое, что следует знать: по большому счёту, в “нормальном режиме эксплуатации”, если не забивать SSD всяческим мусором, диск работает без каких-либо проблем по скорости. До тех пор, пока всего за всю его жизнь, на него не запишут X страниц данных, где Х = количеству страниц данных на диске. В общем, если диск забить всего лишь наполовину и не редактировать большие файлы, про SSD можно было бы вообще не париться. Но поскольку проблем это не приносит никаких, то почему бы и не запариться? :-D
Всю сложность работы SSD, наверное, понимают только инженеры, которые их разрабатывают. В конце концов, это и есть единственное предназначение инженера - вникать, как всё должно работать. Но вкратце проблема с SSD заключается в следующем: перезапись ячейки медленнее, чем первая запись. Сначала контроллер будет выбирать для записи файлов те “ячейки”, в которые ещё никогда не осуществлялась запись, но дальше, когда все “ячейки” потеряют девственность, надо будет что-то с этим делать. И тут на помощь приходит TRIM. TRIM позволяет операционной системе “доложить” контроллеру о том, что некоторым ячейкам памяти нужна предварительная очистка: таким образом, операция будет произведена быстро и в фоновом режиме, а за счёт этого нетронутые ячейки будут постоянно. Ну, конечно, чем больше забить диск, тем хуже будет его производительность и тем скорее будет его деградация (на практике лично я ничего подобного не замечал, но мало ли?! Вдруг, например, мы будем качать до посинения торренты на SSD и в итоге будем её убивать?). Именно поэтому у меня 2 SSD общим объёмом 768 GB.
Так вот, самая первая “SSD” в ноутбуке EEE PC 901 у меня появилась в 2008 году, а поддержка TRIM в ядре Linux появилась лишь в 2010 году в экспериментальных ядрах. Это способствовало тому, что у меня и у многих других сформировалось неправильное отношение к поддержке SSD в Linux. На самом-то деле, в 2008 году TRIM и в самих накопителях не было, а значит, его надо было придумать :). Получается, в Linux с поддержкой SSD всё хорошо, ну или по меньшей мере неплохо. Специальная Wiki по моему дистрибутиву рассказывает, что если включать автоматический TRIM для корневого раздела в моём дистрибутиве (ArchLinux), то корневой раздел смонтируется в режиме только для чтения. Это меня категорически не устраивает. Поэтому для выполнения TRIM на корневом разделе я пользуюсь
fstrim -av
Честно говоря, возможно, TRIM вообще не нужен, потому что все нормальные контроллеры “в фоновом режиме” ищут освободившиеся ячейки. Даже самые говённые и дешёвые китайцы уже научились это делать. Некоторые - с потерей производительности, но научились. Но если есть возможность, почему бы его не сделать? Я - делаю раз в неделю.
Есть и одно большое исключение: я использую флаг монтирования discard для раздела /var. Почему я это делаю? Да всё просто. В /var у меня логи и база данных, туда качаются обновления системы, там работает docker. Словом, в тот раздел чаще всего происходит запись, там часто меняются данные, удаляются данные. Делать для него TRIM сам бог велел, и я делаю в автоматическом режиме. Честно говоря, никаких минусов от этого не вижу. Есть ещё опция указать discard=30, а то и discard=600, как советуют в интернетах, но я на неё забил. Пусть лучше у меня будут целостные данные, которые не надо восстанавливать, даже если диск от этого проживёт на недельку поменьше :)
Ожидаю услышать сейчас вопрос “как так - для раздела /var”? Ну, вот так.
Я сейчас у себя стараюсь использовать такую разбивку:
- То, что часто по-русски называют «раздел EFI», а по-умному ESP - EFI System Partition.
- Раздел
/ - Раздел
/home - Раздел
/var - Раздел
/tmpвыполнен наtmpfs - Раздел
/storage- просто место, куда можно сгрузить всякий хлам. Если на моей SSD системе есть HDD, то это будет HDD.
Теперь поясню, почему так.
Корневой раздел в данном случае, это по сути место для установки программ, а также домашний каталог для пользователя root. Всё. В моём случае, правда, это ещё и /usr/local/src (принадлежит моему пользователю, там чаще всего хранятся чужие исходники с github). Когда корневой раздел отдельно от всего остального, минимизируется возможность того, что какой-нибудь mysqld сожрёт всё место на диске, от чего перестанет например работать sshd.
Раздел /home, как нетрудно догадаться, это мой домашний раздел, там находится каталог с моим профилем. Почему отдельным разделом? О, это очень просто :). Раздел зашифрован. Никаких суперсекретов там нет, но в /home лежат рабочие исходники, а работодателей у меня было много (храню проекты за последний год). Грубо говоря, исходники, которые там лежат, стоят дороже ноутбука, и поэтому, если кто-то в поездке и позарится на мой невзрачный тяжёлый ноутбук без яблока, то ему достанется просто пластик+железо+кремний, но не проекты работодателей.
Раздел /var, как уже упоминалось, это рабочий раздел, в который пишут все, кому не лень. В /var/log создаются журналы всех приложений, в /var/lib/mysql лежит, например, MySQL. А в /var/lib/docker - лежат контейнеры Docker. В общем, как-то так.
Теперь о том, почему мне самому такая разбивка не нравится.
Я, наверное, ретроград или типа того. Не использую LVM, а наверное, стоило бы. Поэтому основная моя причина в неправильном планировании размеров разделов. Например, вот я решил, что на SSD в 250GB будет нормальным корневой раздел в 25GB, а потом с этим мучался :). Сейчас на SSD в 512GB у меня корневой раздел в 40GB, но как-то всё равно тесновато из-за большого /usr/local/src. А /usr/local/src появился, потому что не хватает места в /home. А не хватало его потому, что сначала виртуальные машины я там создавал. Потом перенёс их в /storage и сделал симлинки, но потом поставил ещё PhpStorm, который захавал ещё кучу места… В общем, управлять этим всем не очень хорошо. Думаю, с LVM всё бы стало гораздо удобнее. На следующем ноутбуке попробую так и переделать, всё-таки LVM местами крут.
Моё решение не идеально ни с точки зрения безопасности, ни с точки зрения удобства, но его основная задача - сохранить информацию на ноутбуке. Если ко мне в комнату ворвётся вооружённый бандит - он легко получит доступ к исходникам, я сам ему всё скажу и даже расскажу, где что лежит :D Но если мой ноутбук похитят в стране третьего мира с целью наживы (хотя кому он там нужен, толстый, весит 2.5 кило, и без заветного логотипа Apple?), то воспользоваться данными они не смогут. Я конечно понимаю, что очень маленькое количество воришек умеют программировать на Java, C#, Go и Python одновременно и вряд ли оценят мои наработки, но бережёного бог бережёт, как говорится.