raw device

0. raw device를 생성하는 이유
테이블스페이스가 파일시스템에 데이터를 저장하는 것이 일반적인 반면, 일부 DBMS는 raw device로 불리는 O/S device로 구성하여 운영 체제 파일시스템의 오버헤드를 없애고 더 빠른 성능을 제공한다.
물론 모든 환경(OLTP, DW 등등)에서 raw device가 만능은 아니므로 사용 환경에 따라 FS별로 퍼포먼스를 체크하여 가장 사용 환경에 알맞는 FS를 선택하는 것이 중요하다

 

"디스크에서 I/O는 느린 반면에 메모리에서의 I/O는 속도가 훨씬 빠르다. 그렇기 때문에 일반적으로 OS에서는 파일시스템에 접근할때 direct I/O가 아닌 buffered I/O를 한다. 그런데 DBMS들은 자체적으로 buffering을 한다.
사 용자가 어떤 데이터를 원할때 마다 디스크에서 I/O를 하기 보다는 먼저 일정량을 메모리에 올려놓고 메모리에서 사용자가 원하는 데이터를 가져오는 것이 빠르기 때문이다. 이런 상황에서는 OS가 하는 buffering과 DBMS가 하는 buffering effort가 중첩되서 낭비가 되는 경우가 발생한다.
현재에 와서는 Disk 성능의 많은 개선으로 raw device와 File system간의 우열을 가리기 힘들거나 오히려 상황에 따라서는 File system을 이용하는 것이 DBMS 입장에서 좋은 경우도 있다. 하지만 아직까지도 대규모 데이터의 I/O를 필요로 하는 DBMS의 경우 direct I/O를 추천한다.
참 고적으로 대부분의 Unix에서는 direct I/O를 위해서 파일시스템과 같은 cooked device (buffered) 해당 디스크의 파티션/볼륨을 직접 access할 수 있는 raw device(non-buffered)를 제공한다."

<발췌: 정보공학의 短想(http://dbsecurity.egloos.com)>

 

1. dd (파티션 전체를 백업하고 복구하기 위한 tool)

리눅스가 설치된 파티션의 시작 cylinder#와 끝 cylinder#를 이용하여 파티션을 파일로 백업하는 방법으로 파티션 전체의 백업/복구에 사용된다.

 

Sample) # dd if=/dev/sda2 of=/backup/linux_sda2.img
(sda2 파티션 전체를 /backup/linux_sda2.img 라는 파일에 저장)

 

이러한 dd의 기능을 파일을 생성할 수 있는 점을 이용하여 /dev/zero(내용이 '0'(실제 존재하지만 아무것도 없는)) 가상 디바이스를 통해 raw device에 이용할 파일을 생성한다.

 

# dd if=/dev/zero of=asm_disk1 bs=1024k count=5000
(/dev/zero를 이용해 asm_disk1을 생성하며 이 파일에는 1,024KB(= 1MB) 용량으로 5000번의 I/O 카운트를 수행한다)

 

위 명령을 실행하면 /dev/zero라는 '실제 존재하지만 아무 내용도 없는' 장치를 block size 1MB 크기로 5000회 I/O를 수행하여 파일을 생성하므로 asm_disk1은 5GB 크기의 아무 것도 없는 파일로 생성되게 된다.

 

# chmod 777 asm_disk*
(생성한 asm_disk*는 모든 사용자가 접근할 수 있어야 하므로 777권한으로 setup한다)

 

파일 생성이 완료되었지만 어디까지나 '파일'이기 때문에 이 파일들은 '장치(블록 단위로 데이터 I/O가 가능한)'라고 볼 수 없다. 이 파일을 '장치'로 사용하기 위해서는 loop device를 사용해야한다.

 

2. Loop device

'Loop Device의 정의' (from Wikipedia):

Unix계열 운영체제에서, loop device와 vnd(vnode disk) 또는 lofi(loopback file interface)는 파일을 block device처럼 접근할 수 있게 만들어주는 기능을 한다.

사용하기 전, loop device는 필히 file system 안에 존재하는 file에 연결되어 있어야 한다. loop device는 /dev/loop0 ~ loop7까지 사전 생성되어 있다. 1에서 생성한 asm_disk1~8까지의 파일을 '장치'로 사용하기 위해서는 loop device에 mapping(or mount) 해줘야 한다.

 

# losetup /dev/loop0 asm_disk1
(loop device loop0에 asm_disk1 파일을 mapping한다)

 

이 때 주의할 점은 loop device는 loop0(1이 아님)부터 시작하므로 첫 번째 mapping은 loop0에 해 주는것이 좋다 (물론 loop1에 해도 문제는 되지 않지만). 이렇게 8개의 asm_disk 파일을 각각 loop device에 연결하게 되면 asm_disk를 파일에서 block단위로 I/O가 가능한 '장치'로 변환할 수 있다.

 

3. raw device 생성

 

# raw /dev/raw/raw1 /dev/loop0
(loop0 device를 raw1에 mount 한다)

 

이렇게 되면 asm_disk1~8은 linux Filesystem을 벗어나 raw device로서 FS에 독립적인 I/O가 가능해지므로 0번에서 얘기한 효과를 볼 수 있다. mount 작업을 마친 후 raw device 에 대한 소유권을 조정한다.

 

chown oracle.oinstall /dev/raw/raw1(~8까지 반복)
(raw1~8까지 device의 소유자를 oinstall 그룹의 oracle로 변경한다.)

출처 - http://blog.naver.com/hypnotical?Redirect=Log&logNo=20125228564



흔히 유닉스에서 스토리지 디바이스를 억세스하는 방법에 따라 

블록디바이스(/dev/dsk) 와 로(RAW)디바이스(/dev/rdsk) 로 구분을 합니다.

단어 그대로 이해를 한다면 블록디바이스에 블록은 파일시스템의 블록을 말하는 겁니다.

즉 로디바이스위에 파일시스템이 얹어 있다고 보면 됩니다. 

OS 는 어플리케이션의 IO 요구에 따라 파일 시스템에서 읽어 오느냐 ,

로 디바이스(파일시스템 보다는 더 하위레벨)에서 읽어 오느냐가 억세스 방법에 의해서

차이가 있습니다.

로 디바이스는 파일시스템이 없기 때문에 당현히 파일, 디렉토리, 억세스컨트롤 등을

어플리케이션에서 직접 관리 해야 합니다. 

로 디바이스를 데이타베이스에서 사용할 때 데이타 베이스는 자체적으로 블록과 익스텐트 등의

스토리지 관리 개념을 가지고 있기 때문에 OS레벨에서의 물리적인 데이타 파일 관리만 하면 됩니다.

(데이타 베이스에서 로디바이스를 사용하더라도 물리적인 디바이스(디스크)에 데이타 파일형태로 위치해야

하기 때문에 볼륨매니저 같은 가상 스토리지 개념이 필요합니다.)

일반적인 디스크는 I/O 다음과 같은 패스를 가집니다.

Application<->Library Buffer<->Operation System Cache<->File System/Volume Manager<->Device

그런데 로디바이스의 패스는 다음과 같습니다.

Application<->Device


흔히 DBMS 를 컨피그할때 데이타 파일의 위치를 놓고 RAW 와 파일시스템 비교를 많이 하게 됩니다.

나름대로 장단점이 있어 쉽게 판단 할수는 없지만 파일관리측면에선 파일시스템이 성능면에서는 로 디바이스가 낫습니다.

DBMS 시스템에서 파일시스템을 사용 할 경우 DBMS 의 가 자체 IO버퍼를 설정 하기 때문에 

OS 의 파일시스템 캐시가 필요 없습니다. 이런 파일시스템의 단점을 보완하고자 솔라리스의 Direct I/O , 베리타스 파일시스템등

이 나오게 되었습니다. 이와 같은 더블 버퍼링 를 막음으로써 OS는 메모리 파일시스템 캐싱을 위한 메모리 매니지먼트가 필요없어지고,

DBMS 에서만 버퍼링을 하므로 메모리를 덜 소모하게 됩니다. 주소 변환을 할 필요가 없으니 캐시의 억세스 속도도 빨라지겠죠.

RAW의 장점을 하나더 말씀드리면 KAIO(kernal async IO) 입니다.

위의 IO패스에서 보듯이 로디바이스는 IO요구가 발생될때 유저라이브러리를 사용 하지 않고 커널 레벨에서 IO 가 이루어 지므로 

명령이 단순해 져서 결과적으론 CPU를 덜 사용하게 됩니다.