이전 글에서
journalling과 ReiserFS의 장점과
Linux 2.4 기반의 ReiserFS 시스템을 설치하는 방법을 설명하였다. 이번에는 색다른 주제를 다루려고 한다. 우선 가상 메모리 (VM) 파일시스템으로 알려져있는 tmpfs를 살펴 볼 것이다. tmpfs 는 아마도 Linux에서 사용 가능한 RAM disk와 같은 최상의 시스템일 것이다. 그리고 이것은 커널 2.4의 새로운 기능이다. 또한 그런다음 2.4의 새로운 또 하나의 기능인 "bind mounts"에 대해 살펴볼 것이다. 이것은 파일시스템을 마운트 (리마운트) 할 때 상당한 유연성을 발휘한다. 다음 회에는 devfs에 대해 집중적으로 살펴보고 ext3 파일시스템을 숙지할 것이다.
tmpfs
tmpfs를 한마디로 설명해야 한다면, ramdisk와 같으면서도 다르다고 말해야 할 것 같다. ramdisk와 비슷한 점은, tmpfs는 RAM을
사용할 수 있다는 것이고, 다른점은 저장을 위해 swap 디바이스들을 사용할 수 있다는 것이다. 기존의 ramdisk 는 블록(block) 디바이스이고, 실제로 그것을 사용하려면
mkfs 명령어가 필요하지만, 반면 tmpfs는 파일시스템이다. 블록(block) 디바이스가 아니다; 마운트하면 바로 존재하게 된다. 이러한 사실 때문에 tmpfs가 훌륭한 RAM 기반의 파일시스템이 될 수 있는 것이다.
tmpfs & VM
이제, 좀 더 재미있는 tmpfs의 기능들을 살펴보자. 앞서 언급했지만 tmpfs는 RAM과 swap 모두를 사용할 수 있다. 언뜻 듣기에는 약간 제멋대로라는 생각이 들지만 tmpfs가 "가상 메모리 파일시스템"이라는 점을 기억하라. 또한 여러분도 알고 있듯이, Linux 커널의 가상 메모리 리소스는 RAM과 swap 장치에서 나온다. 커널의 VM 서브시스템(subsystem)은 이러한 리소스들을 시스템의 다른 부분에 할당하고, 리소스들을 막후에서 관리한다. 종종 투명하게 RAM 페이지를 swap으로 또는 그 반대로 옮긴다.
tmpfs 파일시스템은 파일을 저장하기 위해서 VM 서브시스템에 페이지를 요청한다. tmpfs 자체로는 이러한 페이지가 swap 상에 있는지 또는 RAM에 있는지 알지 못한다; 그러한 결정을 하는것은 VM 서브시스템의 역할이다. tmpfs 파일시스템이 인식하고 있는 것은 이것이 특정 형식의 가상 메모리를 사용하고 있다는 것이다.
블록(block) 디바이스가 아니다!
tmpfs 파일시스템의 또 다른 재미있는 특징이 있다. ext3, ext2, XFS, JFS, ReiserFS 등의 "평범한" 파일시스템과는 달리 tmpfs는 블록 디바이스에 존재하지 않는다. tmpfs는 VM에 직접 설치되기 때문에 간단한 마운트 명령어로 tmpfs 파일시스템을 구현 할 수 있다:
# mount tmpfs /mnt/tmpfs -t tmpfs
|
이 명령어를 실행시키면 /mnt/tmpfs에 마운트 된 새로운 tmpfs 파일시스템을 갖게되는 것이다.
mkfs.tmpfs를 실행시킬 필요가 없다는 것에 주목하라. 사실, 이것은 불가능하다. 그와 같은 명령어가 존재하지 않는다.
mount 명령어로 파일시스템은 마운트 되어 사용할 수 있게 된다. 그리고 이것은
tmpfs 타입이다. 이것은 Linux ramdisk가 사용되는 방식과는 상당히 다르다; 표준 Linux ramdisk들은
블록 디바이스이다. 따라서 사용하기 전에 여러분이 선택한 파일시스템으로 포맷되어야 한다. 반면 tmpfs는
파일시스템이다. 따라서 마운트하여 실행시키면 된다.
tmpfs 장점
동적으로 변하는 파일시스템 사이즈
/mnt/tmpfs에 마운트 된 tmpfs 파일시스템 크기가 궁금할 것이다. /mnt/tmpfs는 처음에는 매우 작은 용량이다. 하지만 파일이 복사되고 생성되면서 tmpfs 파일시스템 드라이버는 좀 더 많은 VM을 할당하고 필요한 만큼 파일시스템 용량을 동적으로 늘린다. 그리고, 파일들이 /mnt/tmpfs에서 제거되면 tmpfs 파일시스템 드라이버는 파일시스템의 크기와 VM 리소스를 줄인다. 이렇게 VM이 동적으로 존재하면서 필요할 때마다 시스템의 다른 부분에 의해 사용될 수 있다. VM은 소중한 리소스이기 때문에 실제 필요한 것보다 더 많은 VM을 요구하는 어떤 것도 원하지 않을 것이다. tmpfs의 또 하나의 멋진 기능은 이 모든 것이 자동으로 수행된다는 것이다.
참고자료 참조.
속도
tmpfs의 장점 중 하나는 놀라운 속도이다. 일반적인 tmpfs 파일시스템은 RAM에 존재하기 때문에, 읽기 및 쓰기는 거의 동시에 이루어 질 수 있다. 비록 어느 정도의 swap이 사용되더라도, 성능은 여전히 우수하고 더 많은 VM 리소스를 사용할 수 있을 때 tmpfs 파일시스템의 일부는 RAM으로 옮겨질 것이다. VM 서브시스템이 tmpfs 파일시스템의 일부를 swap으로 자동적으로 옮기는 것은 실제로 성능에
좋은 영향을 미친다. 왜냐하면 VM 서브시스템은 이것을 필요로하는 프로세스를 위해 RAM을 남겨둘 수 있기 때문이다. 이것은 동적 크기조절 기능과 함께 전체 OS 퍼포먼스와 유연성에 기여할 수 있게 된다. 기존의 RAM 디스크를 사용하는 것보다 훨씬 낫다.
지속성이 없다!
제목 자체의 뉘앙스로는 장점을 이야기하는 것 같지 않지만 tmpfs 데이터는 재부팅 중에는 보존되지 않는다. 가상 메모리라는 것이 본질적으로 휘발성이 있기 때문이다. 여러분도 지금 tmpfs가 어떤 의미에서 "tmpfs" 로 불리게 되었는지를 생각하고 있을 것이다. 하지만 실제로 이것은 매우 좋은 것이다. 임시 파일(/tmp)과 /var 파일시스템 트리와 같은 저장하고 싶지 않은 데이터를 보존하기에는 더없이 훌륭한 파일시스템이다.
tmpfs 사용하기
tmpfs를 사용하기 위해서는 "가상 메모리 파일시스템 지원 (이전의 shm fs)"이 가능한 2.4 시리즈 커널이 필요하다; 이 옵션은 kernel 설정의 "File systems" 섹션에 존재한다. 사실상 tmpfs의 사용 여부와 관계없이 2.4 커널에 tmpfs가 지원된다는 것은 좋은 일이다. 왜냐하면 POSIX 공유 메모리를 사용하기 위해서 커널이 tmpfs를 지원해야 하기 때문이다.
System V 공유 메모리는 커널에 tmpfs가 없이도
작동할 것이다. POSIX 공유 메모리를 작동시키기 위해서 tmpfs 파일시스템을 마운트하지 않아도 된다는 것에 주목하라. 커널에 지원되는 것으로 충분하다. POSIX 공유 메모리는 많이 사용되지 않는다.
low VM 문제 방지
tmpfs가 필요한 만큼 동적으로 늘어나고 줄어든다는 사실에 한가지 의문점이 생긴다: 만일 tmpfs 파일시스템이 모든 가상 메모리를 소진 할 지점까지 이르면 어떻게 하겠는가? 그리고 남아있는 RAM이나 swap도 없다면? 재미없는 상황이다. 2.4.4 커널과 같은 경우 커널이 즉시 잠긴다. 2.4.6 커널은 VM 서브시스템은 여러 방법으로 픽스된다. VM을 소진하는 것은 훌륭한 경험은 아니지만 그렇다고 해서 그것이 완전히 잘못된 것은 아니다. 2.4.6 커널이 더이상 VM을 할당할 수 없더라도 분명히 tmpfs 파일시스템에 새로운 데이터를 작성할 수 없다. 또한 시스템 상의 다른 프로세스들에 많은 메모리를 할당할 수 없을 것이다; 일반적으로 이것은 시스템이
극도로 느려지고 반응도 느려진다는 것을 의미한다. 따라서 이러한 low-VM 컨디션을 완화시키기 위해서 필요한 조치를 취하는 것이 시간 낭비일 뿐이다.
게다가, 커널은 더 이상 어떤 것도 가능하지 않을 때 메모리를 없애는 "last-ditch" 시스템이다; VM 리소스를 요구하고 있는 프로세스를 찾으면 죽인다. 불행하게도 이러한 "프로세스를 죽이는" 솔루션은 tmpfs의 증가가 VM 소진에 지대한 영향을 끼칠 때는 역작용을 한다. 여기 그 이유가 있다. tmpfs 스스로는 죽을 수가 없다. (죽어서도 안된다) 왜냐하면 이것은 커널의 일부이지 유저 프로세서가 아니기 때문이다. 그리고 커널이 어떤 프로세스가 tmpfs 파일시스템을 차지하고 있는지 알아내는 것도 쉬운 일은 아니다. 그래서 커널이 실수로 가장 큰 VM-hog 프로세스를 찾아서 공격했다면 이것은 일반적으로 X server 이다. X server가 죽으면 root는 low-VM (tmpfs)을 유발한다.
Low VM: 솔루션
다행스럽게도, tmpfs 파일시스템이 마운트 또는 리마운트 될 때 파일시스템의 최대 사이즈를 지정할 수 있다. 실제로 2.4.6 커널과 util-linux-2.11g 에서는
마운트하면서 이러한 파라미터를 설정할 수 있다. 리마운트 시에는 되지 않는다. 리마운트 할 때에도 설정할 수 있기를 기대해 본다. 최대 tmpfs 사이즈 세팅은 리소스와 Linux의 사용 패턴에 따라 다르다; 이렇게 차이를 두는 이유는 전체 tmpfs 파일시스템이 모든 가상 메모리를 다써버리지 않도록 하며, 앞서 언급한 반갑지 않은 low-VM 유발 방지를 위해서이다. 알맞은 tmpfs의 최대 한계를 찾는 좋은 방법은 'peak time' 동안에 시스템의 swap 사용을 감시하는 것이다. 그런다음 'peak time' 동안 남아있는 swap과 RAM을 합한 것 보다 근소하게 작은 tmpfs 사이즈 한계를 지정한다.
최대 크기의 tmpfs 파일시스템을 만드는 것은 쉽다. 32 MB의 새로운 tmpfs 파일시스템을 만들어보자:
이번에는 /mnt/tmpfs에 새로운 tmpfs 파일시스템을 마운트시키는 대신 /dev/shm에 마운트했다. 이것은 tmpfs 파일시스템을 위한 "공식적인" 마운트포인트가 될 수 있다. devfs를 사용 할 경우 이 디렉토리가 이미 설정되있다는 것을 알게 될 것이다.
또한 파일시스템 크기를 512 KB 또는 1 GB로 제한하고 싶다면
size=512k와
size=1g 로 각각 지정하면 된다. 사이즈 뿐만 아니라 inode (파일시스템 객체)의 수도 제한 할 수 있다.
nr_inodes=x 파라미터를 지정하면 된다.
nr_inodes를 사용할 경우,
x 자리에 간단한 정수가 올 수 있고, 수 천, 수 백만, 수십억개(!)의 inode를 지정하고 싶다면
x 자리에 각각
k,
m,
g 가 오도록 한다.
mount tmpfs 명렁어에 해당하는 것을 여러분의 /etc/fstab 에 추가하려면 다음과 같이 한다:
tmpfs /dev/shm tmpfs size=32m 0 0
|
기존 마운트포인트(mountpoint)에 마운트하기
2.2 커널과 같은 경우, 어떤 것이 이미 설치되어있는 마운트포인트에 마운트를 시도할 때 에러가 나타난다. 하지만, 커널 마운팅 코드가 다시 작성되었기 때문에 마운트포인트를 여러번 사용하는 것은 이제 문제가 아니다. 다음과 같은 시나리오를 설정해 보자; /tmp에 파일시스템이 마운트가 되어있다. 하지만 tmpfs를 사용하기로 결정했다. 옛날에는 /tmp 를 언마운트 하고 새로운 tmpfs /tmp 파일시스템을 그 자리에 리마운트(remount) 하는 방법 밖에 없었다:
# umount /tmp
# mount tmpfs /tmp -t tmpfs -o size=64m
|
하지만 이러한 솔루션은 아무 소용이 없다. /tmp에 'open file'을 가지고 있는 많은 실행 프로세가 있을 수도 있다; 만일 그렇다면, /tmp를 언마운트 하려고 할 때 다음과 같은 에러가 나온다:
umount: /tmp: device is busy
|
하지만 최근의 2.4 커널에서는, "device is busy" 에러 없이 새로운 /tmp 파일시스템을 마운트 할 수 있다:
# mount tmpfs /tmp -t tmpfs -o size=64m
|
단일 명령어를 사용하여 이미 마운트 된 파티션인 /tmp의 탑(top)에 새로운 tmpfs /tmp 파일시스템이 마운트된다. 여기에는 더이상 직접적으로 액세스 되지 않는다. 하지만 원래의 /tmp에 액세스 할 수 없더라도, 원래의 파일시스템상에 있었던 모든 프로세스는 지속적으로 액세스 할 수 있다. 그리고 만일 tmpfs 기반의 /tmp를
umount 하면 원래 마운트 된 /tmp 파일시스템은 다시 나타날 것이다. 사실, 같은 마운트포인트에 여러개의 파일시스템을 마운트 할 수 있다. 그리고 그러한 마운트포인트는 스택(stack)처럼 작용할 것이다; 현재의 파일시스템을 언마운트하면 최근 마운트 된 바로 밑에 있는 파일시스템이 다시 나타날 것이다.
bind mount
bind 마운트를 사용하면, 모든 것을 마운트 하거나, 이미 마운트 된 파일시스템의 일부를 다른 장소에 마운트 할 수 있고 동시에 양 마운트포인트에 파일시스템을 액세스 할 수 있다. 예를 들어, 기존의 root 파일시스템을 /home/drobbins/nifty에 마운트하기 위해서 bind 마운트를 사용해 보자:
# mount --bind / /home/drobbins/nifty
|
/home/drobbins/nifty를 자세히 살펴보면, root 파일시스템(/home/drobbins/nifty/etc, /home/drobbins/nifty/opt)을 볼 수 있을 것이다. root 파일시스템 상에서 파일을 수정한다면, /home/drobbins/nifty 에서도 수정이 된다는 것을 알 수 있다. 왜냐하면 그들은 하나이고 같은 파일시스템이기 때문이다. 커널은 두 개의 다른 마운트포인트에 파일시스템을 매핑(mapping)한다. 다른 장소에 파일시스템을 마운트 할 때, bind-mounted 파일시스템 내부에 있는 마운트포인트에 마운트 된 모든 파일시스템들은 함께 움직이지 않는다. 다시 말해서, 각 파일시스템에 /usr이 있다면, 앞서 수행한 bind mount는 /home/drobbins/nifty/usr를 빈 공간으로 남겨둘 것이다. 추가적인 bind 마운트 명령어를 사용하여 /home/drobbins/nifty/usr에 있는 /usr 의 내용을 검색할 수 있다:
# mount --bind /usr /home/drobbins/nifty/usr
|
파일시스템의 bind mounting
Bind mounting에는 더욱 멋진 기능이 있다. /dev/shm에 마운트 된 tmpfs 파일시스템이 있다고 하자. 현재 root 파일시스템에 있는 /tmp의 tmpfs를 사용하기로 결정했다. 새로운 tmpfs 파일시스템을 /tmp에 마운트 하지 않고 현재 마운트 된 /dev/shm 파일시스템을
공유하기 위해서 새로운 /tmp를 사용하기로 결정했다. /dev/shm을 /tmp에 bind mount 할 수 있지만, /dev/shm 에는 /tmp에 나타나지 않기를 바라던 몇 개의 디렉토리가 포함되어 있다. 그렇다면 어떻게 하겠는가? 다음과 같은 방법을 보자:
# mkdir /dev/shm/tmp
# chmod 1777 /dev/shm/tmp
# mount --bind /dev/shm/tmp /tmp
|
예제를 보면, 우선 /dev/shm/tmp 디렉토리를 만들고, 그 다음 여기에
1777 perms를 주었다. 이것은 /tmp에 적절한 권한이다. 디렉토리가 준비되었다면 /tmp에 /dev/shm/tmp와 /dev/shm/tmp를 마운트 할 수 있다. /tmp/foo 가 /dev/shm/tmp/foo로 매핑되는 동안 /tmp에서 /dev/shm/bar 파일로 액세스 할 방법이 없다.
bind mounts는 매우 강력하고 파일시스템 레이아웃을 쉽게 수정할 수 있다. 다음에는 devfs에 대해서 살펴보도록 하자.
참고자료
여행
윈도우서버 
