BTRFS 풀에서 함께 실행되는 여러 디스크가 있는 파일 서버가 있고 캐싱을 위해 SSD를 추가하고 싶습니다. 나는 주로 속도를 추구하는 것이 아니라 하드 드라이브를 대부분의 시간 동안 많이 사용하지 않을 때 종료할 수 있도록 정기적인 소규모 액세스를 캡처하고 싶습니다(연중무휴 24시간 실행하지 않으면 에너지가 절약되고 디스크가 더 오래 지속됩니다).
내가 아는 한, 현재 Linux에는 dm-cache와 bcache라는 두 가지 SSD 캐싱 기술이 구현되어 있습니다. dm-cache는 여전히 더 효율적이라고 알려져 있지만 두 가지 모두 개발이 진행 중이므로 절대적인 최대 효율성을 위해 조정할 필요는 없습니다.
읽다bcache에 대한 문서, 다음 옵션을 생각했습니다.
쓰기 저장 대기 시간: 더티 데이터가 캐시에 기록되고 이전에 더티 데이터가 포함되지 않은 경우 쓰기 저장을 시작하기 전에 특정 시간 동안 기다립니다. 기본값은 30입니다.
다시 쓰기 비율: 0이 아닌 경우 bcache는 백그라운드 쓰기 저장을 제한하고 PD 컨트롤러를 사용하여 속도를 원활하게 조정하여 캐시 더티 비율을 유지하려고 합니다.
다시 쓰기 실행: 끄면 더티 데이터에 대한 쓰기 저장이 전혀 발생하지 않습니다. 캐시가 본질적으로 가득 찰 때까지 더티 데이터는 계속해서 캐시에 추가되며 벤치마킹 목적으로만 사용됩니다. 기본값은 켜져 있습니다.
충분히 큰 값을 설정하면 writeback_delay
작업이 수행되는 것 같습니다. 한 시간에 한 번만 다시 쓰기만 하거나 (이런 일이 발생한다고 가정합니다) 캐시가 가득 찬 경우입니다.
이게 합리적인 설정인가요? 디스크 속도를 성공적으로 낮추기 위해 다른 방법을 고려해 보셨나요?내 요구 사항을 충족한다면 완전히 다른 경로로 갈 수도 있습니다.
@gorkypl인 것 같습니다.비슷한 문제에 대한 다른 해결책을 찾고 있습니다., 하지만 요구 사항과 상황이 달라서 답변을 받지 못했습니다.
답변1
접근 방식이 너무 복잡하다고 생각합니다.
캐시 읽기: 여기서 할게 없어. 메모리가 충분하면 Linux에서 이 작업이 자동으로 수행됩니다.
캐시 쓰기기본적으로 이것은 당신이 원하는 것입니다. 그러나 쓰기가 디스크에 기록되면 웨이크업도 발생합니다.
따라서 영향을 받는 파일 시스템을 ram-disk /dev/shm 또는 ssd에 직접 배치할 수 있습니다.
절전: 속도를 자주 줄이거나 늘리는 것이 배터리를 절약할 것이라고는 생각하지 않습니다. 반대로 디스크가 더 일찍 고장나면 생산 과정에서 추가 에너지 소비가 발생할 수 있습니다. 그리고 회전하는데 많은 힘이 소모됩니다.