LINUX.ORG.RU

Swap на разделе VS swap в файле. SSD. BTRFS.

 , ,


0

3

Когда ставил систему, что-то не умело в swap на btrfs, и я сделал раздел для свопа. Ну, оно и работает, причем, после некоторой подстройки, работает нормально, без сильно ощутимых тормозов при свопинге. Думаю, если не знать, когда оно свопает, можно этих тормозов и не заметить.

Но вот на мой любимый Neon 5.16 прилетело пятое ядро. Про него так сказано, будто внезапная возможность работать со swapfile на btrfs - это одно из двух лучших, которые в нем вообще есть (второе - это планировщики I/O.

Вот, интересно услышать мнения, чем так плох раздел swap по стравнению с файлом?

С HDD - еще понятно, есть несколько причин.

А с SSD? SSD же одинаково быстрый (ну, или одинаково медленный) во всех своих местах? И «проедание» свопом одних и тех же ячеек, о котором я где-то видел - это же фигня какая-то? Ячейки же перетасовываются не в пределах разделов?

P.S. Не мог сделать эту тему Файрфоксом. Хромиумом получилось. Итс мЭйджик.

Ответ на: комментарий от eternal_sorrow

Ну, как я понял, туда оно и спит, в swap.

А как точно проверить, что содержимое RAM записывается на диск, а не остается в RAM? Усыпить, отключить питание, вынуть батарею? Пото́м попробовать включить? Если просто проснется, а не станет грузиться - то всё правильно? А если станет грузиться сиситема - то это мне так кажется, что всй правильно, а оно неправильно?

Dementy ()

Сам интересовался этим и спрашивал разрабов на #btrfs. В итоге:

1. Гибернация в своп-файл работает через смещение (запоминание смещения) начала файла в настройках initrd. Нужна опция типа resume_offset=xxx для mkinitcpio.

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

3. В чате разрабы уверяли, что внесли в код проверки, которые не допускают порчу данных. При попытке указать неправильный offset будет ошибка типа «bad device».

4. Специфики ssd для btrfs свап-файла вроде нет.

5. Чтобы получить оффсет, нужно использовать не filefrag, а набор команд (есть в гугле и в арчевики), потому что структура FIENFO в случае btrfs возвращает виртуальный адрес, а не физический на диске.

6. Гибернация в swap файл на btrfs raid невозможна.

7. Советуют swap файл сделать nodatacow и держать на отдельном subvolume.

8. В случае перемещения файла в силу каких-то причин (разрабы написали код, уменьшающий вероятность) нужно будет пересчитать новый offset.

P.S. Мне это не нужно, и я в итоге решил не юзать своп-файл на btrfs.

mxfm ()

Вот, интересно услышать мнения, чем так плох раздел swap по стравнению с файлом?

В случае btrfs ответ выше. В общем случае есть неудобство с offset.

mxfm ()
Ответ на: комментарий от Dementy

Я хотел сказать «информацию о сравнении см. выше». В случае btrfs есть перечисленные проблемы, но они по идее несмертельны. В рассылке btrfs не было случаев порчи данных от гибернации в своп-файл. Если сильно нужна гибернация в своп-файл, то можно юзать. Мне лично это было не нужно.

Своп-файл может быть выгоднее раздела при таком раскладе: все разделы диска имитируются btrfs subvolume - это исключает необходимость использования lvm (минус один посредник при записи на диск). Плюс по какой-то причине swap раздел в GPT нежелателен. Тогда да, если нужна гибернация, то наличие своп-файла - необходимость. Если swap раздел допустим (gpt или lvm) , то не вижу причин морочится с файлом (ну разве что его размер поправить проще).

mxfm ()
Ответ на: комментарий от eternal_sorrow


swap в файле


гибернация работает?

Извиняюсь, не совсем понял с первого раза. У меня раздел swap, со своповской файловой системой. Отдельно от разделов btrfs.

А будет ли работать гибернация в файл - пока не знаю. Потому и советуюсь. Подозрение, что не надо мне пытаться чинить то, что не поломано.

Dementy ()
Ответ на: комментарий от mxfm

Если swap раздел допустим (gpt или lvm) , то не вижу причин морочится с файлом (ну разве что его размер поправить проще).

Вот. А у меня на ssd после /home (которому до заполнения далеко) /swap , а после /swap - неразмеченное пространство. В такой ситуации я вообще не предвижу сложности с изменением размера /swap.

Вот на hdd, когда /swap втиснут между / и /home - вот там да. А в «конце» hdd его делать было плохо, ибо скорость.

Dementy ()
Ответ на: комментарий от eternal_sorrow

А гибернация в файл в линуксе вообще хоть с какой-нибудь ФС работает?

Насколько мне известно, такого ещё нет и никогда не было без адовых хаков.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)

чем так плох раздел swap по стравнению с файлом?

Да в целом уже ничем. ФС используется только для того, чтобы выделить блоки, а дальше ядро работает с ними напрямую.

SSD же одинаково быстрый (ну, или одинаково медленный) во всех своих местах?

Вообще да (да и по сути свопа ввод-вывод в него произвольный), но я бы всё равно постарался сделать свопфайл не слишком фрагментированным.

И «проедание» свопом одних и тех же ячеек, о котором я где-то видел - это же фигня какая-то? Ячейки же перетасовываются не в пределах разделов?

На всех SSD современнее мамонтов — совершенно справедливо. Только TRIM/discard не забудь включить.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

А гибернация в файл в линуксе вообще хоть с какой-нибудь ФС работает?

Работает (файл на ext4). Файл даже не непрерывный.

Судя по тому, что сказано выше, это совсем не рокет сайнс.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 1)
Ответ на: комментарий от greenman

без адовых хаков

Вручную указывать раздел и смещение до файла я считаю адовым хаком.

Файл даже не непрерывный.

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

ИМХО, в ядре есть поддержка чтения фрагментированного файла. На btrfs файлы>700 имеют почти полную вероятность делится как минимум на две части. Но поскольку гибернируют всю работу на диск, то там как минимум 1GB используемой памяти собирается, т. е. должно работать с фрагментированным файлом. Лично не проверял.

mxfm ()
Ответ на: комментарий от intelfx

Значит, достаточно непрерывный для того, чтобы образ поместился в первый фрагмент.

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

AEP ★★★★★ ()
Ответ на: комментарий от intelfx

Только TRIM/discard не забудь включить.

Это я не забыл. Вот так в fstab

UUID=92e34375-fa9c-44a8-8a97-ed7b3c11333d /               btrfs   discard,compress=lzo,defaults,subvol=@ 0       1

UUID=0b48b7d0-ba88-46da-89f0-f8346173efa5 /home           btrfs   discard,compress=lzo,defaults,subvol=@home 0       2

/dev/sda4 none swap discard,sw,pri=10 0 0
Однако, неоднократно видел рассуждения, что в наше время делать триминг при каждом монтировании уже́ немодно, потому что «оно как-то само» ставит задачу в cron тримать с оптимальной периодичностью. Заглянул, а оно вот как↓
dementy@RocksteR:~$ crontab -l

no crontab for dementy

dementy@RocksteR:~$ sudo crontab -l

[sudo] пароль для dementy: 

no crontab for root

dementy@RocksteR:~$ 
Потому и сделал, как сумел.

Dementy ()
Ответ на: комментарий от Dementy

Ну, как я понял, туда оно и спит, в swap.

А вот это я, оказывается, неправильно понял. Спит оно не в своп. Спит оно в RAM на подпитке. Погуглил чуток, как это сделать в KDE neon 15.6 (в Ubuntu 18.04) - пока не нагуглил ничего толкового, кроме инфы, что теперь решено, что сон на диск не нужен. Вообще-то, оно вроде не совсем выкинуто

$ cat /sys/power/state
freeze mem disk
но и не работает.

Dementy ()
Ответ на: комментарий от intelfx

Только TRIM/discard не забудь включить.

*Поспешил я что-то. Оказывается, оно действительно «как-то само», только не кроном, а systemd.

dementy@RocksteR:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Wed 2019-08-14 21:40:13 +04; 29min ago
  Trigger: Mon 2019-08-19 00:00:00 +04; 4 days left
     Docs: man:fstrim

авг 14 21:40:13 RocksteR systemd[1]: Started Discard unused blocks once a week.
Значит, думаю, discard в fstab лучше убрать.

А сто́ит ли сделать compress=lzo и для свопа?

Dementy ()
Ответ на: комментарий от Dementy

«Оно как-то само», действительно, ничего не происходит. Просто в некоторых современных юзер-френдли дистрибутивах это настроено из коробки.

Однако, неоднократно видел рассуждения, что в наше время делать триминг при каждом монтировании уже́ немодно

Значит, думаю, discard в fstab лучше убрать.

mount -o discard против fstrim по расписанию — это почти что холивар, есть много аргументов как за одно, так и за другое.

Я бы советовал fstrim по расписанию делать всегда, а mount -o discard делать либо если твой SSD умеет в queued TRIM, либо если у тебя настолько много дисковой нагрузки, что между запусками fstrim по расписанию суммарное количество записанных данных сравнимо с количеством свободного места на диске.

Со свапом то же самое: при запуске системы swap очищается автоматически, а опцию discard следует использовать в случаях, аналогичных вышеописанным.

intelfx ★★★★★ ()
Ответ на: комментарий от Dementy

не нагуглил ничего толкового, кроме инфы, что теперь решено, что сон на диск не нужен

Ну это как всегда — если в линуксе чего-то нет, значит, это не нужно.

intelfx ★★★★★ ()
Ответ на: комментарий от Dementy

А сто́ит ли сделать compress=lzo и для свопа?

Для swap-файла? Нет. Он не может быть сжатым или использовать copy-on-write. Понятно, почему — ядро работает с блоками в этом файле напрямую, вообще без помощи файловой системы.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

«Оно как-то само», действительно, ничего не происходит. Просто в некоторых современных юзер-френдли дистрибутивах это настроено из коробки.

ИМХО, если нечто действительно хорошее настроено из коробки - это такое доброе колдунство и «оно как-то само» в хорошем смысле.

если в линуксе чего-то нет, значит, это не нужно.

А я вот попытался понять, почему они так в этом конкретном случае поступили. А для юзера в KDE есть управление сеансами. Там можно мышкой пипку поставить «начинать с предыдущего сеанса». Если SSD - это отрабатывает со скоростью, сравнимой с пробуждением из swap. Вот они и могли прикинуть, что если теперь есть такое, то пусть простой человек этим и пользуется. А кто очень хочет - тот пусть и найдет, как вернуть гибернацию.

---------------------------------------

Вобщем, для себя я понял.

Если SSD, не экстремально старый и тесный, то лучше сделать раздел /swap, и при этом не жадничать с размером. И неразмеченное место лучше тоже оставить.

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

Для swap-файла? Нет. Он не может быть сжатым или использовать copy-on-write. Понятно, почему — ядро работает с блоками в этом файле напрямую, вообще без помощи файловой системы.

Для /swap раздела, как понимаю, тем более? строки

/dev/sdxx none swap sw
в fstab хватит для всем и для всего? Ну, естественно, /swap раздел от этого не сделается, его сделать надо:)

Dementy ()