raw device

System/Solaris 2011. 12. 8. 11:38

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를 덜 사용하게 됩니다. 
 

'System > Solaris' 카테고리의 다른 글

솔라리스 명령어  (0) 2012.03.02
오라클, 스팍 T4 출시  (0) 2012.01.04
/dev/dsk , /dev/rdsk  (0) 2011.12.08
한국오라클 시스템사업부 전략발표회  (0) 2011.11.22
오라클, 오라클 솔라리스 11 발표  (0) 2011.11.22
Posted by linuxism
,

dev 디렉토리에 dsk, rdsk 라는 디렉토리가 있다. dsk 디렉토리는 하드디스크 블럭 장치(Block device)파일이 들어있으며 rdsk 디렉토리에는 하드디스크가 캐릭터 장치(Character device)로 사용될 경우의 장치 파일이 들어있다.

 

- 하드디스크를 mount할 때는 블럭 장치로 사용되어 블럭 장치명으로 mount 해야한다.

mount /dev/rdsk/c0d0s3 /mnt <-- mount 실패

mount /dev/dsk/c0d0s3 /mnt <-- mount 성공

 

- 포맷할 때는 Character Device로 사용되어 Character Device name으로 포맷 해야한다.

newfs /dev/dsk/c0d0s3 <-- 원래는 안되나 newfs 프로그램이 아래와 같이 변환

newfs /dev/rdsk/c0d0s3 <-- 원래 포맷할 때 형식

 

====================

Written By BlueStorm

====================

 

Block Device
- Random access가 가능한 장치
- 파일 시스템에 의해 mount되어 관리되는 장치
- 버퍼캐쉬에 의한 내부 장치 표현
- 블록 단위의 입출력이 가능한 장치
- 디스크,CD-ROM,Floppy 등

 

Character Device
- 자료의 순차성을 지닌 장치
- 장치의 raw data를 사용자에게 제공
- Console, Tape, Keyboard, Sound Card, Scanner, Printer, Network Card 등


------------------------------------------------------------------------

 

블록 디바이스 드라이버는 버퍼를 가지고 대용량의 데이터를 주고 받는 디바이스를 위한 드라이버이다.문자 디바이스 드라이버(character device driver)란 입출력에 버퍼(buffer)를 필요로 하지않는 디바이스를 위한 드라이버이다.

 

------------------------------------------------------------------------

'System > Solaris' 카테고리의 다른 글

오라클, 스팍 T4 출시  (0) 2012.01.04
raw device  (0) 2011.12.08
한국오라클 시스템사업부 전략발표회  (0) 2011.11.22
오라클, 오라클 솔라리스 11 발표  (0) 2011.11.22
솔라리스 명령어  (0) 2011.11.03
Posted by linuxism
,

용어 정리

Development/Common 2011. 12. 7. 17:44

routine and subroutine ; 루틴과 서브 루틴

컴퓨터 프로그래밍에서 루틴과 서브 루틴은 어떤 프로그램이 실행될 때 불려지거나 반복해서 사용되도록 만들어진 일련의 코드들을 지칭하는 용어이다. 이를 이용하면 프로그램을 더 짧으면서도 읽고 쓰기 쉽게 만들 수 있으며, 하나의 루틴이 다수의 프로그램에서 사용될 수 있어서 다른 프로그래머들이 코드를 다시 작성하지 않도록 해준다. 프로그램 로직의 주요 부분에서는 필요할 경우 공통 루틴으로 분기할 수 있으며, 해당 루틴의 작업이 완료되면 분기된 명령의 다음 명령으로 복귀한다.

어셈블러 언어에서는 매크로 명령어라 불리는 인터페이스를 가진 매크로 정의 부분에 변수의 입력을 필요로 하는 루틴이 코딩될 수 있다. 프로그래머는 루틴을 포함하거나 그 루틴으로 분기하는 대신 매크로 명령어를 사용할 수 있다. 매크로 정의 및 명령어는 다수의 프로그램 특히, 소프트웨어 개발 프로젝트에 참여한 프로그래머 사이에서 공유되는 경우가 많다.

고급 프로그래밍 언어에서는 공통적으로 필요한 많은 루틴이 미리 함수로 만들어진다. 어떤 함수는 프로그램의 다른 코드와 함께 컴파일 되고, 어떤 함수는 프로그램이 실행될 때 시스템 서비스를 위한 동적 호출(dynamic call)을 하는 부분에서 컴파일 되기도 한다. 함수들은 때때로 라이브러리 루틴이라고도 불린다. 컴파일러와 라이브러리 루틴은 대체로 관련 소프트웨어 개발 패키지의 일부분이 된다.

윈도우와 같은 PC의 운영체계에서는 특정 입출력 장치와 상호작용 하는 기능을 수행하는 시스템 루틴을 동적 링크 라이브러리(DLL) 루틴이라 한다. 이 루틴들은 처음 불려질 때 비로소 메모리에 실제 로딩되기 때문에 앞에 동적(動的)이라는 말이 붙는다.

비교적 최근에 쓰이기 시작한 용어인 "프로시저"도 의미상으로는 루틴과 거의 비슷하다.



procedure ; 프로시저

  1. 프로그래밍에서, 프로시저는 루틴이나, 서브루틴 및 함수와 같은 뜻이다. 하나의 프로시저는 특정 작업을 수행하기 위한 프로그램의 일부이다.
  2. 일반적인 의미의 프로시저란, 어떤 행동을 수행하기 위한 일련의 작업 순서를 말한다.
 


library ; 라이브러리

라이브러리는 다른 프로그램들과 링크되기 위하여 존재하는, 하나 이상의 서브루틴이나 함수들이 저장된 파일들의 모음을 말하는데, 함께 링크될 수 있도록 보통 컴파일된 형태인 목적코드 형태로 존재한다. 라이브러리는 코드 재사용을 위해 조직화된 초창기 방법 중의 하나이며, 많은 다른 프로그램들에서 사용할 수 있도록, 운영체계나 소프트웨어 개발 환경제공자들에 의해 제공되는 경우가 많다. 라이브러리 내에 있는 루틴들은 두루 쓸 수 있는 범용일 수도 있지만, 3차원 애니메이션 그래픽 등과 같이 특별한 용도의 함수로 설계될 수도 있다. 라이브러리들은 사용자의 프로그램과 링크되어, 실행이 가능한 완전한 프로그램을 이룬다. 이러한 링크는 대개 정적 연결되지만, 시스템에 따라 동적으로 연결(DLL)될 수도 있다.




source code and object code ; 원시코드와 목적코드

원시코드와 목적코드는 프로그램이 컴퓨터에서 실행되기 위한 준비를 위해 컴파일 되기 "이전"과 "이후" 버전을 가리킨다. 원시코드는 프로그래머에 의해 텍스트 편집기나 비주얼 개발도구로 작성된 프로그램 문장들로 구성되며, 하나의 파일로 저장된다. 예를 들면, C 언어를 사용하는 프로그래머는 원하는 C 언어문장을 텍스트 편집기에 키보드로 입력한 뒤, 파일이름을 붙여서 저장한다. 바로 이 파일이 "원시코드"를 저장하고 있는 파일이다. 그것은 이제 C 컴파일러에 의해 컴파일될 준비가 된 것이며, 컴파일의 결과물, 즉 컴파일된 파일이 바로 "목적코드"라고 불린다. 목적코드 파일은 프로세서가 이해할 수 있는 명령어의 형태를 가지고 있기 때문에 사람들은 그것을 읽거나 수정하기 어렵다. 바로 이런 이유 때문에, 원시코드가 대부분 영원히 보존해야하는 프로그램으로 간주되는 것이다.

일반적으로 사용자들이 운영체계나 응용소프트웨어를 구매하거나 받을 때, 보통 컴파일된 목적코드의 형태만을 받게 되며, 여기에 원시코드는 포함되지 않는다. 대개 저작권이 걸린 소프트웨어 공급자들은 별도의 추가비용이 마련되지 않는 한 보통 자신의 코드를 개선시키는 노력을 하려하지 않는다. 최근, 기능개선을 위해 원시코드가 제공되는 개방형 소프트웨어를 개발하는 움직임이 있는데, 리눅스와 같은 소프트웨어가 그 예이다.

대형 프로그램 개발환경에서는 흔히, 프로그래머들이 각기 다른 원시코드 파일들의 상태나 수준을 기억하고 분류하는데 도움을 주는 관리시스템이 있다. Perl이나 자바스크립트와 같이 컴파일되지 않는 스크립트형 언어에서 원시코드나 목적코드라는 용어는 적용되지 않는데, 왜냐하면 그것들에는 오직 한가지 형태의 코드만이 존재하기 때문이다.

 
 

'Development > Common' 카테고리의 다른 글

유니코드(UNICODE) & 엔코딩(Encoding)  (1) 2012.01.19
utf-8 & euc-kr  (0) 2012.01.19
IIOP  (0) 2012.01.16
CORBA  (0) 2012.01.16
XML  (0) 2012.01.16
Posted by linuxism
,