LINUX.ORG.RU

Failed to suspend system. System resumed again: No space left on device

 , , , ,


0

1

Привет!

Периодически и раньше возникала проблема, но сейчас вдруг стало чаще. Не засыпает система, пишет, якобы no space left on device.

swap 4 гигабайта, оперативка 16. Казалось бы, мало - но занято то всего около 1-2 гигабайт на момент «засыпания», должно хватать (да и сжиматься данные должны, если верить документации). Расширять до 16 (или больше) гигабайт жалко, SSD, более полезное применение найду (в идеале бы и 4 гигабайта сделать «динамическим временным удаляемым файлом на системном разделе»).

dmesg:

[383378.172143] PM: Using 3 thread(s) for compression
[383378.172145] PM: Compressing and saving image data (1445303 pages)...
[383378.172159] PM: Image saving progress:   0%
[383379.249826] PM: Image saving progress:  10%
[383380.380664] PM: Image saving progress:  20%
[383381.312427] PM: Image saving progress:  30%
[383382.223197] PM: Image saving progress:  40%
[383383.148374] PM: Image saving progress:  50%
[383384.010527] PM: Image saving progress:  60%
[383385.131115] PM: Image saving progress:  70%
[383386.506543] PM: Image saving progress:  80%
[383387.550700] PM: Wrote 5781212 kbytes in 9.37 seconds (616.99 MB/s)
[383387.772529] PM: Basic memory bitmaps freed
[383387.772530] OOM killer enabled.
[383387.772531] Restarting tasks ... done.
[383387.794876] PM: hibernation exit
[383387.794994] elogind-daemon[4390]: Failed to suspend system. System resumed again: No space left on device
[383387.796692] elogind-daemon[4390]: Error during inhibitor-delayed operation (already returned success to client): No space left on device
$ free -m
              total        used        free      shared  buff/cache   available
Mem:          15835         956        9918         749        4960       13954
Swap:          4095           0        4095

На системном разделе (/, /var, /tmp) места тоже норм, с запасом, менее 50% занято. df -i тоже подозрительного не показывает (менее 30% на /var).

Куда ещё смотреть?

$ uname -a
Linux thinkpad-x230.local 5.3.9-gentoo #1 SMP Sat Nov 9 12:27:52 GMT 2019 x86_64 Intel(R) Core(TM) i5-3230M CPU @ 

openrc-0.41.2, elogind-241.3, pm-utils-1.4.1-r7

★★★★★

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

занято то всего около 1-2 гигабайт на момент «засыпания», должно хватать

Наивный.

Записывается практически вся активная память, включая кеши и буфера, и еще хер знает что. При этом даже сброс кешей echo 3 > /proc/sys/vm/drop_caches не помогает в уменьшении размера записываемых данных, как будто дропнутые кеши еще в активной памяти. При этом система все равно тормозит после пробуждения, как после дропа кешей. В общем, магия.

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

Записывается практически вся активная память, включая кеши и буфера, и еще хер знает что.

Ну вот лично у меня система с 32Гб успешно засыпала на 8Гб раздел. Так что, очевидно, не все кэши пишутся в своп.

Khnazile ★★★★★
()

Во-первых, не suspend, а гибернация.

Во-вторых, для гибернации в общем случае размер свопа должен быть >= размеру RAM.

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

Ну вот лично у меня система с 32Гб успешно засыпала на 8Гб раздел. Так что, очевидно, не все кэши пишутся в своп.

Еще раз. Не абсолютно вся память, а вся используемая память. Для интереса посмотри размер кешей/буфера до засыпания и после пробуждения. Откуда он материализуется сразу после пробуждения?

И еще.

Размер образа можно узнать cat /sys/power/image_size, обычно около 1/3 от всей памяти, можно изменить.

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

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

Чёрт. И как я эту цифру не увидел… Понять бы теперь, откуда столько много.

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

Выходит, мне с моим вопросом на https://bugzilla.kernel.org/ надо?.. только чувствую, пошлют, скажут, «так и задумано».

Оно в целом понятно - «очистка неиспользуемой памяти» перед засыпанием может плохо повлиять и на скорость засыпания, и на производительность. Но с другой стороны, 2 гигабайта «усыпить» в три раза быстрее, чем 6, так что как раз наоборот. Необязательно именно «проводить очистку», а просто сохранить используемые страницы памяти.

К сожалению, я ненастолько хорошо разбираюсь в коде ядра (это же ядро?), чтобы понять, как оно изнутри работает и сделать заплатку…

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

Понятно, во всём виноват ktorrent. Но вырубание его тоже не помогает, так как кеш после не очищается, видимо.

BattleCoder ★★★★★
() автор топика
Ответ на: комментарий от anonymous
If you want to limit the suspend image size to N bytes, do::

        echo N > /sys/power/image_size

before suspend (it is limited to around 2/5 of available RAM by default).

Ага, теперь понятно, откуда там такой размер. И понятно, что 16 гигабайт точно будет излишним, достаточно всего лишь 6.5.

BattleCoder ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.