Можно ли поместить ~ / .cache в tmpfs?
files=(*)
mapfile -t prefixes < <(printf "%s\n" "${files[@]%-*}" | sort -u)
for p in "${prefixes[@]}"; do ls -v "$p"* | tail -1; done
name_file-3.txt
some_other_file-2.txt
А затем скопировать их в другой каталог:
for ...; done | xargs cp -t /destination/directory
Похоже, у вас действительно есть проблема
Да, поэтому, если кеш включает базу данных трекера, когда вы "очистите" его, вы просто собираетесь восстановить его заново (после кропотливого сканирования всех ваших файлов). Так что я не думаю, что это отличная идея.
Основная проблема заключается в том, что у вас есть (комбинация) программного обеспечения, записывающего в ограниченную файловую систему, которая не учитывает доступное пространство :(.
Мысли вслух
Я считаю, что Fedora использовала для управления / tmp с помощью tmpreaper, который удаляет старые файлы. Теоретически некоторые разработчики приложений могли ожидать эту модель. На практике люди просто не делают этого с ~ / .cache, поэтому вы, вероятно, столкнетесь с некоторые непроверенные угловые случаи, которые взрывают. Например, я заметил, что ls -l --time = atime ~ / .cache / tracker показывает изрядное количество вариантов, поэтому я боюсь это не гарантирует правильной работы.
Большая часть наиболее важного программного обеспечения будет иметь некоторые настраиваемые ограничения. Но это не лучшее решение, чтобы приходилось настраивать каждое из них индивидуально, выделяя фиксированное количество доступного пространства (или 0) для каждого.
Я думаю, это может быть полезно для просмотра веб-страниц, например, разрешить 100M, чтобы избежать повторной загрузки очень недавно t изображения и код. (На самом деле я подозреваю, что стандартное «автоматическое управление кешем» Firefox не позволит заполнить саму файловую систему).
У вас может быть отдельный tmpfs для нескольких программ из «белого списка» (с использованием символических ссылок для их перенаправления), которые, как вы полагаете, не заполнят его / для которых выделено фиксированное пространство, и позволят другим выйти за пределы места ошибки (и их жестоко вычищает существующая система).
Тезис
Я предлагаю, если вы не можете позволить себе стандартный дисковый кеш, тогда вам нужно перейти на поддержку кеширования только для выбранного программного обеспечения, а затем просто запустить ограничение повреждений для всего остального. «Если» - здесь самое важное слово.
(В качестве альтернативы: если вы используете конкретное программное обеспечение, которое значительно превосходит наиболее распространенное программное обеспечение, то, возможно, вы правы и вам необходимо содержать это конкретное программное обеспечение).
Проведите числа. Ваш SSD действительно в опасности?
Хорошо, если мы говорим о дешевых нетбуках с наименьшим размером eMMC, которые могут запускать Windows, то да, вы в некотором роде облажались. Скорее всего, вам нужно будет контролировать использование дискового пространства , ваше программное обеспечение, ограничивать и отключать себя. tmpfs может быть полезной частью для записи некоторых записей в кеш диска, если вам нужно использовать это неконтролируемое (сочетание?) программного обеспечения. Но вам нужно идентифицировать конкретное программное обеспечение.
Однако для устройств, обычно продаваемых как «SSD» (а не «eMMC»), которые в настоящее время начинаются с 128–256 ГБ, наиболее распространенное программное обеспечение не вызовет никаких проблем. Если вы хотите получить общие гарантии по этому поводу, подкрепленные данными, тестами, надежными источниками и т. Д., Google - ваш друг - там есть масса забавных статей. Лично я хотел иметь возможность контролировать использование, чтобы получить общее представление.Думаю, здесь есть несколько полезных инструментов.
- Я использовал
tune2fs -l / dev / ..., чтобы посмотреть на «Время жизни записи» в данной файловой системе ext4. К сожалению, похоже, что btrfs этого не поддерживает. - В работающей системе вы можете посмотреть
/ sys / block /. Седьмой столбец представляет количество 512-байтовых операций записи в устройство. Я полагаю, вы могли бы регистрировать это через регулярные промежутки времени и в сценарии выключения./ stat sudo atopможет отображать записи на диск для каждого процесса в режиме диска. Например. если вы нажмете «d», отобразится совокупное количество операций записи на процесс с момента загрузки. На несколько секунд он изменится на последний интервал. FIXME по-видимому, есть способ получше, например чтобы продолжать отображать совокупную цифру.
Я запустил сценарий с использованием tune2fs под cron для добавления в файл журнала и заметил что-то вроде записи 1–4 ГБ в день. Это было выше, чем я действительно хотел видеть, но для меня не было проблемой, учитывая номинальный срок службы диска. Он должен прослужить более десяти лет, после чего он перестанет быть гарантийным и потребует замены. Даже если вы не планируете заменять диск до истечения гарантийного срока, расчетный срок службы должен быть консервативным; он не упадет замертво сразу. Тесты показали, что диски могут прослужить во много раз дольше, чем их номинал.
И вы ведь поддерживаете, верно? Вы не полагаетесь на безумное отсутствие аппаратных сбоев, чтобы гарантировать сохранение любых критически важных данных.