쓰루는 케시 없이 그냥 io로 바로 흘립니다.
병목의 영향을 그대로 받구요. 오히려 병목을 발생시키는 원인이 되기도 하죠......
빽은 케시에서 한번 데이터가 거쳤다 나갑니다. NOR연산도 내부 케시상에서 이뤄지니
병목의 영향을 상대적으로 덜 받고, 성능적으도 훨 나은 결과를 보여주죠.
대신 밧데리든 sc든 없으면 예기치 못한 정전으로 데이터 날릴 수 있다는 정도?
쓰루도 마찬가지긴 합니다.
Write-through:
캐시에 기록하면서 매체에도 기록합니다.
매체에 기록이 끝나야 io가 종료됩니다.
단적으로 보면 쓰기시에 성능 잇점이 없어보이죠. 읽기는 캐시에서 읽으니 빨라집니다.
Write-back:
캐시에만 기록하고 무결성 문제가 발생하거나 알고리즘에 의해 후에 매체에 기록합니다.
캐시에만 기록하면 io가 종료됩니다. 쓰기시에 Write-through보다 빠르겠죠.
매체에 기록 전(dirty status라 합니다)에 전원이 나가거나 하면 데이터 날아가겠죠.
그래서 백업 배터리 내놔라고 경고 띄웁니다.
둘다 read에서는 동일합니다. cache-hit되면 cache-read, cache-miss되면 디스크에서 cache로 읽어온 후 cache-read. 쓰기에서는 WT는 cache-write와 disk-write가 함께 발생. WB은 cache-write만 발생하고 해당 data를 dirty로 세팅. 나중에 알고리즘에 따라 idle이나 cache-hit일 때 비동기적으로 disk-write가 발생합니다. 고로.. write에 있어서는 WB 방식이 빠를 수 밖에 없고.. 대신 cache 메모리에 아직 dirty가 있는 상태에서 전원이 나가면 그 dirty data는 모두 유실됩니다. 백업 베터리가 있으면 dirty data가 계속 유지되고 보통 다시 켰을때 모두 disk로 flush됩니다. 플래쉬 백업도 비슷하게 비휘발성 메모리를 이용해서 dirty data를 유지한다고 보면 됩니다.
병목의 영향을 그대로 받구요. 오히려 병목을 발생시키는 원인이 되기도 하죠......
빽은 케시에서 한번 데이터가 거쳤다 나갑니다. NOR연산도 내부 케시상에서 이뤄지니
병목의 영향을 상대적으로 덜 받고, 성능적으도 훨 나은 결과를 보여주죠.
대신 밧데리든 sc든 없으면 예기치 못한 정전으로 데이터 날릴 수 있다는 정도?
쓰루도 마찬가지긴 합니다.
즉 데이터가 들어온 순서대로 나가게 됩니다.
Write-back은 캐쉬 콘트롤러가 요청한 데이터 먼저 보냅니다.
먼저 들어온 데이터가 있어도 요청이 없으면 캐쉬에 머물게 되고 나중에 들어온 데이터라도
요청이 있으면 먼저 나갑니다.
보통 Wrie-Back 이 더 나은 성능을 보여 줍니다.
기본 사항만 언급해보면
Write-through:
캐시에 기록하면서 매체에도 기록합니다.
매체에 기록이 끝나야 io가 종료됩니다.
단적으로 보면 쓰기시에 성능 잇점이 없어보이죠. 읽기는 캐시에서 읽으니 빨라집니다.
Write-back:
캐시에만 기록하고 무결성 문제가 발생하거나 알고리즘에 의해 후에 매체에 기록합니다.
캐시에만 기록하면 io가 종료됩니다. 쓰기시에 Write-through보다 빠르겠죠.
매체에 기록 전(dirty status라 합니다)에 전원이 나가거나 하면 데이터 날아가겠죠.
그래서 백업 배터리 내놔라고 경고 띄웁니다.
사용자 입장에서는 이 정도만 알면 됩니다.