/var/cache в TMPFS

Ты себе помоги, а не SSD. Я бы порекомендовал сделать еще +8 Гб ZRAM.

это бессмысленно, то что постоянно должно быть в оперативке - оно и так постоянно в оперативке, а ты хочешь забить её ненужной требухой, у меня вот .cache щас 2,7 ГБ весит, нафиг оно надо в оперативке?

тем более что SSD позволяют очень оперативно подгружать данные, будут у тебя миниатюры файлов подгружаться не за 0,5 секунды, а за 0,3 секунды, велика ж разница, ценой нескольких гигов занятой ОЗУ

быстродействие системы увеличивают другими способами, а не вот этим крохоборством

Лучшая помошь, когда не мешают. Не мешай системе. Пример, последний скриншот. Как думаешь, ‘cache’ - это где?

The data must remain valid between invocations of the application and rebooting the system.

Хочу ускорить быстродействие системы

Если есть видеокарта, то можно попробовать использовать её память в качестве swap.

https://wiki.archlinux.org/title/Swap_on_video_RAM

А в целом какие уже ускорялки в системе сделал?

cache если что это не tmp — кеш надо назад на диск перед отключением писать.

И да, памяти до 32ГБ добить бы (а лучше 64).

Системе мешай, просто разбирайся на что это повлияет, набивай шишки.

Если ты беспокоишься о скорости то запихни кеш твоего браузера в RAM. Если лиса, то в about:config отключи disk.cache (ищи в поиске), и увеличь memory.cache хотя бы до 100Мб.

Ещё можно кеш APT запихнуть. Он не сильно важен.

В всю папку в целом плохая идея.

И я согласен с авторами выше. Хочешь такие эксперименты - добавь RAM, потому как OOM Killer может наделать делов.

во-первых это делать не надо (нет смысла), а во-вторых там просто монтируешь в tmpfs без указания размера как /tmp. мне бы было жалко выделять гигабайты памяти под редкоиспользуемое говно. там хранится кеш пакетов и разная хрень

/etc/fstab :
tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
tmpfs /var/log tmpfs size=10M 0 0

Хочу ускорить быстродействие системы

Хорошо.

запихнуть /var/cache в ОЗУ

Незачем.

Ну и как бонус помогу своему ССД.

Я подозреваю, что это нездоровое желание и есть единственный реальный мотив. Возьми DWPD своего SSD, посмотри, сколько пишется в день реально, и забудь об этом навсегда.

Ерунду делаешь.

Если такая паранойя по поводу SSD то добавь в fstab строки монтировать все с noatime и кинь /tmp и /var/tmp в ram.

У меня на домашнем серваке так, действительно шустрее (но у меня 64 GB RAM).

Если совсем паранойя то /var/log тоже в tmpfs, но сразу говорю это ОЧЕНЬ ПЛОХАЯ идея.

Кеши в RAM не надо. Почему? Все наоборот будет медленнее грузится потому что кеши создаются заново (только что проверил специально для тебя)

И еще совет, добавь RAM (минимум 32 гб), в fstab закомментируй swap и потом в корне sudo rm -f swapfile, но если думаешь так делать то ОБЯЗАТЕЛЬНО zswap поставь и выдели на него минимум 8 Гб что избежать сюрпризов.

Этого достаточно и для быстродействия и для «сохранения» SSD.

Хочу ускорить быстродействие системы и запихнуть /var/cache в ОЗУ

Не ускоришь. Скорее замедлишь. Если у тебятам в /var/cache что-то постоянно читается-пишется, то оно и так в дисковом кэше в ОЗУ. Если нет, то просто займёшь оперативу ненужной фигнёй — ту оперативу, которая могла бы как раз использоваться для чего-то полезного, в том числе и обеспечивать кэш, тем самым ускоряя быстродействие системы.

В общем, если у тебя не какой-то очень особый случай, то таким образом ты в лучшем случае не ускоришь быстродействие системы в целом, в худшем — замедлишь.

Ну и как бонус помогу своему ССД.

В этом нет никакого смысла.

У меня сейчас 16 гб ОЗУ (стандарт). Сколько вы порекомендуете выделить?

См. выше. Не надо. Достаточно /tmp в оперативе. У меня ещё ~/.cache — но у меня и оперативы 32 ГБ.

Какие подводные камни могут возникнуть?

/var/cache — это не /tmp, он в целом не предназначен для постоянной очистки. Данные, которые хранятся там, в целом хотелось бы иметь, а не терять между загрузками. Можешь просто посмотреть на содержимое и прикинуть.

ТС видно напутал /var/cache с /.cache домашней директории.

Я сам поместил /.cache в оперативу. Полет нормальный.

А /var/cache действительно не для чистки.

Пы. Сы: если не секрет сколько вы выделили места? Я 5 гигов (32 гб RAM)

Пы. Сы: если не секрет сколько вы выделили места? Я 5 гигов (32 гб RAM)

4 ГБ. Но на практике там всё равно больше 600 МБ не накапливалось никогда.

/tmp ещё есть смысл переносить в оперативку, но вот что угодно из /var... Ну ладно, /var/tmp можно сделать симлинком на /tmp, ничего с системой от этого не случится. Но блин, в /var/cache могут быть пакеты! Ты не ускоришь систему если надо будет по несколько раз перекачивать пакеты.

ИМХО лучше preload какой-нибудь поставь или с vmtouch поиграйся. Но это всё имеет смысл только на жестком диске, любой SSD по производительности эти ухищрения уделает на раз-два.

запихнуть /var/cache в ОЗУ.

Бессмысленно. Больше времени потеряете на бекапе-востановлении в-из ОЗУ.

помогу своему ССД.

Мифы из 2012? Лучше проверьте, что TRIM включен.

Ну не сказать что мифы…

Но в целом, если так подумать, то в мобиле та же память что и SSD. Только как правило менее производительная. Но тоже Flash. И на мобилах никто не кричит про его чип памяти.

Про TRIM верно подмечено. Создайте cron на каждый скажем запуск с командой fstrim -a чаще избыточно. В теории можно дефолтным таймером (в основном во всех дистрах на 1 неделю стоит) но если у вас такого нет то не мучайтесь и лепите cron.

/var/tmp можно сделать симлинком на /tmp

Эм.. Вообще не понимаю ход мыслей. А почему симлинком?

Не проще ли так:

tmpfs /tmp       tmpfs defaults,noatime,mode=1777,size=2G 0 0
tmpfs /var/tmp   tmpfs defaults,noatime,mode=1777,size=1G 0 0
tmpfs /var/log   tmpfs defaults,noatime,mode=0755,size=50M  0 0

P.S: гайд с забугра тут (linuxconfig.org)

И у тебя будут висеть не 1 тмпфс с лимитом в 3,05Гб а 3 с 3-я лимитами. Ненужное усложнение, больше точек отказа, ниже лимиты.

Не проще ли так

Проще systemctl enable tmp.mount, если у тебя оно ещё не по умолчанию. Для /var/tmp и /var/log этотпросто не очень полезный, а то и вредный, совет.

у меня вот .cache щас 2,7 ГБ весит

А зачем столько? Подозреваю,что там по большей части лежат куски посещенных сайтов,оставленные браузером. Чем больше кэш браузера тем больше он тормозит на не слишком быстром компе. После того как я поместил .cache в tmpfs - браузер (vivaldi) стал заметно отзывчивее.

Но тоже Flash.

NAND, если более точно, только в другом формате/интерфейсе.

Только как правило менее производительная

UFS 4.x — до 2900 Мб/с на каждую из двух линий.

И на мобилах никто не кричит про его чип памяти.

Дело не в форм-факторе, потому что на ПК абсолютное большинство пользователей (то есть те, что на Windows и macOS) тоже не парятся по поводу износа SSD (если всё работает как надо, потому что иногда на всех крупных ОС иногда возникают ситуации, когда диски убиваются в хлам за месяцы и даже недели).

Про TRIM верно подмечено.

И это действительно лучший способ помочь SSD :)

в /var/cache могут быть пакеты! Ты не ускоришь систему если надо будет по несколько раз перекачивать пакеты.

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

А чем /var/tmp в RAM вам не угодил?

Я при каждой настройке как серверов так и домашних пк его всегда в RAM монтирую. Уже 7 лет как сисадмин. Ни одного косяка за это время из-за этого.

Про /var/log, если вы хотите себе геморрой с поиском бага в случае если что-то перестанет работать, то отличная идея его заработать! А если вы ставите систему кому-то (например родне) то логи в принципе не нужны. Только надо отключить доступ (пароль) к sudo и root им, нечего там шарится. А для себя я бы этого не делал

Кстати да. .cache хорошая идея в TMPFS (при условии, что достаточно RAM).

А вот /var/cache - плохая. Наоборот будет тормозить при первом запуске после ребута. И не забывайте, что может что-то поломаться из-за этого.

Выше кто-то писал про пакеты в /var/cache. Иногда бывает, что ломается APT если его туда запихнуть.

Поэтому .cache монтируйте, а /var/cache оставьте в покое.

И что? Что может пойти не так? Это же просто запись fstab. Отказа чего? Если откажет монтирование то отвалится не только это, но и SSD тоже.

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

А вот /var/cache - плохая.

Еще раз изучил содержимое и могу сказать что нет там ничего,из-за чего имело бы смысл в RAM перемещать. Так что согласен с вами.

И не забывайте, что может что-то поломаться из-за этого.

Изредка чищу «потерянные» файлы там (и в других местах). Сходу не могу предположить что именно может поломаться от несохранения /var/cache при перезагрузке. Хотя я естественно не абсолютно всеми пакетами дебиана пользовался - может быть что-то и может.

Выше кто-то писал про пакеты в /var/cache. Иногда бывает, что ломается APT

Ни разу не видел чтобы APT ломалось от отсутствия пакета в кэше. Вот если файл битый или недокачаный - тогда да, возможен глюк именно при установке этого пакета. С этой точки зрения лучше вообще отсутствие файла с пакетом чем наличие поврежденного.

Вообще,от этого кэша пакетов значимую пользу видел только одну. Если ставлю дебиан на другой комп то после установки base system можно скопировать кэш пакетов с рабочего компа и тогда при дальнейшей установке качать придется намного меньше(только то что обновилось).

А чем /var/tmp в RAM вам не угодил?

Тем, что его содержимое не должно теряться при перезагрузке.

Ни одного косяка за это время из-за этого.

Приложения мало пользуются этим каталогом, и по тому же стандарту не должны ломаться от удаления файлов оттуда. А я пользовался /var/tmp для своих временных файлов. В прошедшем времени, потому что не стал менять новые умолчания, хоть и не одобряю их — теперь оттуда автоматически удаляются файлы старше 30 дней.

Про /var/log, если вы хотите себе геморрой с поиском бага в случае если что-то перестанет работать,

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

Кстати да. .cache хорошая идея в TMPFS

Там хранятся thumbnails, например. Загрузка десятка тысяч даже готовых превьюшек занимает много времени, а ты предлагаешь их каждый раз с нуля создавать. Там же кэши таких программ, как restic и borg, которые могут в некоторых случаях экономить часы на стандартных операциях.

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

Не знаю, как там в минте, но лично у меня в /var/cache лежат кэш пакетной системы и шрифтов. Качать/перегенерировать такие файлы выглядит неразумно.

Алсо, монтировать пользовательский tmpfs с 16ГиБ оперативки довольно грустно.

Не знаю как у кого но быстрый гуглинг по форуму дал это (linux.org.ru)

Так что вероятнее всего таки можно поломать систему удалив (или очистив) /var/cache

Тем, что его содержимое не должно теряться при перезагрузке.

по тому же стандарту не должны ломаться от удаления файлов оттуда

Вот вы и ответили на вопрос. Как не крути ни один SSD не будет быстрее RAM. Ну и временные файлы на диске - лишний износ. Для временных есть RAM.

На моем втором компе (на базе северной мамки) 256 Гб RAM. И я пихаю в RAM все что возможно (особенно загрузки, для скорости). Так намного шустрее. Плюс в силу специфики моей деятельности я редко что-то сохраняю, только правлю и назад клиенту. И так много много раз. SSD за это спасибо не скажет, поэтому то, что не нужно хранить у меня идёт в RAM.

Отказа чего?

Количества места или числа инодов (которое по умолчанию пропорционально месту). И ещё чем больше мусора в списке монтирования тем больше шансы ошибки и больше твоего времени уходит чтобы прочитать его.

Экономия на спичках.

По поводу надёжности SSD: использую SSD где-то 12 лет. Мой первый ноут с небольшим SSD (256 Гб) использовался мной в хвост и в гриву всё время. Каждый день, без выходных. Несколько лет назад, отдал его ребёнку, тот использует его ещё жёстче. SSD до сих пор живой.

Кроме этого, у меня ещё в нескольких устройствах, ноутах и десктопах, были (есть) SSD - все до сих пор живы.

По поводу скорости: начиная с какого-то момента, разница в скорости становится незаметной. Например, для ускорения прогонов тестов, пытался выносить тестовую БД на RAM disk. Тут же выяснилось, что тесты упираются больше в CPU, чем в I/O, разница в скорости выполнения незначительная, а геморроя больше.

А откуда

десятка тысяч

У меня всего 2500 фото. .cache живёт в RAM, полет нормальный.

По поводу часов это сильное преувеличение. Если вы не юзаете что-то очень специфическое и гонится за скоростью реакции, то это все же хорошая идея.

Не верите - попробуйте сами. Только не забудьте бекап вашего кеша создать.

cd ~

mv .cache .cache.bak

mkdir .cache

И убедитесь что все в норме будет.

Вернуть назад:

cd ~

rm -rf .cache

mv .cache.bak .cache

Вот вы и ответили на вопрос

Не надо манипулировать словами. Содержимое этого каталога не должно удаляться при перезагрузке, это заданное стандартом поведение.

Как не крути ни один SSD не будет быстрее RAM.

В большинстве случаев это не имеет значения.

лишний износ

Износ лишний, когда это WA или баг.

SSD за это спасибо не скажет

Перестань разговаривать с SSD и посмотри DWPD в даташите. Жить станет проще без лишней дрочки.

Забываете что тогда ССД были MLC, а сейчас QLC с умножением записи в стандартном алгоритме кеширования, а ресурс ячеек снизился куда то в район 200-500 циклов.

Содержимое этого каталога не должно удаляться при перезагрузке

Это понятно, но вы путаете две вещи: «не должно» и «нельзя»

Какие проблемы можно получить нарушив это «не должно»? Есть пример? Просто за 7 лет, 0 проблем с этим.

Перестань разговаривать с SSD и посмотри DWPD в даташите

Насколько мне известно, новые SSD пошли в сторону объёма за счёт продолжительности жизни.

И я не говорю что надо «труситься» над SSD. Просто я всегда все временные файлы выношу в RAM. Во первых приватнось, во вторых скорость, в третьих жизнь SSD.

Количества места или числа инодов

Хорошее замечание, но тогда нужен хардлинк :)

Дело в том, что симлинк это тоже файл (файл ссылка) со своим инодом. Просто показывает на другой файл.

У меня всего 2500 фото

Не у всех всего 2500 фото.

По поводу часов это сильное преувеличение

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

Не верите - попробуйте сами.

Мне не надо верить, я прекрасно знаю, что и сколько времени занимает.

Давайте не ссориться. Это же не спор. Я просто делюсь своим опытом

эти программы

Можно пример? Опять же, почти наверняка это что-то специфическое…

Насколько мне известно, новые SSD пошли в сторону объёма за счёт продолжительности жизни.

Ресурс записи TLC остаётся высоким, тем не менее. QLC мало кто покупает для чего-то, кроме WORM, или когда надо просто максимально сэкономить, но тут оно тоже не особо блещет, иногда дороже приличной TLC.

приватнось

Приватность обеспечивается шифрованием. В том числе RAM.

скорость

За исключением всяких in-memory баз данных, это мало где заметно.

жизнь SSD

Ой, всё. Мог просто написать это во всех трёх пунктах, тут многие с пониманием относятся к экономии ресурса SSD.

Можно пример?

В моём комментарии два названия конкретных программ, одной из которых я пользуюсь каждый день. Для экономии ресурса повторю их здесь: borg, restic.

Ресурс записи TLC остаётся высоким, тем не менее. QLC мало кто покупает для чего-то

Настоящую TLC, ещё поискать нужно, надо же проверять что там за чипы памяти на самом деле, сейчас всё QLC, работающая как TLC до некоторого заполнения в лучшем случае)

Загрузка десятка тысяч даже готовых превьюшек

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

Там же кэши таких программ, как restic и borg,

Я выше и написал что вполне может быть необходимость хранения кэшей тех программ которыми лично я никогда не пользовался. От задач зависит.

$XDG_CACHE_HOME

У меня в Дебиане 11 такой переменной вообще нет. Вероятно она образуется при использовании всяких «сред» и «окружений»,а у меня просто icevm

можно поломать систему удалив (или очистив) /var/cache

Удалять там можно файлы. А вот с каталогами надо быть осторожным. Бывает что софт не умеет создать отсутствующий каталог в который сам же хочет писать файлы.

Не у всех всего 2500 фото.

У меня 2700, и это я около года свой «фотосклад» не чистил.

Если удалить кэш, эти программы будут полностью заново считывать включённые в бэкап файлы.

Особенность конкретных программ. Если вы ими пользуетесь то конечно вам удалять кэш нежелатально.

Приватность обеспечивается шифрованием. В том числе RAM.

Шифрование постоянно тратит ресурсы процессора, даже в тех случаях когда это просто домашний комп. Могу понять шифрование диска,но RAM в этом случае явно уже перебор.