Чи дійсно ramfs зберігає дані в пам'яті?

[ps]

Я тут недавно відкрив для себе файлову систему ramfs. До цього створив топік тут і сам собі на нього відповів, але все одно лишаються сумніви, бо фактично не тестував. Чи дійсно дані пишуться в пам'ять? Бо я пишу туди різні логи та інші тимчасовості, з метою продовження терміну життя SSD. Чи це я сам собі таке видумав зайвий клопіт..

Є ще tmpfs, наскільки зрозумів, вона дає трохи ширші можливості: зокрема там є підтримка прав доступу (коли в ramfs я задаю їх кронтабом від рут після ребуту з /etc/fstab)

Може я написав трешачини, але краще опозоритись та спитати чи правильно я розумію та використовую цей тип ФС.

[res2500]

щоб перевірити скільки що займає, я використовую команди top i df -h, бажано для таких FS мати багато оперативної пам'яті, 64 Мб як для мене це мало, тут треба брати аналогічно з swap, ramfs використовує всю  оперативну пам'ять, а tmpfs можна вказати об'єм, і після ліміту, може використати swap, це краще. Ну наприклад, ноут з 8 гіг оперативної, swap займав 400 Мб коли я збирав в портах Iridium браузер, форк Хрома, swap в мене 3,5 Гіг.
 якщо ви збираєте великі проекти swap зараз треба мати не менш 5 гіг, браузер хром це підтверджує і власна практика, якщо у вас 32 гіга оперативної, то можна і 5 гіг виділити на tmpfs, мені говорили що в оперативній пам'яті працює швидше система, чим з swap

[yvs115]

відносно tmpfs ramfs etc. - для зручного використання логокешів зручно використовувати log2ram якщо маєте достатньо ram

Код: [Вибрати]

% df -h
Ф. система      Розм   Вик  Дост Вик% змонтований на
log2ram         4,0G  183M  3,9G   5% /var/log
log2ram         4,0G  1,5G  2,6G  36% /home/yvs/.cache
якщо це десктоп то в ~/.cache богзна скільки всього (в основному певно браузерні кеши)
а на десктопному компі зараз 32g тому віддати нп 4G під логокеші для мене ок

p.s. але ці підходи з кешуванням в пам'яті треба тестити в кожному окремому випадку чи все нормально (нп з log2ram rsync методом у мене деякі трабл були на пару свіжих ос)

[ps]

64 Мб як для мене це мало

то так треба) більше я тому процесу не дам)) до речі не знаю як себе поведе саме ramfs у випадку переповнення, бо з вичитаного саме tmpfs тут перекидає надлишок на swap.

може використати swap

а swap хіба розуміє файлову систему - завжди сприймав його як монолітне звалище для сирої пам'яті...

для зручного використання логокешів зручно використовувати log2ram

о, вельми вдячний за ключ для пошуку - не знав про таку! бо частина системних логів досі смажить ssd, через що мене хронічно давить жаба викручувати дебаги на максимум.

якщо це десктоп то в ~/.cache богзна скільки всього (в основному певно браузерні кеши)

ну взагалі сервер/ssd але для десктопу теж актуально, бо тут в мене hdd і все тупить люто жужить і співає.
особливо останнім часом з FF, дивлюсь згаданий вище I/O htop'a то за голову берусь.

log2ram         4,0G  183M  3,9G   5% /var/log

А як ви змонтували /var/log - може є перевірений рецепт, щоб я не ушатав систему з цією оптимізацією) Це через fstab і якщо так то чи можна приклад того рядка (з опціями монтування)?
Але з іншого боку... толку з логів якщо після ребуту вони зникнуть, хіба що дійсно як для оптимізації швидкості і терміну служби диску. Частково щось перенести в перманент..

[yvs115]

зручно використовувати log2ram

не знав про таку! бо частина системних логів досі смажить ssd, через що мене хронічно давить жаба викручувати дебаги на максимум.

На github сторінці в apt секції https://github.com/azlux/log2ram?tab=readme-ov-file#via-apt-recommended-genericized
і ставити як зазвичай з "apt install log2ram"
З нюансів використання додам що виставляв SIZE=N та LOG_DISK_SIZE=~N/2 в log2ram.conf, якщо система буде повільно завантажуватись спробувати USE_RSYNC=false (хоча синхронізація з rsync має бути швидша, і то (з rsync повільний boot) пофіксять скоріш усього). Ще бажано незалежно від того - systemd-journald прикрутити який також розпухає з часом (нп SystemMaxUse=100M RuntimeMaxFileSize=50M в systemd/journald.conf).

дивлюсь згаданий вище I/O htop

до речі з azlux репо буде і свіжий btop (який виглядає симпатичніше за інші *top)
там ще зручні тулзи є - але в основному звідти у мене був log2ram та свіжий btop

А як ви змонтували /var/log

PATH_DISK="/var/log;/home/yvs/.cache"
в сумі на них у мене SIZE=4G з 32g ram

може є перевірений рецепт, щоб я не ушатав систему з цією оптимізацією

нема - треба перевіряти все у свому use-case

Це через fstab і якщо так то чи можна приклад того рядка (з опціями монтування)?
Але з іншого боку... толку з логів якщо після ребуту вони зникнуть, хіба що дійсно як для оптимізації швидкості і терміну служби диску. Частково щось перенести в перманент..

якщо з apt - то там відповідний сервіс вже є "systemctl enable log2ram" і ребут якщо вперше поставився - бо він рідкоперіодично sync на диск робить як і при boot/shutdown також

p.s. якщо у вас мало ram, і щось навіть свопиться, - то ніякі варіанти з чимось в пам'яті не розглядав би - бо і так памяті мало якщо свопиться

[BeSiDa]

Але з іншого боку... толку з логів якщо після ребуту вони зникнуть, хіба що дійсно як для оптимізації швидкості і терміну служби диску. Частково щось перенести в перманент..

А вам логи потрібні задля якої мети?
Коли то задля "чому воно зависло", то можна й на інший комп через мережу логи скидати (де також вони в пам'яті будуть). А з того на перший.
Чи взагалі вимикати всі і тільки коли треба вмикати.

[yvs115]

Але з іншого боку... толку з логів якщо після ребуту вони зникнуть, хіба що дійсно як для оптимізації швидкості і терміну служби диску. Частково щось перенести в перманент..

А вам логи потрібні задля якої мети?

з log2ram не зникнуть (якщо не crash системи)

Коли то задля "чому воно зависло", то можна й на інший комп через мережу логи скидати (де також вони в пам'яті будуть). А з того на перший.

різні use-case бувають, нп централізований логхаб також буває та відповідними стд засобами організовується, але назад на перший нема сенсу перекидувати.

[BeSiDa]

різні use-case бувають, нп централізований логхаб також буває та відповідними стд засобами організовується, але назад на перший нема сенсу перекидувати.

А коли другий зависне, то де його логи брати? ))
Логи першого на другий, логи другого на перший. І все в пам'яті ))
Ще й по мултікасту "роздаю всій своїй локальній мережі!" бо може там більше двох компів і то змінюється хто онлайн, а хто ні. А "централізований" (царизм), то не український вибір! ))

[yvs115]

різні use-case бувають, нп централізований логхаб також буває та відповідними стд засобами організовується, але назад на перший нема сенсу перекидувати.

А коли другий зависне, то де його логи брати? ))
Логи першого на другий, логи другого на перший. І все в пам'яті ))
Ще й по мултікасту

тож можна простіше сказати, одним словом, - мультіхфілософ безмежно далекий від будь-яких практичних use-case)

[Tamer4]

О, дякую. log2ram працює чудово на старенькому ПК, система перестала смикати диск кожні декілька секунд, але я ~/.cache змонтував через fstab в tmpfs щоб не переписувати його на диск.