제가 이 디렉토리에 대해 걱정하는 ~/.cache이유는 두 가지입니다. SSD에 불필요한 쓰기가 많이 발생하고, 암호화된 컨테이너와 외부 드라이브에 있는 파일에 대한 정보(예: 이미지 썸네일)가 포함되어 있기 때문입니다.
tmpfs에 넣고 fstab. 꽉 찰 때까지 문제 없이 실행됩니다. 이로 인해 일부 프로그램에서는 오류 메시지가 발생합니다.
나는 파일이 .cache지속되어서는 안 된다고 생각합니다( tmpfs 와 유사 /tmp). 이것이 바로 제가 tmpfs를 사용하는 이유입니다. 그래서 crontmpfs가 가득 차면 매 시간마다 정리하기 위해 실행되는 스크립트를 작성했습니다 ..cache
tracker그러나 이로 인해 해당 데이터베이스를 찾을 수 없다는 오류 메시지가 나타납니다 .
이로 인해 이 디렉토리가 실제로 지속되어서는 안 되는 것인지 궁금합니다. 에 넣는 것이 좋은 생각입니까 tmpfs?
답변1
너한테 문제가 있는 것 같구나.
예, 따라서 캐시에 추적기 데이터베이스가 포함된 경우 이를 "정리"하면 다시 재구축됩니다(모든 파일을 힘들게 스캔한 후). 그래서 나는 그것이 아니라고 생각한다.엄청난아이디어.
근본적인 문제는 여유 공간을 관찰하지 않는 제한된 파일 시스템에 소프트웨어를 쓰는 (결합된) 소프트웨어가 있다는 것입니다.
당신의 생각을 소리내어 말해보세요
나는 Fedora가 /tmp오래된 파일을 삭제하는 tmpreaper를 사용하여 관리되곤 했다고 생각합니다. 이론적으로 일부 애플리케이션 개발자는 이 모델을 예상했을 수도 있습니다. 실제로 사람들은 ~/.cache에 대해 이 작업을 수행하지 않으므로 다음과 같은 결과가 발생할 수 있습니다.일부테스트되지 않은 극단은 폭발할 수 있습니다. 예를 들어, 이것이 ls -l --time=atime ~/.cache/tracker꽤 많은 변화를 보인다는 것을 알았기 때문에 이것이 잘 작동한다고 보장할 수는 없을까 걱정됩니다.
가장 중요한 소프트웨어에는 대부분 구성 가능한 제한이 있습니다. 그러나 이것은 그다지 좋은 해결책이 아닙니다. 각 공간을 개별적으로 구성해야 하며 각 공간에 고정된 여유 공간(또는 0)을 제공해야 합니다.
예를 들어 최근 이미지와 코드를 다시 다운로드하지 않도록 100M을 허용하는 등 웹 검색에 유용할 수 있다고 생각합니다. (나는 실제로 Firefox의 기본 "자동 캐시 관리"가 파일 시스템 자체를 채우는 것을 방지한다고 의심합니다).
채워지지 않거나 고정된 공간이 할당되어 있다고 믿는 일부 "화이트리스트" 소프트웨어(심볼릭 링크를 사용하여 리디렉션)에 대해 별도의 tmpfs를 가질 수 있으며, 다른 소프트웨어에서 공간 부족 오류가 발생하게 할 수도 있습니다. 기존 시스템).
종이
표준 디스크 캐싱을 감당할 수 없다면 선택한 소프트웨어에 대해서만 캐싱을 지원하도록 변경하고 다른 모든 소프트웨어에는 손상 제한을 실행해야 한다고 제안합니다. 여기서 중요한 단어는 "만약"입니다.
(또는: 사용하는 특정 소프트웨어가 가장 일반적인 소프트웨어보다 작성 능력이 훨씬 더 뛰어나다면 아마도 귀하의 말이 맞을 것이며 해당 특정 소프트웨어를 포함해야 할 것입니다).
숫자를 실행합니다. SSD가 정말 위험에 처해 있나요?
글쎄요, Windows를 실행할 수 있는 최소한의 eMMC를 갖춘 저가형 넷북에 대해 이야기하고 있다면 그렇습니다. 디스크를 모니터링하고 싶을 수도 있습니다공간소프트웨어를 사용하고 자신을 제한하고 비활성화하십시오. 이런 종류의 런어웨이(조합?) 소프트웨어를 사용해야 하는 경우 tmpfs는 디스크 캐시에 일부 쓰기를 포함하는 데 유용한 부분일 수 있습니다. 하지만 특정 소프트웨어를 식별해야 합니다.
그러나 일반적으로 "eMMC"가 아닌 "SSD"(현재 128-256GiB로 시작)로 판매되는 장치의 경우 가장 일반적인 소프트웨어는 전혀 문제를 일으키지 않습니다. 데이터, 테스트, 신뢰할 수 있는 소스 등이 뒷받침된다는 일반적인 확신을 원한다면 Google이 여러분의 친구입니다. 흥미로운 기사가 많이 있습니다. 개인적으로 저는 사용량을 모니터링하여 전체적인 그림을 얻을 수 있었으면 좋겠습니다. 여기에 유용한 도구가 있다고 생각합니다.
- 나는
tune2fs -l /dev/...주어진 ext4 파일 시스템에서 "평생 쓰기"를 살펴본 적이 있습니다. 불행히도 btrfs는 이것을 지원하지 않는 것 같습니다. - 실행 중인 시스템에서는
/sys/block/<dev>/stat512바이트가 장치에 기록된 횟수를 나타내는 일곱 번째 열을 볼 수 있습니다. 주기적으로 종료 스크립트에 이를 기록할 수 있을 것 같습니다. sudo atop프로세스당 디스크 쓰기는 디스크 모드에서 표시될 수 있습니다. 예를 들어 "d"를 누르면 시작 이후 각 프로세스에 대한 누적 쓰기가 표시됩니다. 몇 초 후에 마지막 간격을 표시하도록 변경됩니다. 문제가 생겼어계속해서 누적 숫자를 표시하는 등 더 나은 방법이 있을 것입니다.
cron에서 une2fs를 사용하여 스크립트를 실행하여 로그 파일에 추가하고 하루에 1-4GB의 쓰기를 관찰했습니다. 제가 정말 보고 싶은 것보다 높지만 드라이브의 정격 쓰기 수명을 고려하면 나에게는 문제가 되지 않습니다. 10년 이상 지속되어야 하며, 그 시점이 지나면 보증이 만료되어 어쨌든 교체해야 합니다. 보증 기간이 만료되기 전에 드라이브를 교체할 계획이 없더라도 수명 등급은 보수적으로 유지되어야 합니다. 테스트 결과 드라이브는 정격보다 몇 배 더 오래 지속되는 것으로 나타났습니다.
백업하셨죠? 중요한 데이터의 생존을 보장하기 위해 하드웨어 오류가 전혀 발생하지 않을 것이라는 점에 의존할 필요는 없습니다.