용량을 결합하면서 빠른 스토리지와 느린 스토리지 전반에 걸쳐 다중 계층 파일 시스템을 구성하는 방법은 무엇입니까?

용량을 결합하면서 빠른 스토리지와 느린 스토리지 전반에 걸쳐 다중 계층 파일 시스템을 구성하는 방법은 무엇입니까?

느린 500GB 마그네틱 HDD와 빠른 500GB SSD를 동시에 사용할 수 있는 방법을 찾고 있습니다.

용량 측면에서 두 가지를 합친 합리적인 비율로 끝내고 싶지만(800GB 이상이면 좋겠습니다)어떤 파일이 어떤 디스크에 저장되어야 하는지 결정하는 것은 까다롭고 디렉터리 경계를 넘는 것이 거의 불가능합니다..

다단계 수납 형태에서도 비슷한 것을 고려한 것으로 보인다. 그러나 지금까지 내가 찾은 유일한 메커니즘은 빠른 볼륨을 느린 볼륨의 캐시로 사용하는 것입니다. 500GB HDD 느린 드라이브에서 500GB SSD 캐시로 끝나기 때문에 이것은 나에게 효과가 없습니다. 단순히 느린 HDD에 박싱하고 SSD를 사용하는 것보다 나을 것이 없습니다.

두 개의 볼륨에 걸쳐 있고 한 볼륨에서 다른 볼륨으로 동적으로 복제하는 시스템을 생각해 보십시오. 이는 캐싱과 유사하지만 볼륨을 완전히 일관되게 유지할 필요가 없으며 단일 볼륨보다 더 많은 용량을 제공할 수 있습니다.

지금까지 검색한 내용이 모두 비어 있습니다. 캐싱을 지원하는 LVM 및 XFS에 대한 여러 참조를 찾았습니다. 그러나 두 장치보다 더 높은 용량을 달성할 수 있는 것은 분명 없습니다.

따라서 이것이 가능하다고 가정했지만 구현 방법을 찾지 못했습니다.


이 문제의 까다로운 부분은 하나의 최종 파일 시스템만 사용하여 솔루션을 구현하는 것입니다. 나에게는 디렉토리별로 배치할 파일을 수동으로 선택하는 것이 불가능합니다.

답변1

아래 답변은 개인적인 경험에 근거한 것이 아니므로 실제로 효과가 있는지 확실하게 말할 수는 없지만 시도해 볼 수 있는 아이디어일 뿐입니다.

LVM 캐시

캐시 논리 볼륨 유형은 작고 빠른 LV를 사용하여 크고 느린 LV의 성능을 향상시킵니다. 자주 사용되는 블록을 더 빠른 LV에 저장하여 이를 수행합니다.

내가 올바르게 이해했다면 빠른 디스크의 캐시 크기를 제한한 다음 느린 디스크와 나머지 빠른 디스크의 다른 논리 볼륨을 만들 수 있습니다.

블록 캐시

또 다른 가능한 해결책은은닉처:

Bcache(블록 캐시)를 사용하면 SSD를 다른 블록 장치(일반적으로 회전하는 HDD 또는 어레이)에 대한 읽기/쓰기 캐시(후기입 모드) 또는 읽기 캐시(연속 기입 또는 후기입)로 사용할 수 있습니다.

지원 장치와 캐싱 장치 모두 가능합니다."전체 장치, 파티션 또는 기타 표준 블록 장치."

이론적으로는 SSD를 200+300GB 파티션 2개로 나눌 수 있습니다. 200GB가 캐시 장치로 사용됩니다.

그런 다음 SSD의 나머지 300GB 파티션과 느린 디스크를 단일 800GB 논리 볼륨으로 결합할 수 있습니다( LVM또는 사용).소프트웨어 RAID) 캐시 장치를 사용하여 캐시합니다.

다시 말하지만, 나는 이것들 중 어떤 것도 시도한 적이 없습니다. lvmcache귀하의 목적에 더 적합한 것 같습니다. 두 가지를 모두 시도하고 성능을 비교하여 어떤 솔루션이 더 나은지 결정할 수 있습니다.

답변2

XFS는 라이브 파티셔닝을 제공합니다:

XFS 파일 시스템은 일반 디스크 파티션이나 논리 볼륨에 상주할 수 있습니다. XFS 파일 시스템은 데이터 부분, 로그 부분, 실시간 부분의 최대 세 부분으로 구성됩니다. ...

...

실시간 부분은 실시간 파일에 대한 데이터를 저장하는 데 사용됩니다. 이 파일의 속성 비트는 다음을 통해 전달됩니다.xfsctl(3)파일이 생성된 후, 파일에 데이터가 기록되기 전입니다. 실시간 부분은 여러 고정 크기 범위(mkfs.xfs(8) 시간에 지정됨)로 나뉩니다. 라이브 섹션에 있는 각 파일의 확장 크기는 라이브 섹션 확장 크기의 배수입니다.

하지만 제한사항이 있으니 참고하세요. 데이터는 라이브 파티션이나 "일반" 파티션에 기록되므로 파티션에서 볼 수 있는 것처럼 용량을 확장하기 위해 데이터가 앞뒤로 이동하지 않습니다.계층형 스토리지 시스템.

둘째, 지원서를 작성하려면 다음이 필요합니다.XFS_XFLAG_REALTIME실시간 비트 설정파일이 생성된 후 데이터가 기록되기 전에 라이브 파티션을 기록하려는 파일의 경우.

답변3

대략적인 아이디어입니다. 읽기 전용 부분이 HDD이고(아마도 변경되지 않거나 거의 변경되지 않는 파일의 경우) 덮어쓰기가 SSD에 있는 FS 덮어쓰기를 고려해 보셨나요? 파일이 안정적이라고 판단되면 오버레이에서 HDD로 파일을 이동하고, 오버레이에 활성 작업 복사본이 있으면 HDD에서 파일을 제거하는 오프라인 메커니즘이 필요합니다. 이 오프라인 메커니즘은 SSD가 가득 찼을 때 실행될 수 있습니다. 분명히 사람들은 이전에도 이 방향을 보고 있었을 것입니다.Linux 오버레이(OverlayFS) 마운트의 상위 파일 시스템에 대한 변경 사항을 하위 파일 시스템에 병합.

많은 작업을 수행하면 FUSE 파일 시스템을 만들어 온라인에서 자동으로 수행하는 것도 가능합니다. 실제로 이 문제를 해결할 수 있는 방법이 있을 수도 있습니다.https://en.wikipedia.org/wiki/Filesystem_in_Userspace몇 가지 아이디어와 조언.

답변4

보세요파일 시스템 병합: "mergerfs는 논리적으로 여러 경로를 병합합니다. 이를 집합의 결합으로 생각하십시오. mergefs를 통해 실행되거나 렌더링되는 파일 또는 디렉터리는 해당 특정 작업에 대해 선택된 정책을 기반으로 합니다."

그리고좌심실: "LVM 볼륨을 모니터링하고 사용량에 따라 블록을 더 빠르거나 느린 스토리지로 이동하는 애플리케이션입니다. 즉, Linux에서 LVM을 활용하는 계층적 스토리지 관리자입니다."

관련 정보