소형 RAM 기반 /tmp

/tmp에 16MB만 사용하면 일부 소프트웨어에 문제가 발생할 수 있습니까?

예, 일부 소프트웨어에서 쓰기를 원 /tmp하고 해당 소프트웨어나 다른 소프트웨어가 이미 파티션을 채운 경우 가능합니다. 일반적으로 이는 잘못된 시스템 구성, 사용 가능한 리소스에 대한 합법적인 제한 또는 다른 소프트웨어의 오작동을 나타낼 수 있습니다. 어떤 경우에도 작성하려는 소프트웨어가 자체적으로 솔루션을 찾으려고 시도할 가능성이 낮으며 오류가 발생합니다.

일부 소프트웨어는 대용량 파일을 작성할 수 있다고 가정하며 /tmp공정하게 말하면 이는 공정한 가정입니다. 이 문제는 "부적절한 구성" 오류 범주에 속합니다.

스스로에게 물어봐야 할 첫 번째 질문은 "RAM을 사용하면 어떤 이점이 있습니까 /tmp?"입니다. 가장 확실한 것은 다음과 같습니다.잠재적인장점은 RAM에 액세스하는 것이 디스크에 액세스하는 것보다 훨씬 빠르다는 것입니다. 그러나 이러한 명백한 잠재적 이점은 다음과 같은 이유로 실제로는 그다지 크지 않을 것입니다.

• 그럼에도 불구하고 시스템은 자주 액세스하는 파일을 RAM에 캐시합니다. /tmp캐시를 넣기 위해 이 캐시에 사용할 수 있는 RAM의 양을 줄이는 것은 약간 어리석은 일입니다. 왜냐하면 자주 사용되지 않는 파일이 /tmp캐시에서 일반적으로 사용되는 파일을 대체한다는 의미이기 때문입니다.

• 응용 프로그램은 이미 RAM에 항목을 자유롭게 저장할 수 있으며, 이는 파일에 저장하는 것보다 더 쉬운 경우가 많습니다. 따라서 항목을 tmp 파일에 넣으면 RAM의 이점을 누릴 가능성이 거의 없습니다. 실제 콘텐츠를 살펴보면 /tmp아마도 대부분 소켓과 FIFO이거나 약간의 IPC 데이터일 것입니다. RAM 기반 파일 시스템을 통해 액세스하는 것이 개념적으로는 더 깔끔하지만 실제로 차이가 있을지는 의문입니다.

이 경우 /tmpRAM에 구현하는 이유는 무엇입니까?

1. 이는 기본 속성의 구현을 단순화합니다 /tmp. 즉, 종료 시 삭제됩니다.

2. 하드웨어의 마모를 약간 줄일 수 있습니다. 이는 저장용으로 저렴하고 수명이 제한된 플래시 메모리만 있거나 쓰기 가능한 저장소가 전혀 없는 환경(예: 임베디드 시스템)에서 더욱 중요합니다.

3. 오용되지 않는다고 가정하면 /tmpRAM을 사용하면 현대 하드웨어의 막대한 메모리 용량을 활용할 수 있습니다. 즉, RAM에 있어야 할 내용이 있을 수도 있습니다.

16MB할 수 있다그것만으로도 충분하지만 프로세스가 제어할 수 없는 경우에는 문제가 되지 않으며 /tmp누구든지 쓸 수 있어야 합니다. 그러나 프로세스에 쓰는 동안 패닉이 /tmp발생하거나 하드 드라이브가 가득 차거나 RAM 파티션이 소진되어 위험 신호가 더 빨리 발생한다면 더 좋지 않을까요 ?

사용 중인 소프트웨어에 자신이 있는 경우 후자가 더 적합하므로 RAM 파티셔닝을 선택할 수 있습니다. /tmp비정상적인 상황(예: )이 발생할 경우를 대비하여 먼저 실제 사용량을 확인해야 합니다 du -h /tmp. "정상 임계값"을 설정하고 cron 작업을 사용하여 해당 임계값을 확인하여 임계값이 초과되면 누군가에게 경고하거나 긴급 정리를 수행할 수 있습니다.

불행하게도 일부 응용 프로그램은 /tmp갑자기 오류가 발생하는 경우 삭제되지 않은 일부 콘텐츠를 가끔 덤프할 수 있지만 서버(자주 종료되지 않음)에서는 이 콘텐츠가 무기한 남아 있을 수 있습니다. 누군가가 로그인하여 무언가를 사용하고 연결이 임의로 닫히거나 중단되는 경우와 같이 이는 매우 무해하게 발생할 수 있다고 생각합니다.

따라서 RAM이 아닌 것이 /tmp더 안전합니다. 남용은 오랫동안 눈에 띄지 않을 수 있지만 이는 RAM만큼 심각하지 않기 때문입니다. 또한 문제가 발생하는 경우 디스크에 문제의 원인을 가리키는 확실한 증거가 있습니다.