Read Policy: 읽기 정책
No Read Ahead: 어플리케이션(프로세서)이 읽기 요청한 부분만 읽습니다.
그러니깐 앞으로 요청할 거 같은 데이터 캐시에 미리 올려논다든지 그러지 않는다는겁니다.
데이터 읽기가 예측하기 힘들정도로 다양한 위치(위치가 중요합니다)에서 무작위로 이루어지는 경우 이 정책이 좋습니다. 레이드카드의 뻘짓이 줄겁니다.
Always Read Ahead: 프로세서에서 요청한 읽기외에 그 주변까지 미리 읽어놓습니다.
대개 동일한 시점에 동일한 폴더내에 작성된 파일들은 주변 블록에 몰려있습니다. 이런 파일들이 같이 엑세스 되는 경우가 많은 경우, 주변을 미리 읽어놓으면 성능이 좋아질 수 있다는거죠.
하드디스크의 스트라이프 시퀸셜 읽기 성능이 뛰어나다는걸 이용한 정책입니다. 주로 어플리케이션 기동같은 행위에 강합니다.
파일단위로 보지 않더라도, 대개의 어플리케이션은 하나의 파일 내에서 랜덤억세스를 하는 경우 주로 주변 블럭을 왔다갔다하며 탐색하니 나름 여려 경우에 그럭저럭 적용되는 정책이라고 볼 수 있습니다.
Adaptive Read Ahead: 사용자의 읽기 패턴을 파악해서 자주 접근하는 파일들을 미리 읽어드립니다. (한국어로 번역하면 적응형 미리읽기?)
이건 OSX가 잘 하는 짓인데, 최근 발매된 윈도즈10에도 포함된 기능입니다(파일케싱에 대해: 어플리케이션 프리패칭 등의 기술은 예전부터 존재함).
여기서는 컨트롤러가 사용자의 행동패턴을 파악해서 자주 접근하는 데이터를 미리 캐시에 올려놓겠다는겁니다.
참고로 아이폰과 안드로이드는 거지같은 eMMC 성능과, 지루한 어플리케이션 로딩속도 때문에 필수적으로 들어간 기능이기도 합니다.
(메모리 클리닝을 해도 자꾸 메모리 사용량이 도로 늘어나는 이유)
서버시스템 스토라지에서는 캐시가 사용자가 주로 접근하는 데이터들의 합보다 크다면야 효과가 매우 크겠지만, 그렇지 않다면 글쎄요?
(물론 제조사들 설명서에는 패턴이 일정하다면 캐시 크기가 작아도 잘 동작한다고 기대하게끔 설명합니다만....)
Write Policy: 기록정책(기록 작업을 어떻게 진행할 것인지를 설정하는 겁니다):
Write Back: (쓰기작업을 백그라운드로 합니다)
Process -----[쓰기명령 > Controller-] [------- 짧은 대기 ----------] [다른일 하기 ------------------------------------
Controller --------------------------- [(캐시에) 쓰기완료 > Process -] [백그라운드 쓰기작업 -----] [미디어에 쓰기 완료 --]
쓰기명령을 컨트롤러에 보내면 컨트롤러가 데이터를 캐시에 로드하고, 바로 쓰기 완료했음 이라고 프로세스에 신호를 보냅니다. 프로세스는 계속 다른 작업을 합니다.
컨트롤러는 남는 시간에 캐시에 있는 데이터를 실제로 미디어(하드디스크)에 기록할겁니다. 전원이 끊겼을 때 문제가 발생할 소지가 높지만, 인터럽트 오버헤드를 크게 줄일 수 있습니다.
Write Through: (즉시기록모드)
Process ----- [쓰기명령 > Controller][----- (오랜 기다리기) ----------------------------------] [다른일 하기 ---
Controller ------------------------- [쓰기작업 ------------------][미디어에 쓰기완료 > Process] --------------
쓰기명령을 컨트롤러에 보내면 컨트롤러는 미디어에 기록을 마칠때까지 프로세서에 인터럽트를 걸어버립니다.
프로세서는 컨트롤러가 쓰기작업을 마치기 전까지 다른 작업을 할 수 없습니다.
인터럽트 오버헤드가 있지만, 전원차단 등에 Write Back에 비해 매우 튼튼합니다.
부가옵션(만약 컨트롤러 세팅옵션에 있다면)
Disk Cache Policy:
실제 미디어의 캐시 정책을 설정합니다. Write Through 모드에서는 이 정책이 실제 스토라지의 기록성능을 결정짓습니다.
Write Back 모드에서는 백그라운드 쓰기 작업의 퍼포먼스를 결정합니다. (프로세서에 영향을 주지 않습니다: 캐시가 널널하다면)
별거 아니고 대개 실제 하드디스크에 있는 캐시(보통 하드디스크 Cache 스펙에 표시되는거...) 쓸건지 말건지 이정도 설정하는 겁니다.
적어도 레이드카드의 캐시보다는 전원차단 등의 사고에 어느정도 내성이 높다고 볼 수 있습니다(기업용 하드는 이런 경우를 대비해서 내부에 대용량 캐퍼시티를 포함하는 경우가 많습니다).
I/O Policy: 입출력 정책(이건 개인적으로 이 이름보다는 I/O Cache Policy가 더 낮다고 생각합니다)
Direct I/O: 직접 입출력
입출력 작업에 컨트롤러의 캐시따위 쓰지 않습니다. 캐시를 사용하는 경우에 비해 안정적으로 동작합니다. (대신 성능이...)
Cached I/O: 캐시된 입출력
입출력 작업에 컨트롤러 캐시를 사용합니다. 만약 캐시에 있는 데이터를 요청하면 하드디스크 긁어댈거 없이 바로 캐시에서 보내줄 수 있을겁니다.
제가 가장 해메던게 I/O Policy랑 다른 정책이랑 겹치는 내용이 있다는겁니다. 제가 알기로는 컨트롤러에 두 옵션이 다 있는 경우 다른 정책들이 I/O 정책에 의해 무효화 되기도 하는 것으로 알고 있습니다(정확한 내용은 역시 컨트롤러 제조사에 문의하는게 낮겠지요). 읽기 정책의 Adaptive Read Ahead는 제가 설명하고 있는 형태로 동작하는지에 대해 확실치 않습니다. 대개 중저가 레이드 컨트롤러 캐시는 제가 해당 항목에 설명한 형태의 작업을 수행하기에는 매우 부족합니다. (안드로이드만 하더라도 앱이 많이 안 깔려있어도 대개 500MB ~ 1GB정도의 메모리를 어플리케이션 캐싱에만 소모합니다)
참고로 레이드컨트롤러 뿐 아니라, ZFS에도 동일한 내용이 나옵니다. 다들 비슷비슷한 내용 가지고 건들기 때문에 비슷한 내용을 다룹니다만, 그래도 역시 컨트롤러 메뉴얼을 보는게 좋습니다. 스펙과 작동 환경이 다들 다르기 때문에 세부적인 동작은 상이할 수 있습니다.
캐시는 레이드카드 자체의 캐시도 있지만, 별도 SSD로 구성하는 경우도 있습니다. 비휘발성 캐시의 경우 전원차단에 좀더 내성이 있습니다.
Storage Cache 의 경우 위의 옵션들은 항상 존재합니다.
Cache 메모리는 느린 디스크 I/O 를 나중에 백그라운드에서 메모리와 디스크를 씽크해주는 프로세스의 도움으로 프로그램들이 빠른 케쉬를 인터페이스하니까 어느면에서는 속도에 많은 도움이 되기도 합니다만 전혀 적용이 안되는 경우도 있고 또는 케쉬와 디스크가 씽크가 제대로 안되는 경우도 발생할 수 있기때문에 (갑자기 발생하는 power outage 나 프로세스가 안정적이지 못한 경우들로 인하여) 디스크에 저장되는 정보가 망가지는 일들이 생기기도하지요... 이것을 방지하는 많은 로직들이나 백업파워들이 존재하긴하지만 그래도 항상 문제를 일으키는 부분이라서... 아주 조심해야 하는 옵션인것 같습니다...
zfs의 경우 많은 시스템 메모리를 파일시스템의 케쉬로 사용하여 zfs 기능중에 속도를 저하시키는 부분들을 극복하고 zfs 를 더 빠르게 만들기도 합니다...
읽는 방법 (원칙/룰) -> 먼저 읽지 않는다.
쓰는 방법 -> Write Through 방식으로 한다.
LSI 제품 셋팅중 같은데
LSI 본사에 영어로 문의해보세요..
Read Policy: 읽기 정책
No Read Ahead: 어플리케이션(프로세서)이 읽기 요청한 부분만 읽습니다.
그러니깐 앞으로 요청할 거 같은 데이터 캐시에 미리 올려논다든지 그러지 않는다는겁니다.
데이터 읽기가 예측하기 힘들정도로 다양한 위치(위치가 중요합니다)에서 무작위로 이루어지는 경우 이 정책이 좋습니다. 레이드카드의 뻘짓이 줄겁니다.
Always Read Ahead: 프로세서에서 요청한 읽기외에 그 주변까지 미리 읽어놓습니다.
대개 동일한 시점에 동일한 폴더내에 작성된 파일들은 주변 블록에 몰려있습니다. 이런 파일들이 같이 엑세스 되는 경우가 많은 경우, 주변을 미리 읽어놓으면 성능이 좋아질 수 있다는거죠.
하드디스크의 스트라이프 시퀸셜 읽기 성능이 뛰어나다는걸 이용한 정책입니다. 주로 어플리케이션 기동같은 행위에 강합니다.
파일단위로 보지 않더라도, 대개의 어플리케이션은 하나의 파일 내에서 랜덤억세스를 하는 경우 주로 주변 블럭을 왔다갔다하며 탐색하니 나름 여려 경우에 그럭저럭 적용되는 정책이라고 볼 수 있습니다.
Adaptive Read Ahead: 사용자의 읽기 패턴을 파악해서 자주 접근하는 파일들을 미리 읽어드립니다. (한국어로 번역하면 적응형 미리읽기?)
이건 OSX가 잘 하는 짓인데, 최근 발매된 윈도즈10에도 포함된 기능입니다(파일케싱에 대해: 어플리케이션 프리패칭 등의 기술은 예전부터 존재함).
여기서는 컨트롤러가 사용자의 행동패턴을 파악해서 자주 접근하는 데이터를 미리 캐시에 올려놓겠다는겁니다.
참고로 아이폰과 안드로이드는 거지같은 eMMC 성능과, 지루한 어플리케이션 로딩속도 때문에 필수적으로 들어간 기능이기도 합니다.
(메모리 클리닝을 해도 자꾸 메모리 사용량이 도로 늘어나는 이유)
서버시스템 스토라지에서는 캐시가 사용자가 주로 접근하는 데이터들의 합보다 크다면야 효과가 매우 크겠지만, 그렇지 않다면 글쎄요?
(물론 제조사들 설명서에는 패턴이 일정하다면 캐시 크기가 작아도 잘 동작한다고 기대하게끔 설명합니다만....)
Write Policy: 기록정책(기록 작업을 어떻게 진행할 것인지를 설정하는 겁니다):
Write Back: (쓰기작업을 백그라운드로 합니다)
Process -----[쓰기명령 > Controller-] [------- 짧은 대기 ----------] [다른일 하기 ------------------------------------
Controller --------------------------- [(캐시에) 쓰기완료 > Process -] [백그라운드 쓰기작업 -----] [미디어에 쓰기 완료 --]
쓰기명령을 컨트롤러에 보내면 컨트롤러가 데이터를 캐시에 로드하고, 바로 쓰기 완료했음 이라고 프로세스에 신호를 보냅니다. 프로세스는 계속 다른 작업을 합니다.
컨트롤러는 남는 시간에 캐시에 있는 데이터를 실제로 미디어(하드디스크)에 기록할겁니다. 전원이 끊겼을 때 문제가 발생할 소지가 높지만, 인터럽트 오버헤드를 크게 줄일 수 있습니다.
Write Through: (즉시기록모드)
Process ----- [쓰기명령 > Controller][----- (오랜 기다리기) ----------------------------------] [다른일 하기 ---
Controller ------------------------- [쓰기작업 ------------------][미디어에 쓰기완료 > Process] --------------
쓰기명령을 컨트롤러에 보내면 컨트롤러는 미디어에 기록을 마칠때까지 프로세서에 인터럽트를 걸어버립니다.
프로세서는 컨트롤러가 쓰기작업을 마치기 전까지 다른 작업을 할 수 없습니다.
인터럽트 오버헤드가 있지만, 전원차단 등에 Write Back에 비해 매우 튼튼합니다.
부가옵션(만약 컨트롤러 세팅옵션에 있다면)
Disk Cache Policy:
실제 미디어의 캐시 정책을 설정합니다. Write Through 모드에서는 이 정책이 실제 스토라지의 기록성능을 결정짓습니다.
Write Back 모드에서는 백그라운드 쓰기 작업의 퍼포먼스를 결정합니다. (프로세서에 영향을 주지 않습니다: 캐시가 널널하다면)
별거 아니고 대개 실제 하드디스크에 있는 캐시(보통 하드디스크 Cache 스펙에 표시되는거...) 쓸건지 말건지 이정도 설정하는 겁니다.
적어도 레이드카드의 캐시보다는 전원차단 등의 사고에 어느정도 내성이 높다고 볼 수 있습니다(기업용 하드는 이런 경우를 대비해서 내부에 대용량 캐퍼시티를 포함하는 경우가 많습니다).
I/O Policy: 입출력 정책(이건 개인적으로 이 이름보다는 I/O Cache Policy가 더 낮다고 생각합니다)
Direct I/O: 직접 입출력
입출력 작업에 컨트롤러의 캐시따위 쓰지 않습니다. 캐시를 사용하는 경우에 비해 안정적으로 동작합니다. (대신 성능이...)
Cached I/O: 캐시된 입출력
입출력 작업에 컨트롤러 캐시를 사용합니다. 만약 캐시에 있는 데이터를 요청하면 하드디스크 긁어댈거 없이 바로 캐시에서 보내줄 수 있을겁니다.
제가 가장 해메던게 I/O Policy랑 다른 정책이랑 겹치는 내용이 있다는겁니다. 제가 알기로는 컨트롤러에 두 옵션이 다 있는 경우 다른 정책들이 I/O 정책에 의해 무효화 되기도 하는 것으로 알고 있습니다(정확한 내용은 역시 컨트롤러 제조사에 문의하는게 낮겠지요). 읽기 정책의 Adaptive Read Ahead는 제가 설명하고 있는 형태로 동작하는지에 대해 확실치 않습니다. 대개 중저가 레이드 컨트롤러 캐시는 제가 해당 항목에 설명한 형태의 작업을 수행하기에는 매우 부족합니다. (안드로이드만 하더라도 앱이 많이 안 깔려있어도 대개 500MB ~ 1GB정도의 메모리를 어플리케이션 캐싱에만 소모합니다)
참고로 레이드컨트롤러 뿐 아니라, ZFS에도 동일한 내용이 나옵니다. 다들 비슷비슷한 내용 가지고 건들기 때문에 비슷한 내용을 다룹니다만, 그래도 역시 컨트롤러 메뉴얼을 보는게 좋습니다. 스펙과 작동 환경이 다들 다르기 때문에 세부적인 동작은 상이할 수 있습니다.
캐시는 레이드카드 자체의 캐시도 있지만, 별도 SSD로 구성하는 경우도 있습니다. 비휘발성 캐시의 경우 전원차단에 좀더 내성이 있습니다.
Cache 메모리는 느린 디스크 I/O 를 나중에 백그라운드에서 메모리와 디스크를 씽크해주는 프로세스의 도움으로 프로그램들이 빠른 케쉬를 인터페이스하니까 어느면에서는 속도에 많은 도움이 되기도 합니다만 전혀 적용이 안되는 경우도 있고 또는 케쉬와 디스크가 씽크가 제대로 안되는 경우도 발생할 수 있기때문에 (갑자기 발생하는 power outage 나 프로세스가 안정적이지 못한 경우들로 인하여) 디스크에 저장되는 정보가 망가지는 일들이 생기기도하지요... 이것을 방지하는 많은 로직들이나 백업파워들이 존재하긴하지만 그래도 항상 문제를 일으키는 부분이라서... 아주 조심해야 하는 옵션인것 같습니다...
zfs의 경우 많은 시스템 메모리를 파일시스템의 케쉬로 사용하여 zfs 기능중에 속도를 저하시키는 부분들을 극복하고 zfs 를 더 빠르게 만들기도 합니다...