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

swap в файле

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

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

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

Сам интересовался этим и спрашивал разрабов на #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.

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

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

Из того, что выше, на первый взгляд создается впечатление, что наоборот, старый добрый раздел swap всем лучше, чем swapfile на btrfs.

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

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

swap в файле

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

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

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

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

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

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

Разве своп на Btrfs работает?

Да, если COW отключить.

Увидело свет ядро Linux 5.0

Для Btrfs реализована полноценная поддержка swap-файлов, а также изменение FSID без перезаписи метаданных.

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

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

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

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

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

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

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

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

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

но я бы всё равно постарался сделать свопфайл не слишком фрагментированным

он вообще не должен быть фрагментированным

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

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

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

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

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

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

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

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

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

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

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

Только 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

dementy@RocksteR:~$ crontab -l

no crontab for dementy

dementy@RocksteR:~$ sudo crontab -l

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

no crontab for root

dementy@RocksteR:~$ 

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

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

$ cat /sys/power/state
freeze mem disk

Только 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.

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

При гибернации ядро в первый сектор пишет список смещений (физических, на диске) всех фрагментов

Вот это поворот. Окей, ладно, я недооценил линукс :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/dev/sdxx none swap sw

Используй zram для свопа. Это быстрое.

Из того, что выше, на первый взгляд создается впечатление, что наоборот, старый добрый раздел swap всем лучше, чем swapfile на btrfs.

Так и есть, и это касается любой ФС. Но иногда бывает, что swap понадобился, а раздела нет. И тогда приходится использовать swap в файле, а под ним получается ФС, которая вносит дополнительные проблемы. И эти проблемы разработчики теперь и этой ФС постарались если не убрать, то посильно минимизировать. Смысл именно в этом, а не в том, что «меняйте раздел на файл».

что теперь решено, что сон на диск не нужен.

Это кем решено!?

zram также складирует сжатое в рам. проблему ограничения ресурса оно таки не полностью решает.

интересно гибернация в зрам блокируется ?? :)

zram для свопа. Это быстрое.

Это, насколько могу судить по множеству прочитанного на форуме, у кого как. Опять же, у всех свои нюансы в определении слова «быстрее».

Пробовал zram и zswap. Да, тот момент, когда все же начнет использоваться диск, приходит позже. Но зато и гораздо туже. Даже, фиг там «туже» - происходит вот то вставание колом, о котором тут столько разговоров.

zram также складирует сжатое в рам. проблему ограничения ресурса оно таки не полностью решает.

Ну, оно и не может решить это. RAM все же не резиновая. А вот раздел для свопа в наше время можно сделать очень большим.

И вот именно, что сжатое. Как я теперь понял, у swap свое, особое сжатие. Получается, что сжатое в zram приходится распаковывать перед тем, как записывать в swap со своповским сжатием, так? А куда его распаковывать, если RAM занята? Вот, может от того у меня клинило при использовании zram и zswap, а после отказа от этих двоих клинить «волшебно» перестало. А лично меня перестало пугать ожидание момента свопинга. Я теперь этого момента просто не замечаю, если специально не подглядываю.

Теперь у меня еще один прикол остался. Когда и памяти свободной мало, и в swap несколько гигов уже подложено. Вот тогда, если попытаться запустить что-то прожорливое, только живительный Alt+SysRq+F. Причем, Alt+SysRq+F прибивает одну вкладку в Chromium, и вот то прожорливое запускается. Интересно, что после этого прибитую вкладку можно перегрузить, и всё нормально рассаживается в оперативке и свопе. Но это, наверное, уже́ другия тема.

Это кем решено!?

В моем случае, похоже, это решили в Canonical Ltd, а KDE и не воспротивились)). Но, как я понял, и в KDE neon можно сделать это руками.

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

да нет, конечно зачем костылить велосипед если все алгоритмы сжимателей давно продуманы и отработаны. как всегда обычное зло пардон нравится мне это название :)
в бубунте 18.04 такие алгоритмы
$ cat /sys/block/zram0/comp_algorithm
[lzo] lz4 lz4hc 842 zstd

zswap кажись как мудрит одновременно используя и zram и место на диске, но надо ставить поиграться. и параллельно их ставить не желательно.

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

надо читнуть https://www.kernel.org/doc/Documentation/blockdev/zram.txt

Вот, что написано в ArchWiki про zswap

Zswap is a kernel feature that provides a compressed RAM cache for swap pages. Pages which would otherwise be swapped out to disk are instead compressed and stored into a memory pool in RAM. Once the pool is full or the RAM is exhausted, the least recently used (LRU) page is decompressed and written to disk, as if it had not been intercepted. After the page has been decompressed into the swap cache, the compressed version in the pool can be freed.

Страницы, сжатые zswap, перед переписыванием на диск распаковываются.

Про то, что происходит при заполнении zram, точно что-то не пойму. Похоже, что пожатое туда будет там сидеть до снятия питания.

Вот и складывается впечатление, что если купить (а не стыбзить из палеонтологического музея) SSD, то эти штуки не нужны. SSD работает достаточно быстро. Возня zswap с перепаковкой, внезапно начинающаяся при таки наступившей нехватке RAM - лишнее. Zram, которое может занять кусок оперативки давно не нужными страницами - тоже. В ноутбуке у меня сейчас 6 GB RAM и 12 GB SWAP. SWAP при нужде можно еще растянуть. Надо, конечно, еще выкинуть плашки 2 и 4 гига, а вкинуть 8 и 8*

А нужны они, если оперативки мало, а диска для swap нет совсем, или есть, но очень медленный. Вот, живой пример ситуации вынужден носить в кармане. 1 гиг оперативки и четыре гига тормозной «внутренней памяти». Без zram оно включиться-то еще может, а вот работать уже нет. *и выкинуть эту дрянь, а купить телефон.