김윤술 2016-02

서버의 메모리를 쓰기 캐쉬로 쓰고 있을겁니다. log 디바이스를 따로 지정해주면 메모리 쓰기용량이 오버되면 SSD 용량으로 쓰기로 넘어갑니다. 즉 램을 쓰기로 캐쉬로 써서 빠른겁니다. 문제는 쓰기가 열심히 진행될때 정전시 데이터가 깨질 우려가 있다는 단점이 있죠.

NGC 2016-02

copy on write이고.. ZFS자체가 데이터무결성을 가지는 파일시스템으로 알고있는데 정전시 깨지나요???
일반적인 저널링 파일시스템보다 zfs가 정전시 파일시스템 무결성때문에라도 꼭 쓰려고 하는 건데...

김윤술 2016-02

복불복입니다. 무조건 정전되었다고 깨지는게 아니고 운없으면 깨집니다. 제가 한번 깨먹어봐서요. 일부는 복구하고 일부는 최종 데이터 백업으로 살리고 했던 그날이 생각납니다.

분노의다운힐 2016-03

default인 async write 방식에서는 메모리 버퍼링이 있기 때문에 정전되면 버퍼링된 내용이 날라가는 것은 당연합니다. 이건 ZFS 뿐 아니라 모든 파일시스템이 동일합니다. ZFS 속성에서 항상 synchronous write를 쓰게 하고 쓰기 성능이 좋은 SSD로 ZIL을 추가하면 조금 더 나을 것 같습니다. sync write에서는 ZIL까지 반영된 후에 write가 종료되기 때문에, 최소한 write syscall이 성공하면 데이터를 잃을 일은 없습니다. (ZIL은 메모리가 아니라 스토리지 또는 전용 디바이스에 생성됩니다) 반면에, async write에서는 write가 성공해도 데이터를 잃을 수 있는 가능성이 있습니다. 물론 작더라도 UPS가 있어야 안심할 수 있겠지만요.

간장게장 2016-02

우선 캐시 때문입니다. 고가의 하드웨어 레이드 카드들도 마찬가지이고요.

캐시가 1GB이면 1GB 복사까지는 빠르다가 그거 딱 지나면 캐시 없는 원래의 제 속도가 나올 것 같은데 그 이후에도 빠릅니다. 우선 생각할 수 있는 것은 1GB 복사하는 동안에 일부는 하드디스크로 나가기 때문에 캐시가 꽉 차지는 않기 때문이라는 것을 생각할 수 있습니다. 그것도 이유가 되기는 합니다만 그것보다도...

캐시를 좀 지능적으로 사용하자면 캐시 안으로 조각 조각 들어온 것들을 순서를 바꿔서 끼리끼리 모아서 하드디스크에 순차적으로 출력하기 때문입니다. 요새 하드디스크는 순차 읽기 쓰기 속도는 100Mb/sec가 넘습니다. 그러나 조각 조각 들어온 것들을 즉각적으로 보내면 그 속도가 나올 수 없습니다. a1-b1-c1-a2-b2-c2-a3-b3-c3 순서로 들어온 것을 그냥 하드디스크로 보내는 것이 아니라 순서를 바꿔서 a1-a2-a3(인접한 것) 보내고 b1-b2-b3 보내고 c1-c2-c3 보내고 하는 식으로 뭉텡이로 보내면 순차 읽기 쓰기 속도에 근접할 수 있습니다.(그래서 NCQ니 queue depth니가 중요함)

SSD 같은 경우 원래 flash 메모리가 읽기는 무쟈게 빠르지만 쓰기는 무쟈게 느린 매체입니다.(지우고 나서 써야 하는데 지우는데 시간이 많이 걸림) 요걸 콘트롤러가 장난을 쳐서 미리 깨끗하게 준비된 곳에 쓰고 지워져야 할 기존 데이터는 나중에 백그라운드로 슬슬 지우는 방법, 그리고 앞서 말씀드린 모아서 순차화시켜 쓰는 방식을 결합시겨 빠르게 하는 것입니다. raid 식으로 병렬화해서 빠르게 하는 것도 있고.

zfs 같은 것은 저널링 파일 시스템이라고 하여 캐시 역할을 빼더라도 순차 쓰기 속도가 원래 빠릅니다. 여기저기 찾아다니면서 찔끔찔끔 쓰질 않고 한 곳에 주르르 순차적으로 쓰기를 합니다. 바로 SSD와 비슷한 방법을 쓰는 것이죠. 순서를 따지자면 사실은 SSD 컨트롤러가 저널링 파일시스템 방식을 모방한 것임.

간장게장 2016-02

위에
"zfs 같은 것은 저널링 파일 시스템이라고 하여 캐시 역할을 빼더라도 순차 쓰기 속도가 원래 빠릅니다."
이건 표현이 좀 잘못되었네요. 순차 쓰기 속도는 아무 파일시스템이나 원래 빠른 것이고. 찔끔찔끔 쓰는 것이 느린 것인데, zfs 같은 것은 여기저기 찾아댕기며 찔끔찔끔 쓰질 않고 그냥 주르르 새 장소에 쓰는 방식을 사용합니다.

병따개님 2016-02

캐시를 쓴다는 말 외에는 어려워서 이해가 쉽지 않네요. ^^;

5년정도 지나면 왠지 ssd가격이 하드에 근접할거같으니 그때가 되면 쓰기속도 걱정은 사라지겠죠?

병따개님 2016-02

한번 위키피디아의 zfs항목을 보니

RAID-Z is a data/parity distribution scheme like RAID-5, but uses dynamic stripe width: every block is its own RAID stripe, regardless of blocksize, resulting in every RAID-Z write being a full-stripe write. This, when combined with the copy-on-write transactional semantics of ZFS, eliminates the write hole error.

RAID-Z is also faster than traditional RAID 5 because it does not need to perform the usual read-modify-write sequence.

이런 설명이 있긴하네요.
read-modify-write가 뭔지 모르겠다는게 문제지만...

김주영the촌놈 2016-03

캐쉬는 용량도 물론 중요하지만 그것보단 알고리즘이 더 중요하죠.

epowergate 2016-03

제가 아는범위에서 정리해 드리면 다음과 같습니다.
ZFS는 COW file system입니다.  다시말하면 DISK에 WRITE 될때까지 Return이 오질 않는겁니다.  즉, Memory를  CACHE로 사용하지 않습니다.
ZFS는 파일마다 Block Stripe 크기가 다릅니다.  보통 32KB ~ 128KB입니다.
READ-MODIFY-WRITE는 SOFTWARE RAID등에서 PARITY 계산을 어떻게 하는지에 대한 방법입니다.
ZFS는 DATA를 우선 WRITE하고 PARITY를 나중에 계산해서 WRITE하는것으로 되어 있습니다.  DATA는 DISK있지만 Memory에 CACHE도 되어 있지요. 이를 이용합니다.

문제는 ZFS가 모두 ZFS가 아니라는데 있습니다.
BSD, Solaris, OpenSolaris에 있는 ZFS는 COW를 100% 지원합니다.
Linux에는 2가지 ZFS가 있지요.  FUSE 기반의 ZFS와 ZFSonLinux 가 있습니다.  까먹었는데 2중에 1개는 COW를 완벽하게 지원하지 않습니다.  그 버전은 사용자의 느낌상으로 더 빨라 보일수 있습니다.

epowergate 2016-03

한가지 팀을 드리면 ZFS에서는 가변 Stripe를 사용합니다.  파일의 크기에 따라서 Stripe의 크기를 조정하는 기술입니다.  파일을 저장할때는 좋아보이죠.
문제는 정형데이터, DBMS 등,을 저장할때는 쥐약입니다.  COW도 좋아보이죠.  그런데 DBMS에서는 쥐약을 2번 먹는겁니다.
ORACLE등의 상용 DB에서는 자체적으로 저장 Device 장애를 대비하는 기능을 가지고 있는데 COW등은 over head가 너무 크지요.
ORACLE에서 ZFS만 고집하지 않는 이유이기도 합니다.