내 스크립트를 사용하여 dm-cache 장치를 만들고 있습니다. http://pastebin.com/KTSzL6EA
효과적으로 다음 명령을 실행하고 있습니다.
dmsetup create suse-cache-metadata --table 0 15872 linear /dev/mapper/suse-cache 0
dmsetup create suse-cache-blocks --table 0 125813248 linear /dev/mapper/suse-cache 15872
dmsetup create storagecached --table 0 2930266112 cache /dev/mapper/suse-cache-metadata /dev/mapper/suse-cache-blocks /dev/mapper/storage 512 1 writethrough default 0
dmsetup resume storagecached
1.5TB USB 2.0 HDD 캐싱을 위한 60GB SSD LVM 볼륨. 다음을 사용하여 캐시된 DM 장치를 마운트합니다.
mount -t btrfs -o noatime,autodefrag,compress=lzo,space_cache /dev/mapper/storagecached /mnt/storage
그러나 전혀 작동하지 않는 것 같습니다. 캐시된 장치의 콘텐츠에 액세스할 때마다 외부 HDD가 회전하고 일부 봇이 내 웹 사이트에 액세스할 때마다 캐시되어야 하는 경우에도 꽤 짜증나고 결국 I/O 오류가 발생하는 것을 확인했습니다. 외장형 HDD는 지속적인 스핀 업 및 스핀 다운을 처리할 수 없기 때문에 약 1주일 정도 소요됩니다.
실제로 몇 가지 벤치마크를 수행하기로 결정했으며 dd명령을 사용하여 8GB 파일을 /dev/null에 복사하면 40MB/s만 달성됩니다. 캐시되지 않은 HDD와 동일한 속도입니다. 언제나. 캐시를 삭제한 상태에서 테스트 실행을 수행하고 캐시해야 한다고 생각하는 세 번째 또는 네 번째 읽기를 수행합니다. 캐시에 사용되는 SSD는 루트 파티션에서 92MB/s를 달성합니다. 물론 모든 벤치 후에는 RAM 캐싱 성능에 미치는 영향을 제거하기 위해 Linux RAM 캐시를 삭제했습니다.
저는 실제로 이 스크립트를 2대의 PC에서 사용하고 있는데 둘 다 작동하지 않는 것 같습니다. 연속 쓰기가 쓰기 속도를 높이지는 않는다는 것을 알고 있지만 어쨌든 읽기에 더 관심이 있습니다.
편집하다:
로그를 조사한 결과 dmsetup status캐시 적중률이 매우 낮은 것으로 나타났습니다. btrfs 결함일 수 있나요?
답변1
dm 캐시는 블록을 캐시 장치로 승격시키는 데 시간이 걸립니다. Linux 램 캐시와 달리 기본 dmcache 정책에서는 SSD로 승격하기 위해 특정 데이터에 대해 최소한 몇 번의 읽기가 필요합니다. 일반적으로 10회 이상의 많은 읽기가 필요합니다. 시스템에 비교적 많은 양의 예비 램이 있으면 많은 시간이 걸릴 수 있습니다. dmcache를 "훈련"할 시간입니다. 캐시 크기가 예비 램 용량과 유사하고 자주 사용하는 데이터가 많은 공간을 차지한다면 전혀 제대로 작동하지 않을 수 있습니다.
답변2
설정을 위해 lvmcache(7)를 사용하면 훨씬 더 행복해질 것입니다. 또한 맨페이지는 시작하고 실행하는 데 매우 유용합니다. 최신(커널 4.2 이후) 릴리스에서만 기본적으로 설정되는 쓰기 저장/연속 쓰기 정책과 smq 캐싱 정책에 유의하세요. 또한 이는 RHEL 7.2+ 정도에서는 기본값입니다.
내 강연을 시청하실 수 있습니다:https://www.youtube.com/watch?v=6W_xK5Ks-Lw 또는 슬라이드를 읽어보세요:https://www.linuxdays.cz/2017/video/Adam_Kalisz-SSD_cache_testing.pdf