수년 전에 나는 감당할 수 없을 정도로 디스크 공간을 모두 채우는 응용 프로그램을 가지고 있었습니다. 이로 인해 일종의 데이터베이스(대체로 말하면)를 유지 관리하는 시스템 프로세스가 쓰기에 실패하고 해당 데이터베이스가 손상됩니다. 나는 이런 상황을 피하고 싶다.
ext2/3/4를 사용하면 권한 있는 프로세스의 쓰기를 방지하기 위해 정확히 이 목적에 -m맞는 옵션 mke2fs("syslogd(8)과 같은 루트 소유 데몬 허용)"을 사용하여 일정 비율의 디스크 공간을 수퍼유저용으로 예약할 수 있습니다. 시스템이 아닌 파일에 저장").
그러나 나는 스냅샷 기능 때문에 ext2/3/4보다 btrfs를 선호하지만 btrfs에는 그러한 옵션이 없습니다. 디스크 할당량이 있지만 이로 인해 스냅샷 성능 문제가 발생하는 경향이 있으며 신뢰할 수 없는 것으로 나타났습니다.
또 다른 아이디어는 사용자가 쓸 수 있는 공간을 위해 별도의 파티션을 갖는 것이지만 , /home및 /tmp( /var/tmp사용자가 쓸 수 있는 위치가 더 있습니까?) 에 대해 별도의 파티션을 갖는 것은 약간 과도한 느낌이 들고 각 파티션은 개별적으로 예측된 사용량보다 많아야 합니다. 약간의 안전 여유, 디스크 공간 낭비.
다른 옵션이 있나요?
답변1
별도의 파티션을 사용하려는 아이디어는 현재 작동하는 유일한 아이디어입니다. 그러나 이것은 실제로 너무 많은 것이 아닙니다. 사람들은 이 목적을 위해 별도의 파티션을 사용해 왔습니다.수십 년작동하기 때문입니다. 몇 가지 일반적인 조언:
/homeBTRFS를 사용하지 않는 경우 별도의 파티션에 있는 것이 많은 배포판의 표준이므로 이미 모든 주요 소프트웨어에서 잘 지원됩니다. 95%의 사용자가 파일의 95%를 여기에 저장하기 때문에 이것이 가장 큰 관심사입니다./tmp실제로 이상적으로는 분할되어서는 안 됩니다.tmpfs자체 크기 제한이 있는 마운트가 되기를 거의 원할 것입니다 . 이는 일반적으로 성능을 향상시키고 디스크 공간 낭비를 방지합니다./tmp대부분의 경우 몇 KB보다 큰 데이터를 거의 저장하지 않기 때문입니다./var/tmpmount 가 되는 것이 더 나을 수도 있습니다tmpfs. 특히 다음과 같은 경우라면 더욱 그렇습니다.위치RAM과 적당한 양의 스왑 공간.- 이 외에도 특정 시스템 구성에 따라 사용자는 스토리지
/var/lib에/var/cache디렉터리 원하는/var/games양/var/lib/games의 데이터를 (직접 또는 간접적으로 ) 쓸 수 있습니다. 예). 개인적으로 저는 , , 및 을 자체 파티션에 넣고 꽉 차기 시작하면 을 넣습니다 . 실제로 사용하는 경우 BTRFS가 최선의 선택이 아닐 수도 있지만 거의 항상 자체 파티션이어야 합니다./var/mail/var/spool/var/www/var/ftp/var/cache/var/spool/var/lib/var/cache/var/mail - 다른 곳도 있을 수 있습니다. 공식적인FHS거의 모든 Linux 배포판에서 사용되는 표준 레이아웃을 나열하고 무엇이 어디로 가는지 언급하므로 흥미로울 수 있습니다.