vinum(4)

명칭
vinum - 논리 볼륨 매니저

서식
kldload vinum kldload Vinum

해설
vinum (은)는 논리 볼륨 매니저입니다. Veritas Volume Manager 에 환기되고 있습니다만 직접 유래하는 것이 아닙니다. 이것은 다음과 같은 기능을 제공합니다.

•   디바이스에 의존하지 않는 논리 디스크를 제공합니다. 이것을볼륨라고 부릅니다. 볼륨은 시스템내의 디스크의 크기에 제한되지 않습니다.

•   볼륨은 1 개 이상의프렉스로부터 구성됩니다. 각 프렉스는 볼륨의 전address 공간을 가집니다. 이것은 RAID-1 (밀러)의 실장을 나타냅니다. 복수의 프렉스를 사용하는 것으로 이하와 같은 효과가 있습니다.

    •   읽기 throughput의 향상. vinum (은)는 가장 액세스의 적은 디스크로부터 데이터를 읽어내므로, 복수의 디스크로부터 되는 프렉스를 가지는 볼륨이라면 보다 많은 데이터를 병렬에 읽어내는 것이 가능합니다. vinum (은)는 1 프렉스로부터 마셔 데이터를 읽어냅니다만, 모든 프렉스에 대해서 데이터를 기입합니다.

    •   신뢰성의 향상. 다른 디스크상의 복수의 프렉스에 격납하는 것으로써, 프렉스 중 1 개가 이용 불능이 되었다고 해도 데이타를 뽑기 시작할 수 있겠지요. RAID-5 프렉스 (아래와 같이 참조)와 비교해, 복수의 프렉스는 보다 많은 스토리지 area를 필요로 합니다만, 퍼포먼스가 우수합니다. 특히 드라이브 고장때의 차이는 현저하겠지요.

    •   장황한 프렉스를 이용해, 온라인 상태 데이터 재구성을 할 수 있습니다. 어느 프렉스를 결합해, 계속되어 낡은 프렉스의 1 개를 분리하는 것으로써, 액세스를 방해하는 일 없이 온라인으로 데이터를 이동할 수 있습니다.

    •   장황한 프렉스에 의해, 일관성을 가진 파일 시스템 덤프를 얻을 수 있습니다. 프렉스를 결합해, 어떤 시점에 분리하는 것으로써, 분리된 프렉스는 분리한 시점에 있어서의 파일 시스템의 정확한 snapshot가 됩니다.

•   각 프렉스는, 서브 디스크로 불리는, 1 개(살) 이상의 논리 디스크 슬라이스로부터 구성됩니다. 서브 디스크는 물리 디스크가 연속한 블록으로서 정의됩니다. 프렉스는 모든 적절한 수의 서브 디스크로 구성할 수 있습니다. (바꿔 말하면, 진짜 제한은 서브 디스크의 수는 아니고 다른 요인, 많은 서브 디스크의 관리에 관한 메모리나 퍼포먼스라고 한 것입니다)

•   서브 디스크와 프렉스의 사이의 편성에는 몇개의 종류가 있습니다:

    •   콘카치네이트화 프렉스는 1 개(살) 이상의 서브 디스크로부터 되어, 각 서브 디스크 (은)는 프렉스의 address 공간 중(안)에서 연속한 부분으로서 편성됩니다.

    •   스트라이프화 프렉스는 2 개(살) 이상의, 크기의 동일한 서브 디스크로부터 됩니다. 파일의 address 공간은스트라이프에, 즉 서브 디스크의 크기의 정수 분의 1 에, 대응 붙일 수 있습니다. 연속한 프렉스아드레스뗴듩에는, 각 서브 디스크의 스트라이프가 차례로 대응 붙일 수 있습니다. 스트라이프화 프렉스의 서브 디스크는 모두 같은 크기일 필요가 있습니다.

    •   RAID-5 프렉스에는 크기의 동일한 서브 디스크가, 적어도 3 개(살)은 필요합니다. 이것은 스트라이프화 프렉스를 닮아 있습니다만, 각 스트라이프 중(안)에서 1 개의 서브 디스크 하지만 패리티 정보를 가지고 있는 점이 다릅니다. 패리티 정보를 가지는 서브 디스크는 스트라이프에 따라서 다릅니다. 1 번째의 스트라이프에서는 1 번째의 서브 디스크, 2 번째의 스트라이프에서는 2 번째의 서브 디스크 와 같이 됩니다. 단일 디스크 고장의 경우, vinum (은)는 나머지의 서브 디스크에 격납되고 있는 정보로부터 데이터를 복원합니다. 이 편성은 읽기가 집중하는 액세스에 특별히 향하고 있습니다. RAID-5 프렉스의 서브 디스크는 모두 같은 크기일 필요가 있습니다.

•   드라이브 (은)는 스토리지 계층 중(안)에서 가장 저레벨인 물건입니다. 이것은 디스크 특수 디바이스를 나타냅니다.

•   vinum (은)는 자동 기동 기능을 제공합니다. 통상의 UNIX 파일 시스템과 달리, vinum 볼륨내에 모든 설정 정보를 가지고 있기 (위해)때문에, 하부조직이 이용 가능하게 되었을 때에 올바르게 기동하는 것을 프로텍션할 수 있습니다. 이 점이 Veritas™ File System 에 대한 중요한 이점이기도 합니다. 이 기능은 볼륨의 존재를 검출합니다. 이것은, 볼륨을 자동적으로 mount 한다고 하는 의미가 아닙니다. mount를 실행하는 것은, 통상의 /etc/fstab 에 의한 기동 순서입니다.

커널의 설정
vinum (은)는 현재 커널 로드 가능 모듈 (kld)로서 제공되고 있어 커널의 설정은 불필요합니다. 다른 kld 와 같이, kld 는 OS 의 버젼과 절대로 적합할 필요가 있습니다. 그렇지 않으면 vinum (은)는 에러 메세지를 출력해 종료하겠지요.

vinum 에는 현재 2 개의 버젼이 있습니다. 그것은, RAID-5 기능을 가지지 않는 자유롭게 입수 가능한 버젼과 RAID-5 의 기능을 가지는 완전한 버젼입니다. 완전한 버젼은 Cybernet Systems Inc. (http://www.cybernet.com)(으)로부터 입수 가능합니다.

VINUM 의 기동
통상, 설정된 버젼의 vinum (을)를 부트시에 기동시킵니다. /etc/rc.conf 안의 변수 vinum_drives 에 vinum 드라이브가 놓여져 있는 슬라이스를 설정합니다. 예를 들면, vinum 드라이브가 /dev/da1h, /dev/da2h, /dev/da3h, /dev/da4h, /dev/da5h 에 있다고 하면(자), 이 변수를 다음과 같이 설정합니다.

    vinum_drives="/dev/da1 /dev/da2 /dev/da3 /dev/da4 /dev/da5"

VINUM 의 인스톨
자유롭게 입수 가능한 버젼의 vinum kld 는 /modules/vinum.ko (이어)여, RAID-5 버젼의 kld 는 /modules/Vinum.o 입니다. 모듈을 로드하려면 다음의 명령을 실행합니다:

    # kldload vinum

또 vinum(8) (은)는 로드되어 있지 않으면 kld 모듈을 자동적으로 로드합니다.

vinum (을)를 로드한 후, 설정을 실행할 필요가 있습니다. 벌써 인스톨이 끝나 있으면, 다음의 명령에 의해, 존재하는 디스크 집합으로부터 설정을 읽어냅니다.

    # vinum read /dev/da1 /dev/da2 /dev/da3 /dev/da4 /dev/da5 /dev/da6

이 명령에서는 vinum 에 의해 사용되는 모든 디바이스를 지정할 필요가 있습니다. vinum(8) (은)는, 최신의 설정 파일을 사용해, 설정을 디바이스보다 읽어냅니다. 계속해, 보다 낡은 설정으로부터 얻을 수 있던 추가 정보가 있으면, 설정을 갱신합니다. 이러한 명령은 통상, 기동 파일 /etc/rc 에 파묻히고 있습니다.

vinum 설정을 작성하는 방법에 대해서는 vinum(8) (을)를 참조해 주세요.

kld 를 언로드하려면 , 우선 kldstat 그리고 Id 필드를 찾습니다.

    # kldstat
    Id Refs Address    Size     Name
     1    2 0xf0100000 1c7de8   kernel
     2    1 0xf0f5b000 b0000    Vinum.ko

모듈을 언로드하려면 kldunload (을)를 사용합니다:

    # kldunload -n Vinum

kld 를 언로드할 수 있는 것은 아이돌중, 바꿔 말하면(자) 볼륨이 mount 되지 않고, 다른 vinum 프로그램의 인스턴스가 액티브하지 않을 때만입니다. kld 의 언로드는 볼륨내의 데이터를 파괴하지 않습니다.

  오브젝트의 설정과 기동
vinum 오브젝트의 설정과 기동에는, vinum(8) 유틸리티를 사용해 주세요.

IOCTL 호출
ioctl 호출은 vinum 설정 프로그램만이 사용하도록(듯이) 설계되고 있습니다. 헤더 파일 /sys/sys/vinumio.h 에 설명이 있습니다.

  디스크 label
전통적인 디스크 특수 디바이스는 디스크 label (을)를 디바이스의 제 2 섹터에 가지고 있습니다. 상세한 것에 대하여는 disklabel(5) (을)를 참조해 주세요. 이 디스크 label에는 디바이스내의 파티션 정보가 기술되고 있습니다. vinum (은)는 볼륨을 한층 더 분할할 것은 없기 때문에, 볼륨에는 물리 디스크 label (이)가 없습니다. 편리이기 때문에, vinum 에는 ioctl 호출 DIOCGDINFO (디스크 label의 취득), DIOCGPART (파티션 정보의 취득), DIOCWDINFO (파티션 정보의 기입), DIOCSDINFO (파티션 정보의 설정)(이)가 실장되고 있습니다. DIOCGDINFO 와 DIOCGPART 는 내부적인 디스크 label 정보를 참조합니다만, 이것은 볼륨내에는 존재하지 않습니다. 따라서, disklabel(8) 의 -r 옵션은, 생의 디스크 정보를 읽으므로, 실패하겠지요.

일반적으로, disklabel(8) (은)는 vinum 볼륨에 있어 유용한 효과는 없습니다. 만약 동작시키면(자), disklabel 는 3 개의 파티션 a, b, c 를 표시해, fstype 를 제외해 이것들은 같게 되겠지요. 예를 들면 이하와 같이 표시됩니다:

    3 partitions:
    #        size   offset    fstype   [fsize bsize bps/cpg]
      a:     2048        0    4.2BSD     1024  8192     0   # (Cyl.     0 - 0)
      b:     2048        0      swap                        # (Cyl.     0 - 0)
      c:     2048        0    unused        0     0         # (Cyl.     0 - 0)

vinum (은)는 DIOCWDINFO 와 DIOCSDINFO 의 ioctl 를 무시합니다. 즉 아무것도 변경하지 않습니다. 따라서, 디스크 label를 변경하려고 하면(자) 아무 표시도 없게 무시되겠지요.

파일 시스템의 작성
vinum 볼륨은 파티션을 가지지 않기 때문에, 볼륨의 이름에 관해서 디스크 파티션의 이름부의 통상의 룰에 따를 필요는 없습니다. 물리 디스크 패티션에 대해서는, 디바이스명의 마지막 캐릭터는 파티션 식별자 (a 로부터 h)를 지정합니다. vinum 볼륨은 이 규칙에 따를 필요는 없습니다. 그러나 따르지 않았던 경우, newfs 하지만 파티션의 식별을 할 수 없으면 불평하겠지요. 이 문제를 해결하려면 newfs 에 대해서 -v 플래그를 지정해 주세요.

오브젝트의 이름 붙어라
vinum (은)는 디폴트의 이름을 프렉스와 서브 디스크에 할당합니다. 이 이름을 덧쓰기하는 일도 가능합니다. 그러나 디폴트의 이름을 덧쓰기하는 것은 추천 하지 않습니다. 오브젝트에 임의의 이름을 붙일 수 있다 Veritas(tm) volume manager 의 사용 경험으로부터 하면(자), 이러한 자유도에 큰 이점은 없고, 혼란을 일으키겠지요.

이름에는 공백이 아닌 임의의 캐릭터를 사용할 수 있습니다만, 영숫자와 언더스코어에만 제한하는 것을 권합니다. 볼륨, 프렉스, 서브 디스크의 이름에는 64 캐릭터까지, 또 드라이브의 이름에는 32 캐릭터까지 사용할 수 있습니다. 볼륨과 프렉스의 이름을 선택할 때에는, 자동적으로 생성되는 프렉스명과 서브 볼륨명이, 이러한 전이 되는 이름보다 길어지는 것에 주의해 주세요.

•   vinum(8) 하지만 오브젝트를 생성 또는 삭제하면(자), 디렉토리 /dev/vinum (을)를 작성해, 그 중에 vinum 가 검출한 각 볼륨에 대응한다 디바이스 엔트리를 작성합니다. 또, vinum 는 서브 디렉토리 /dev/vinum/plex (와)과 /dev/vinum/sd (을)를 작성해, 그 중에 프렉스와 서브 디스크에 대응하는 디바이스 엔트리를 격납합니다. 더욱, vinum 는 2개의 디렉토리 /dev/vinum/vol (와)과 /dev/vinum/drive (을)를 작성해, 그 중에 볼륨과 드라이브에 대한 계층적인 정보를 격납합니다.

•   UNIX 드라이브와 달리, vinum 볼륨을 파티션으로 한층 더 분할하지 않습니다. 따라서 디스크 label를 가지지 않습니다. 불행한 일에, 이것에 달려 있고 구두인가의 유틸리티, 특히 newfs (은)는 혼란합니다. newfs (은)는 통상 vinum 볼륨명의 마지막 캐릭터를 파티션 식별자로서 해석하려고 하기 때문입니다. a (으)로부터 c 의 캐릭터로 끝나지 않는 캐릭터 라인을 볼륨명에 사용했을 경우에는, newfs 에 대해서 -v 플래그를 지정해 이 규칙을 무시하는 듯 newfs 에 지시하는 것이 필요합니다.

•   프렉스에는 명시적으로 이름을 할당할 필요는 없습니다. 디폴트의 프렉스 이름은 볼륨명에 캐릭터 라인 .p 와 프렉스의 번호를 계속한 것입니다. 예를 들면, 볼륨 vol3 의 프렉스는 vol3.p0, vol3.p1 그렇다고 하는 식으로 이름이 붙여집니다. 이 이름을 덧쓰기하는 것은 가능합니다만 추천하지 않습니다.

•   프렉스와 같이, 서브 디스크에 대해서도 자동적으로 이름을 할당할 수 있어 명시적인 이름부는 추천하지 않습니다. 서브 디스크명은 프렉스명에 캐릭터 라인 .s 와 서브 디스크 (을)를 식별하는 번호를 계속한 것입니다. 예를 들면, 프렉스 vol3.p0 의 서브 디스크는 vol3.p0.s0, vol3.p0.s1 그렇다고 하는 식으로 이름이 붙여집니다.

•   한편, 드라이브 (은)는 반드시 이름을 붙일 필요가 있습니다. 이것에 의해, 드라이브를 다른 장소로 이동했다 (이)라고 해도 자동적으로 인식하는 것이 가능하게 됩니다. 드라이브 네임의 길이는 32 캐릭터까지입니다.

사용예

vinum 오브젝트가 vinum(8) 의 설정 파일 예의 마디에 설명되고 있는 것이다고 합니다. 디렉토리 /dev/vinum (은)는 다음과 같이 보이겠지요:

    # ls -lR /dev/vinum/ /dev/rvinum
    total 5
    brwxr-xr--  1 root  wheel   25,   2 Mar 30 16:08 concat
    brwx------  1 root  wheel   25, 0x40000000 Mar 30 16:08 control
    drwxrwxrwx  2 root  wheel       512 Mar 30 16:08 drive
    drwxrwxrwx  2 root  wheel       512 Mar 30 16:08 plex
    drwxrwxrwx  2 root  wheel       512 Mar 30 16:08 rvol
    drwxrwxrwx  2 root  wheel       512 Mar 30 16:08 sd
    brwxr-xr--  1 root  wheel   25,   3 Mar 30 16:08 strcon
    brwxr-xr--  1 root  wheel   25,   1 Mar 30 16:08 stripe
    brwxr-xr--  1 root  wheel   25,   0 Mar 30 16:08 tinyvol
    drwxrwxrwx  7 root  wheel       512 Mar 30 16:08 vol
    brwxr-xr--  1 root  wheel   25,   4 Mar 30 16:08 vol5
    /dev/vinum/drive:
    total 0
    brw-r-----  1 root  operator    4,  15 Oct 21 16:51 drive2
    brw-r-----  1 root  operator    4,  31 Oct 21 16:51 drive4
    /dev/vinum/plex:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x10000002 Mar 30 16:08 concat.p0
    brwxr-xr--  1 root  wheel   25, 0x10010002 Mar 30 16:08 concat.p1
    brwxr-xr--  1 root  wheel   25, 0x10000003 Mar 30 16:08 strcon.p0
    brwxr-xr--  1 root  wheel   25, 0x10010003 Mar 30 16:08 strcon.p1
    brwxr-xr--  1 root  wheel   25, 0x10000001 Mar 30 16:08 stripe.p0
    brwxr-xr--  1 root  wheel   25, 0x10000000 Mar 30 16:08 tinyvol.p0
    brwxr-xr--  1 root  wheel   25, 0x10000004 Mar 30 16:08 vol5.p0
    brwxr-xr--  1 root  wheel   25, 0x10010004 Mar 30 16:08 vol5.p1
    /dev/vinum/rvol:
    total 0
    crwxr-xr--  1 root  wheel   91,   2 Mar 30 16:08 concat
    crwxr-xr--  1 root  wheel   91,   3 Mar 30 16:08 strcon
    crwxr-xr--  1 root  wheel   91,   1 Mar 30 16:08 stripe
    crwxr-xr--  1 root  wheel   91,   0 Mar 30 16:08 tinyvol
    crwxr-xr--  1 root  wheel   91,   4 Mar 30 16:08 vol5
    /dev/vinum/sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20000002 Mar 30 16:08 concat.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100002 Mar 30 16:08 concat.p0.s1
    brwxr-xr--  1 root  wheel   25, 0x20010002 Mar 30 16:08 concat.p1.s0
    brwxr-xr--  1 root  wheel   25, 0x20000003 Mar 30 16:08 strcon.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100003 Mar 30 16:08 strcon.p0.s1
    brwxr-xr--  1 root  wheel   25, 0x20010003 Mar 30 16:08 strcon.p1.s0
    brwxr-xr--  1 root  wheel   25, 0x20110003 Mar 30 16:08 strcon.p1.s1
    brwxr-xr--  1 root  wheel   25, 0x20000001 Mar 30 16:08 stripe.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100001 Mar 30 16:08 stripe.p0.s1
    brwxr-xr--  1 root  wheel   25, 0x20000000 Mar 30 16:08 tinyvol.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100000 Mar 30 16:08 tinyvol.p0.s1
    brwxr-xr--  1 root  wheel   25, 0x20000004 Mar 30 16:08 vol5.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100004 Mar 30 16:08 vol5.p0.s1
    brwxr-xr--  1 root  wheel   25, 0x20010004 Mar 30 16:08 vol5.p1.s0
    brwxr-xr--  1 root  wheel   25, 0x20110004 Mar 30 16:08 vol5.p1.s1
    /dev/vinum/vol:
    total 5
    brwxr-xr--  1 root  wheel   25,   2 Mar 30 16:08 concat
    drwxr-xr-x  4 root  wheel       512 Mar 30 16:08 concat.plex
    brwxr-xr--  1 root  wheel   25,   3 Mar 30 16:08 strcon
    drwxr-xr-x  4 root  wheel       512 Mar 30 16:08 strcon.plex
    brwxr-xr--  1 root  wheel   25,   1 Mar 30 16:08 stripe
    drwxr-xr-x  3 root  wheel       512 Mar 30 16:08 stripe.plex
    brwxr-xr--  1 root  wheel   25,   0 Mar 30 16:08 tinyvol
    drwxr-xr-x  3 root  wheel       512 Mar 30 16:08 tinyvol.plex
    brwxr-xr--  1 root  wheel   25,   4 Mar 30 16:08 vol5
    drwxr-xr-x  4 root  wheel       512 Mar 30 16:08 vol5.plex
    /dev/vinum/vol/concat.plex:
    total 2
    brwxr-xr--  1 root  wheel   25, 0x10000002 Mar 30 16:08 concat.p0
    drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 concat.p0.sd
    brwxr-xr--  1 root  wheel   25, 0x10010002 Mar 30 16:08 concat.p1
    drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 concat.p1.sd
    /dev/vinum/vol/concat.plex/concat.p0.sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20000002 Mar 30 16:08 concat.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100002 Mar 30 16:08 concat.p0.s1
    /dev/vinum/vol/concat.plex/concat.p1.sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20010002 Mar 30 16:08 concat.p1.s0
    /dev/vinum/vol/strcon.plex:
    total 2
    brwxr-xr--  1 root  wheel   25, 0x10000003 Mar 30 16:08 strcon.p0
    drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 strcon.p0.sd
    brwxr-xr--  1 root  wheel   25, 0x10010003 Mar 30 16:08 strcon.p1
    drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 strcon.p1.sd
    /dev/vinum/vol/strcon.plex/strcon.p0.sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20000003 Mar 30 16:08 strcon.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100003 Mar 30 16:08 strcon.p0.s1
    /dev/vinum/vol/strcon.plex/strcon.p1.sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20010003 Mar 30 16:08 strcon.p1.s0
    brwxr-xr--  1 root  wheel   25, 0x20110003 Mar 30 16:08 strcon.p1.s1
    /dev/vinum/vol/stripe.plex:
    total 1
    brwxr-xr--  1 root  wheel   25, 0x10000001 Mar 30 16:08 stripe.p0
    drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 stripe.p0.sd
    /dev/vinum/vol/stripe.plex/stripe.p0.sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20000001 Mar 30 16:08 stripe.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100001 Mar 30 16:08 stripe.p0.s1
    /dev/vinum/vol/tinyvol.plex:
    total 1
    brwxr-xr--  1 root  wheel   25, 0x10000000 Mar 30 16:08 tinyvol.p0
    drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 tinyvol.p0.sd
    /dev/vinum/vol/tinyvol.plex/tinyvol.p0.sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20000000 Mar 30 16:08 tinyvol.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100000 Mar 30 16:08 tinyvol.p0.s1
    /dev/vinum/vol/vol5.plex:
    total 2
    brwxr-xr--  1 root  wheel   25, 0x10000004 Mar 30 16:08 vol5.p0
    drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 vol5.p0.sd
    brwxr-xr--  1 root  wheel   25, 0x10010004 Mar 30 16:08 vol5.p1
    drwxr-xr-x  2 root  wheel       512 Mar 30 16:08 vol5.p1.sd
    /dev/vinum/vol/vol5.plex/vol5.p0.sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20000004 Mar 30 16:08 vol5.p0.s0
    brwxr-xr--  1 root  wheel   25, 0x20100004 Mar 30 16:08 vol5.p0.s1
    /dev/vinum/vol/vol5.plex/vol5.p1.sd:
    total 0
    brwxr-xr--  1 root  wheel   25, 0x20010004 Mar 30 16:08 vol5.p1.s0
    brwxr-xr--  1 root  wheel   25, 0x20110004 Mar 30 16:08 vol5.p1.s1
    /dev/rvinum:
    crwxr-xr--  1 root  wheel   91,   2 Mar 30 16:08 rconcat
    crwxr-xr--  1 root  wheel   91,   3 Mar 30 16:08 rstrcon
    crwxr-xr--  1 root  wheel   91,   1 Mar 30 16:08 rstripe
    crwxr-xr--  1 root  wheel   91,   0 Mar 30 16:08 rtinyvol
    crwxr-xr--  1 root  wheel   91,   4 Mar 30 16:08 rvol5

프렉스나 서브 디스크를 분리했을 경우에는, 이 이름은 예약된 채로 있습니다. 서브 디스크는 그것이 배치되고 있는 디스크의 이름을 바탕으로 이름이 붙여져 프렉스는 서브 디스크의 이름을 바탕으로 이름이 붙여지고 있습니다. 이 대응부에게는 아직 고려의 여지가 있습니다.

  오브젝트 상태

각 vinum 오브젝트에는, 오브젝트에 관련 지을 수 있던상태가 있습니다. vinum (은)는 오브젝트에 대한 조작을 결정하기 위해서(때문에) 이 상태를 이용합니다.

  볼륨 상태
볼륨에는 다음 상태가 있습니다.

volume_down
    볼륨이 완전히 액세스 불능입니다.

volume_up
    볼륨은 기동하고 있어, 적어도 일부는 기능하고 있습니다. 모든 프렉스 하지만 이용 가능하다고는 할 수 없습니다.

  프렉스 상태
프렉스에는 다음 상태가 있습니다.

faulty
    프렉스는 I/O 에러에 의해 완전하게 정지하고 있습니다.

down
    프렉스는 관리자에 의해 정지 당하고 있습니다.

initializing
    프렉스는 초기화중입니다.

    이하 상태는, 프렉스의 적어도 일부는 기동하고 있는 것을 나타냅니다.

corrupt
    프렉스엔트리는 적어도 일부는 기동하고 있습니다. 모든 서브 디스크가 이용 가능하지 않고, 일관성의 결여가 일어나고 있습니다. 만약 망가지지 않은 다른 프렉스가 없으면, 볼륨에는 이미 일관성이 없습니다.

degraded
    RAID-5 프렉스엔트리는 액세스 가능합니다만, 1 개의 서브 디스크가 정지하고 있어, 많은 I/O 요구를 위해서(때문에)는 수복이 필요합니다.

flaky
    프렉스는 정말로 기동하고 있습니다만, 복구된 서브 디스크를 가지고 있습니다. 이 서브 디스크는, 완전하게 믿을 수 없는 상태이며, 만약 피하는 것이 가능하면 읽고 싶지 않은 상태입니다.

up  프렉스엔트리는 완전하게 기동하고 있습니다. 모든 서브 디스크가 기동하고 있습니다.

  서브 디스크 상태
서브 디스크에는 다음 상태가 있습니다.

empty
    서브 디스크 엔트리는 완전하게 작성되었습니다. 모든 필드는 정상적이어, 디스크는 갱신되고 있습니다만, 디스크상에 데이터는 없습니다.

initializing
    서브 디스크 엔트리는 완전하게 작성되어 현재 초기화중입니다.

    이하 상태는, 무효인 데이터를 나타냅니다.

obsolete
    서브 디스크 엔트리는 완전하게 작성되었습니다. 모든 필드는 정상적이어, 디스크상의 설정은 갱신되어 데이터는 유효합니다만, 드라이브가 정지 당하고 있어 그 결과 갱신에 실패하고 있습니다.

stale
    서브 디스크 엔트리는 완전하게 작성되었습니다. 모든 필드는 정상적이어, 디스크는 갱신되어 데이터는 유효합니다만, 드라이브가 고장나고 있어 갱신이 없어지고 있습니다.

    이하 상태는, 유효하지만 액세스 할 수 없는 데이터를 나타냅니다.

crashed
    서브 디스크 엔트리는 완전하게 작성되었습니다. 모든 필드는 정상적이어, 디스크는 갱신되어 데이터는 유효합니다만, 드라이브가 정지하고 있습니다. 고장의 뒤서브 디스크에의 기입은 행해지지 않고, 그 때문에 데이터는 유효합니다.

down
    서브 디스크 엔트리는 기동하고 있어, 유효한 데이터를 가져, 관리자에 의해 정지 당하고 있습니다. 데이터는 유효합니다.

reviving
    서브 디스크는 현재 restore 작업중입니다. 기입은 가능합니다만, 읽기는 할 수 없습니다.

    이하 상태는, 유효한 데이터를 가지는 액세스 가능한 서브 디스크를 나타냅니다.

reborn
    서브 디스크 엔트리는 완전하게 작성되었습니다. 모든 필드는 정상적이어, 디스크는 갱신되어 데이터는 유효합니다만, 드라이브가 정지한 후 다시 기동한 상태입니다. 갱신은 전혀 없어지고 있지 않습니다만, 서브 디스크가 손상하고 있을 가능성이 있습니다. 선택의 여지가 있으면 이 서브 디스크로부터의 읽기는 실시하지 않을 것입니다. 만약 이 서브 디스크가 프렉스내에서 해당하는 address 공간을 커버하는 유일한 서브 디스크였던 경우, 그러한 상황하에서는 서브 디스크 상태를 up 로 설정 합니다. 따라서 이 상태는, 읽기 요구를 채우는 다른 서브 디스크가 존재하는 것을 의미합니다.

up  서브 디스크 엔트리는 완전하게 작성되었습니다. 모든 필드는 정상적이어, 디스크는 갱신되어 데이터는 유효합니다.

  드라이브 상태
드라이브에는 다음 상태가 있습니다.

down
    드라이브는 액세스 불능입니다.

up  드라이브는 기동하고 있어 동작중입니다.

버그와 실수

1.  vinum (은)는 새로운 프로덕트입니다. 많은 버그가 있겠지요. 설정의 메카니즘은 반드시 완전하게는 동작하고 있지 않습니다. 만약 곤란하면(자), 문제를 보고하기 전에 다음의 URL 를 참조해 주세요. http://www.lemis.com/vinum_beta.html 및 http://www.lemis.com/vinum_debugging.html

2.  vinum 모듈을 kldunload 명령을 사용해 언로드하는 것이 가능합니다. 그러나 이 조작에는 버그가 많아, 이 조작이 존재하는 이유는 단지 시스템을 테스트하는 사람이 하기 쉽게 하기 위한(해) 입니다. 대신 방법은 리부트입니다. 동작 확률은 약 80% 입니다. 즉 언로드의 5 회에 1 회는 패닉이 된다고 생각됩니다.

3.  vinum (을)를 정적으로 링크 한 커널을 구축할 수도 있습니다만, 이 방법은 전혀 테스트되고 있지 않습니다. 만약, vinum 의사 디바이스를 정적 링크 한 상태로 문제가 일어났을 경우에서도 kld 모듈 그리고 문제가 재현되지 않는 이상 일부러 문제를 보고하지 말아 주세요.

4.  RAID-5 프렉스는 초기화할 필요가 있습니다. 초기화를 하지 않아도, 통상의 운용의 방해로는 되지 않습니다만, 디스크 중 1 개가 고장났을 때에 전체의 파괴를 일으키겠지요. 이 초기화를 강제하기 위한이야 있고 방법 (또는 저속이라고 해도, 패리티 블록을 재구축 하는 대체 방법) 하지만 생각나지 않습니다. 무엇인가 좋은 아이디어가 있으면 제공을 환영합니다.

5.  커널과 kld 의 버젼의 상위를 검출하는 구조는 실장되고 있지 않습니다.

VINUM 에 관한 문제의 디버그

vinum 에 관한 문제의 해결은 어려운 일일지도 모릅니다. 이 마디에서는 몇개의 접근 (을)를 소개합니다.

  설정에 관한 문제

vinum 의 설정은, 비교적 (매우) 문제에 부딪치기 쉽다고 말할 수 있습니다. 문제가 일어나면(자), 우선 실시해야 한다 (일)것은 설정 정보의 갱신을 다음과 같이 해 멈추는 것입니다.

    # vinum setdaemon 4

이것에 의해 갱신과 디스크상의 설정의 한층 더 파괴를 멈추겠지요.

다음에, 디스크상의 설정을 확인합니다. Bourne 타입의 쉘로 다음과 같이 합니다.

    # rm -f log
    # for i in /dev/da0s1h /dev/da1s1h /dev/da2s1h /dev/da3s1h; do
    >    (dd if=/dev/da1h skip=8 count=6|tr -d '\000-\011\200-\377'; echo) >> log
    >  done

디바이스의 이름은, 모든 vinum 슬라이스의 이름입니다. 그렇다면, log 파일에는 다음과 같은 내용이 들어가 있을 것입니다.

    IN VINOpanic.lemis.comdrive1}6E7~^K6T^Yfoovolume obj state up
    volume src state up
    volume raid state down
    volume r state down
    volume foo state up
    plex name obj.p0 state corrupt org concat vol obj
    plex name obj.p1 state corrupt org striped 128b vol obj
    plex name src.p0 state corrupt org striped 128b vol src
    plex name src.p1 state up org concat vol src
    plex name raid.p0 state faulty org disorg vol raid
    plex name r.p0 state faulty org disorg vol r
    plex name foo.p0 state up org concat vol foo
    plex name foo.p1 state faulty org concat vol foo
    sd name obj.p0.s0 drive drive2 plex obj.p0 state reborn len 409600b driveoffset 265b plexoffset 0b
    sd name obj.p0.s1 drive drive4 plex obj.p0 state up len 409600b driveoffset 265b plexoffset 409600b
    sd name obj.p1.s0 drive drive1 plex obj.p1 state up len 204800b driveoffset 265b plexoffset 0b
    sd name obj.p1.s1 drive drive2 plex obj.p1 state reborn len 204800b driveoffset 409865b plexoffset 128b
    sd name obj.p1.s2 drive drive3 plex obj.p1 state up len 204800b driveoffset 265b plexoffset 256b
    sd name obj.p1.s3 drive drive4 plex obj.p1 state up len 204800b driveoffset 409865b plexoffset 384b

최초의 행은 vinum label를 포함하고 있어 IN VINO 그렇다고 하는 텍스트로 시작되어 있을 필요가 있습니다. 이 행에는 시스템의 이름도 포함되어 있습니다. 정확한 정의는 /usr/src/sys/dev/vinum/vinumvar.h 에 기재되어 있습니다. 보존된 설정은 이 행의 도중부터 volume obj state up 그렇다고 하는 텍스트로 시작되어 있습니다. 이것은 디스크의 섹터 9 로부터 시작되어 있습니다. 그 이후의 출력은 디스크상의 설정의 나머지의 부분을 나타내고 있습니다. 어쩌면 모든 설정을 보기 위해서(때문에)는, dd 명령의 count 의 인수를 늘릴 필요가 있을지도 모릅니다.

모든 디스크상의 설정은 같다라고 하는 것이 필요합니다. 그렇지 않은 경우에는, log 파일의 정확한 내용과 함께 문제를 보고해 주세요. 디스크상의 설정을 회복하기 위해서 할 수 있는 것은 아마 거의 없을 것입니다가, 만약 오브젝트를 생성했을 때에 사용한 파일의 카피를 보존되어 있으면, 오브젝트를 재생성할 수 있겠지요. create 명령은 서브 디스크의 데이터를 변경하지 않기 때문에, 이 커멘드는 데이터의 파괴를 일으키지 않습니다. 이런 종류의 문제를 만났을 경우에는, resetconfig 명령을 사용할 필요가 있을지도 모릅니다.

  커널 패닉

vinum 에 유래한다고 생각되는 패닉을 해석하려면 , 디버그용 커널을 구축할 필요 (이)가 있습니다. 디버그용 커널의 구축의 상세한 것에 대하여는, 온라인 핸드북 (을)를 참조해 주세요. vinum 커널 로드 가능 모듈의 심볼 정보를 얻으려면 , 더욱 작업이 필요합니다.

1.  가능하면, 디버그 커널의 카피 또는 링크를 /var/crash/kernel.gdb 에 작성합니다. 이것은 gdb 의 초기화 파일이 이 정도치를 검색하기 때문입니다.

2.  vinum 모듈을 디버그 정보와 함께 구축하고 있는 것을 확인합시다. 통상의 Makefile 이면, 이것은 디폴트의 설정입니다.

3.  vinum 개시 후, 다음의 명령을 실행합시다:

        echo add-symbol-file /modules/vinum.ko \
          0x`objdump --section-headers /modules/vinum.ko \
          | grep ' .text' \
          | awk '{print $4}'`+`kldstat \
          | grep vinum | awk '{print $3}'`

    이것을 파일에 격납해, 실행 가능하게 해, 실행하는 것이 가장 간단합니다. 출력은 다음과 같이 되겠지요:

        add-symbol-file /modules/vinum.ko 0x00005e24+0xf0f4e000

4.  /usr/src/sys/modules/vinum/.gdbinit.crash 파일을 당신이 해석을 실행하고 싶은 디렉토리 (예를 들면 /var/crash )에 카피해, .gdbinit 에 이름을 바꿉니다.

5.  /modules 에 놓여져 있는 버젼의 vinum 하지만 심볼을 포함하지 않으면 에러 메세지는 표시됩니다만, 스택 트레이스는 심볼을 표시하지 않습니다. gdb (을)를 시작하기 전에 모듈을 체크합시다.

        $ file /modules/vinum.ko
        /modules/vinum.ko: ELF 32-bit LSB shared object, Intel 80386,
          version 1 (FreeBSD), not stripped

    그 출력이 /modules/vinum.ko is stripped 였던 경우, strip 되어 있지 않은 버젼을 찾아낼 필요가 있습니다. 통상, /usr/obj/sys/modules/vinum/vinum.ko 의 안 ( make world (을)를 이용해 vinum (을)를 구축했을 경우) 인가 /usr/src/sys/modules/vinum/vinum.ko 의 안 (이 디렉토리에서 vinum (을)를 구축했을 경우)에 있습니다.

6.  만약 디버그 커널을 /var/crash/kernel.gdb (이)라는 이름으로 하고 있지 않은 경우에는, .gdbinit (을)를 편집해, 올바른 장소를 지시하도록 해 주세요. 시리얼 접속을 통해 리모트 디버그를 하고 있는 경우에는, /usr/src/sys/modules/vinum/.gdbinit.crash 파일을 .gdbinit (이)라는 이름으로 디버그를 실행하고 있는 디렉토리에 카피해, 다음의 명령로 기동해 주세요.

        gdb -k

    gdb (은)는 자동적으로 접속을 확립합니다. 리모트 머신은 그 시점에서 gdb 하지만 동작중이 아니면 안됩니다. 이 .gdbinit 파일은 시리얼 접속이 38400 bps 로 동작하는 것이라고 기대하고 있습니다. 다른 스피드로 동작시키고 싶은 경우에는, 이 파일을 적절히 편집해 주세요 ( remotebaud 에 관한 기술을 찾아 주세요).

7.  덤프를 취하거나 gdb (을)를 사용하는 것으로 문제를 분석해 주세요. 혹은 상기의 셸 스크립트의 출력 (을)를 이용해 주세요. 다음에 리모트 디버그의 세션으로 vinum(8) 에 있어서의 debug 명령의 이용예를 나타냅니다.

        (kgdb) add-symbol-file /usr/src/sys/modules/vinum/vinum.ko 0x00005e24+0xf0f4e000
        add symbol table from file "/usr/src/sys/modules/vinum/vinum.ko" at text_addr = 0xf0f53e24?
        (y or n) y
        (kgdb) bt
        #0  Debugger (msg=0xf0f661ac "vinum debug") at ../../i386/i386/db_interface.c:318
        #1  0xf0f60a7c in vinumioctl (dev=0x40001900, cmd=0xc008464b, data=0xf6923ed0 "",
              flag=0x3, p=0xf688e6c0) at
              /usr/src/sys/modules/vinum/../../dev/vinum/vinumioctl.c:109
        #2  0xf01833b7 in spec_ioctl (ap=0xf6923e0c) at ../../miscfs/specfs/spec_vnops.c:424
        #3  0xf0182cc9 in spec_vnoperate (ap=0xf6923e0c) at ../../miscfs/specfs/spec_vnops.c:129
        #4  0xf01eb3c1 in ufs_vnoperatespec (ap=0xf6923e0c) at ../../ufs/ufs/ufs_vnops.c:2312
        #5  0xf017dbb1 in vn_ioctl (fp=0xf1007ec0, com=0xc008464b, data=0xf6923ed0 "",
              p=0xf688e6c0) at vnode_if.h:395
        #6  0xf015dce0 in ioctl (p=0xf688e6c0, uap=0xf6923f84) at ../../kern/sys_generic.c:473
        #7  0xf0214c0b in syscall (frame={tf_es = 0x27, tf_ds = 0x27, tf_edi = 0xefbfcff8,
              tf_esi = 0x1, tf_ebp = 0xefbfcf90, tf_isp = 0xf6923fd4, tf_ebx = 0x2,
              tf_edx = 0x804b614, tf_ecx = 0x8085d10, tf_eax = 0x36, tf_trapno = 0x7,
              tf_err = 0x2, tf_eip = 0x8060a34, tf_cs = 0x1f, tf_eflags = 0x286,
              tf_esp = 0xefbfcf78, tf_ss = 0x27}) at ../../i386/i386/trap.c:1100
        #8  0xf020a1fc in Xint0x80_syscall ()
        #9  0x804832d in ?? ()
        #10 0x80482ad in ?? ()
        #11 0x80480e9 in ?? ()
        (kgdb) f 1
        #1  0xf0f60a7c in vinumioctl (dev=0x40001900, cmd=0xc008464b, data=0xf6923ed0 "",
            flag=0x3, p=0xf688e6c0) at
            /usr/src/sys/modules/vinum/../../dev/vinum/vinumioctl.c:109
        Source file is more recent than executable.
        109             Debugger ("vinum debug");

    디버거로부터 실행 개시할 때, 프레임 1 의 소스 (위의 예에서는 마지막 부분)에 다음의 캐릭터 라인이 포함되어 있는 것은 중요합니다.

        Debugger ("vinum debug");

    이것은 주소 정의가 올바른 일을 나타내고 있습니다.

최초의 조사에서 가장 중요한 정보는, 위에 나타나고 있도록(듯이) bt (백 트레이스) 명령의 출력입니다.

저자
Greg Lehey <grog@lemis.com>

역사
vinum (은)는 FreeBSD 3.0 으로부터 등장했습니다.

관련 항목
vinum(8), disklabel(5), disklabel(8)