Devicemanagement PDF

AIX 버전 7.
장치 관리
IBM
참고
이 정보와 이 정보가 지원하는 제품을 사용하기 전에, 221 페이지의 『주의사항』에 있는 정보를 확인하십시
오.
이 개정판은 새 개정판에서 별도로 명시하지 않는 한, AIX 버전 7.2 및 모든 후속 릴리스에 적용됩니다.

© Copyright International Business Machines Corporation 2010, 2019.
목차
이 문서에 관한 정보................................................................................................. vii

강조표시....................................................................................................................................................... vii
AIX 에서 대소문자 구분.................................................................................................................................vii
ISO 9000.....................................................................................................................................................vii
장치 관리................................................................................................................ 1
새로운 기능.................................................................................................................................................... 1
논리적 볼륨 관리자 ........................................................................................................................................ 1
논리적 볼륨 관리자 개념............................................................................................................................ 1
논리적 볼륨 관리자 구성............................................................................................................................ 9
LVM 문제점 해결 ....................................................................................................................................25
논리적 볼륨 스토리지....................................................................................................................................35
장치 설치 준비........................................................................................................................................ 36
읽기/쓰기 광 드라이브 구성..................................................................................................................... 36
다수의 장치 구성..................................................................................................................................... 37
이동식 매체 드라이브 추가.......................................................................................................................38
논리적 볼륨 스토리지를 위한 공간 재이용 지원.........................................................................................38
논리적 볼륨 스토리지 개념.......................................................................................................................39
논리적 볼륨 스토리지 구성.......................................................................................................................43
볼륨 그룹 전략 ....................................................................................................................................... 50
논리적 볼륨 전략..................................................................................................................................... 52
볼륨 그룹 정책 구현.................................................................................................................................62
페이징 공간 및 가상 메모리........................................................................................................................... 62
페이징 공간 개념..................................................................................................................................... 62
페이징 공간 구성..................................................................................................................................... 65
페이징 공간 문제점 해결.......................................................................................................................... 68
가상 메모리 관리자..................................................................................................................................68
파일 시스템.................................................................................................................................................. 69
파일 시스템 개념..................................................................................................................................... 70
파일 시스템 구성..................................................................................................................................... 79
파일 시스템 관리..................................................................................................................................... 79
파일 시스템을 유지보수하기.................................................................................................................... 82
파일 시스템 문제점 해결.......................................................................................................................... 90
디스크 오버플로우.................................................................................................................................. 92
마운트.................................................................................................................................................... 96
파일 시스템 유형...................................................................................................................................100
디렉토리 ..............................................................................................................................................113
워크로드 관리자 ........................................................................................................................................ 120
워크로드 관리 개념 .............................................................................................................................. 120
워크로드 관리자 관리............................................................................................................................ 126
클래스 ................................................................................................................................................. 136
워크로드 관리자에서 프로세스 분류 ...................................................................................................... 140
워크로드 관리자를 사용한 자원 관리 ..................................................................................................... 143
워크로드 관리자 설정............................................................................................................................ 149
워크로드 관리자 문제점 해결................................................................................................................. 151
워크로드 관리자 API.............................................................................................................................151
워크로드 관리자 분류, 규칙 및 제한에 대한 예제 .................................................................................... 154
워크로드 관리자 명령............................................................................................................................ 155
장치 노드................................................................................................................................................... 156
장치 클래스.......................................................................................................................................... 156
iii
장치 구성 데이터베이스 및 장치 관리..................................................................................................... 156
장치 상태..............................................................................................................................................157
장치 위치 코드............................................................................................................................................157
어댑터 위치 코드...................................................................................................................................157
프린터 및 플로터 위치 코드................................................................................................................... 158
tty 위치 코드........................................................................................................................................ 158
SCSI 장치 위치 코드............................................................................................................................. 159
Dials/LPFKeys 위치 코드..................................................................................................................... 159
멀티프로토콜 포트 위치 코드................................................................................................................. 160
장치 드라이버............................................................................................................................................ 160
iSCSI 오프로드 어댑터 설정........................................................................................................................161
AIX 에서 iSCSI 어댑터 구성.................................................................................................................. 161
iSCSI 목표의 플랫 파일 갱신 ................................................................................................................ 161
정적으로 검색된 iSCSI 목표를 ODM에 추가...........................................................................................162
플랫 파일에서 정적으로 검색된 iSCSI 목표를 ODM에 추가 .................................................................... 162
PCI 핫 플러그 관리.....................................................................................................................................163
PCI 핫 플러그 슬롯 정보 표시................................................................................................................ 164
PCI 통신 어댑터 구성 해제.................................................................................................................... 164
PCI 핫 플러그 어댑터 제거 또는 대체..................................................................................................... 165
PCI 핫 플러그 어댑터 추가.................................................................................................................... 165
다중 경로 입출력........................................................................................................................................ 166
MPIO 사용 가능 장치 관리.................................................................................................................... 168
MPIO 장치 구성....................................................................................................................................169
지원되는 다중 경로 장치........................................................................................................................170
MPIO 장치 속성....................................................................................................................................171
경로 제어 모듈 속성.............................................................................................................................. 173
SAN 복제 속성......................................................................................................................................175
통신 어댑터 제거...................................................................................................................................176
스토리지 어댑터 구성 해제.................................................................................................................... 181
비동기 어댑터 구성 해제........................................................................................................................182
입출력 장치 문제점 해결........................................................................................................................183
목표 디바이스 구성.....................................................................................................................................186
FC와 FCoE 장치의 대상 구성.................................................................................................................186
테이프 드라이브......................................................................................................................................... 187
테이프 드라이브 속성 ........................................................................................................................... 187
테이프 드라이브용 특수 파일 ................................................................................................................ 197
USB 장치 지원........................................................................................................................................... 198
USB 플래시 드라이브 지원.................................................................................................................... 198
USB 블루 레이 드라이브 읽기 전용 지원.................................................................................................199
스토리지 데이터 캐싱................................................................................................................................. 199
개념 .................................................................................................................................................... 199
장점 .................................................................................................................................................... 200
제한사항...............................................................................................................................................200
구성요소...............................................................................................................................................201
구성 .................................................................................................................................................... 201
관리..................................................................................................................................................... 205
모니터링 캐시 통계............................................................................................................................... 206
로그인 이름, 시스템 ID 및 비밀번호............................................................................................................ 206
운영 체제에 로그인............................................................................................................................... 207
한 번 이상 로그인(login 명령)................................................................................................................208
시스템에서 다른 사용자로 전환(su 명령)................................................................................................208
로그인 메시지 억제 .............................................................................................................................. 208
운영 체제에서 로그아웃(exit 및 logout 명령) ........................................................................................ 208
사용자 ID 표시......................................................................................................................................208
비밀번호 ..............................................................................................................................................210
로그인 이름, 시스템 ID 및 비밀번호용 명령 요약 ................................................................................... 212
공통 데스크탑 환경.....................................................................................................................................212
데스크탑 자동 시작 사용 및 사용 안함 설정.............................................................................................212
iv
수동으로 공통 데스크탑 환경 시작......................................................................................................... 213
수동으로 공통 데스크탑 환경 정지......................................................................................................... 213
데스크탑 프로파일 수정.........................................................................................................................213
공통 데스크탑 환경용 표시장치와 터미널 추가 및 제거............................................................................213
공통 데스크탑 환경를 위한 장치 사용자 조정 표시.................................................................................. 215
HEA(Host Ethernet Adapter)가 있는 LPM(Live Partition Mobility).......................................................... 217
HEA가 있는 라이브 파티션 이동성 요구사항...........................................................................................217
HEA가 있는 라이브 파티션 이동성 실행................................................................................................. 218
DLPAR을 위해 어댑터 재배치 .....................................................................................................................219
루프백 디바이스......................................................................................................................................... 220
주의사항............................................................................................................. 221
개인정보처리방침 고려사항........................................................................................................................ 222
상표...........................................................................................................................................................222
색인................................................................................................................... 223
v
vi
이 문서에 관한 정보
이 문서는 사용자 및 시스템 관리자에게 시스템 백업 및 복원, 물리적 및 논리적 스토리지 관리, 적절한 페이징 공
간 크기 조정과 같은 태스크를 수행할 때 옵션선택에 영향을 미칠 수 있는 모든 정보를 제공합니다. 논리적 볼륨,
스토리지 및 자원 관리와 같은 태스크를 수행하는 방법에 대한 모든 정보도 제공합니다. 시스템 사용자는 명령 실
행, 프로세스 처리, 파일 및 디렉토리 처리, 기본 인쇄 등과 같은 태스크를 수행하는 방법을 배울 수 있습니다.
그 밖에 사용자와 시스템 관리자에게 유용한 주제로는 페이징 공간 작성 및 크기 조정, 가상 메모리 관리, 시스템
백업 및 복원, 하드웨어 및 의사 장치 관리, 시스템 자원 제어기(SRC) 사용, 파일 보안, 스토리지 미디어 사용, 환
경 파일 사용자 조정 및 쉘 스크립트 쓰기 등이 있습니다. 이 문서는 운영 체제와 함께 제공되는 문서 CD에도 있습
니다.
강조표시
다음 강조표시 규칙이 이 문서에서 사용됩니다.
굵은체 명령, 서브루틴, 키워드, 파일, 구조, 디렉토리 및 시스템에 의해 이름이 사전 정의된 기타
항목을 식별합니다. 사용자가 선택하는 버튼, 레이블 및 아이콘과 같은 그래픽 오브젝트도
식별합니다.
기울임꼴 사용자가 실제 이름 또는 값을 제공해야 하는 매개변수를 식별합니다.
특정 데이터 값 예제, 사용자가 볼 수 있는 표시되는 항목과 유사한 텍스트 예제, 프로그래
모노스페이스
머로서 작성할 수 있는 내용과 유사한 프로그램 코드 부분의 예제, 시스템 메시지 또는 실제
로 사용자가 입력해야 하는 정보를 식별합니다.
AIX 에서 대소문자 구분
AIX® 운영 체제의 모든 항목은 대소문자를 구분하므로 대문자와 소문자가 구별됩니다. 예를 들어 ls 명령을 사용
하여 파일을 나열할 수 있습니다. 이 경우 LS를 입력하면 시스템이 명령을 찾을 수 없음으로 응답합니다. 따라서
FILEA, FiLea 및 filea은 같은 디렉토리에 있어도 세 개의 다른 파일 이름으로 인식됩니다. 원하지 않는 조치
가 수행되는 것을 방지하기 위해서는 항상 대소문자를 명확히 구분하여 사용하십시오.
ISO 9000
ISO 9000 등록 품질 시스템이 이 제품의 개발과 제조에서 사용되었습니다.
© Copyright IBM Corp. 2010, 2019 vii

viii AIX 버전 7.2: 장치 관리
장치 관리
명령을 사용하여 AIX 에서 사용 가능한 여러 장치를 관리할 수 있습니다. 사용자가 관리할 수 있는 몇몇 장치에는
논리적 볼륨 관리자, 파일 시스템, 테이프 드라이브 및 프린터가 포함됩니다.
장치 관리의 새로운 기능
장치 관리 주제 집합과 관련하여 새로운 정보 또는 크게 변경된 정보를 읽을 수 있습니다.
새로운 정보 또는 변경된 정보를 확인하는 방법

이 PDF 파일에서는 새로운 정보와 변경된 정보 주위에서 개정 태그(>| 및 |<)를 볼 수 있습니다.
2020년 11월
다음 정보는 이 주제 집합에 작성된 갱신사항을 요약한 것입니다.
• 50 페이지의 『논리적 볼륨 암호화』 주제에서 데이터 암호화 사용에 대한 정보가 추가되었습니다.
2020년 5월
• 3 페이지의 『지리적 논리적 볼륨 관리자 』 주제에서 비동기 원격 미러링을 위한 지리적 논리적 볼륨 관리
자(GLVM) 배치 지침이 추가되었습니다.
• 171 페이지의 『MPIO 장치 속성』 주제에서 io_thrshld_tmr 속성에 대한 정보가 추가되었습니다.
2019년 11월
• 171 페이지의 『MPIO 장치 속성』 주제에서 다음 속성에 대한 정보가 추가되었습니다.
– rw_timeout - 스토리지 장치에서 명령을 실행할 때마다 SCSI 명령을 완료하도록 허용되는 시간(초)을 지
정합니다.
– min_rw_to - rw_timeout 속성에 대해 허용되는 가장 작은 값을 지정합니다.
– rw_max_time - 각 입출력 조작을 완료하는 대략적인 최대 시간(초)을 지정합니다.
• 200 페이지의 『스토리지 데이터 캐싱의 제한사항』 주제에서 NVMe 장치의 제한사항에 대한 정보가 추가되
었습니다.
논리적 볼륨 관리자
논리적 볼륨 스토리지를 만들고 제어하는 데 사용할 수 있는 일련의 운영 체제 명령, 라이브러리 서브루틴 및 기
타 도구를 LVM(논리적 볼륨 관리자)이라고 합니다.
LVM은 스토리지 공간을 보다 단순하고 융통성 있게 보여 주는 논리적 보기와 실제 물리적 디스크 간에 데이터를
맵핑하여 디스크 자원을 제어합니다. LVM은 기존의 디스크 장치 드라이버 위에서 실행되는 장치 드라이버 코드
계층을 사용하여 이를 수행합니다.
LVM은 LVDD(논리적 볼륨 장치 드라이버)와 LVM 서브루틴 인터페이스로 구성됩니다. LVDD(논리적 볼륨 장치
드라이버)는 모든 입출력을 관리하고 처리하는 의사 장치 드라이버입니다. LVDD는 논리적 주소를 물리적 주소
로 변환하고 특정 장치 드라이버로 입출력 요청을 전송합니다. LVM 서브루틴 인터페이스 라이브러리에는 시스
템의 논리적, 물리적 볼륨에 대한 시스템 관리 태스크를 수행하기 위해 시스템 관리 명령이 사용하는 루틴이 포함
되어 있습니다.
논리적 볼륨 관리자 개념
논리적 볼륨 관리자의 사용을 시작하기 전에 기본 메커니즘과 용어를 이해해야 합니다.
© Copyright IBM Corp. 2010, 2019 1

연결 변환 프로세스
연결 변환 프로세스는 볼륨 그룹을 사용할 수 있고 볼륨 그룹에 최신 데이터가 포함되어 있는지 확인하기 위해
LVM이 사용하는 메커니즘 중 하나입니다.
varyonvg 및 varyoffvg 명령은 시스템에 정의된 볼륨 그룹을 활성화 또는 비활성화(사용 가능 또는 사용 불
가능하게 하기)합니다. 볼륨 그룹은 시스템이 액세스하기 전에 연결 변환해야 합니다. 연결 변환 프로세스 중에
LVM은 볼륨 그룹에 정의된 물리적 볼륨에서 관리 데이터를 읽습니다. VGDA(volume group descriptor area)와
VGSA(volume group status area)를 포함하는 이 관리 데이터는 볼륨 그룹의 각 물리적 볼륨에 저장됩니다.
VGDA에는 볼륨 그룹의 각 논리적 볼륨에 대한 논리적 파티션으로 물리적 파티션의 맵핑을 설명하는 정보와 시
간 소인을 포함한 기타 중요한 정보가 들어 있습니다. VGSA에는 볼륨 그룹에서 연결 변환 조작이 시도될 때 효력
이 상실된 물리적 파티션과 누락된 물리적 볼륨(즉, 사용 불가능 또는 활성화되지 않음)과 같은 정보가 들어 있습
니다.
연결 변환 조작이 볼륨 그룹에 정의된 하나 이상의 물리적 볼륨에 액세스할 수 없으면 해당 명령은 볼륨 그룹과
상태에 대해 정의된 모든 물리적 볼륨의 이름을 표시합니다. 이를 통해 이 볼륨 그룹의 연결 변환 해제 여부를 결
정할 수 있습니다.
쿼럼
쿼럼은 볼륨 그룹이 사용 준비가 완료되고 그 안에 최신 데이터가 포함되도록 하기 위해 LVM에서 사용하는 메커
니즘 중 하나입니다.
쿼럼은 활성화되어 있는 볼륨 그룹 설명자 영역 및 볼륨 그룹 상태 영역(VGDA/VGSA)의 수에 대한 선출입니다.
쿼럼은 디스크 장애가 발생하는 경우 VGDA/VGSA 영역의 데이터 무결성을 보장합니다. 볼륨 그룹의 각 실제 디
스크에 하나 이상의 VGDA/VGSA가 있습니다. 단일 디스크에 볼륨 그룹을 작성하는 경우 초기에는 디스크에 상
주하는 두 개의 VGDA/VGSA 영역을 갖습니다. 볼륨 그룹이 두 개의 디스크로 구성된 경우 한 디스크에는 두 개의
VGDA/VGSA 영역이 있지만 다른 하나에는 하나의 VGDA/VGSA가 있습니다. 볼륨 그룹이 셋 이상의 디스크로 구
성된 경우 각 디스크에는 하나의 VGDA/VGSA만 할당됩니다.
적어도 디스크의 절반(해당 VGDA/VGSA 영역을 의미)을 LVM으로 읽을 수 없는 경우에는 쿼럼이 유실됩니다. 디
스크가 두 개인 볼륨 그룹에서 하나의 VGDA/VGSA만 있는 디스크가 유실되면 세 VGDA/VGSA 영역 중 두 영역
에 도달할 수 있기 때문에 쿼럼은 계속 존재합니다. VGDA/VGSA 영역이 두 개인 디스크가 유실되는 경우에는 이
러한 설명이 적용되지 않습니다. 볼륨 그룹을 구성하는 디스크 수가 많을수록 하나의 디스크가 실패할 때 쿼럼이
유실될 가능성은 줄어듭니다.
쿼럼이 유실되는 경우 볼륨 그룹은 연결 변환이 해제되어 LVM에서 더 이상 디스크에 액세스할 수 없습니다. 이렇
게 되면 해당 볼륨 그룹에 대한 디스크 입출력이 금지되므로 물리적 문제점이 발생할 때 데이터가 유실되지 않거
나 기록되는 것으로 간주됩니다. 또한 연결 변환 해제의 결과로 사용자는 하드웨어 오류가 발생했으며 서비스를
수행해야 한다는 알림을 오류 로그에 받습니다.
쿼럼이 유실된 경우에도 볼륨 그룹을 계속 작동해야 경우가 있습니다. 이런 경우 해당 볼륨 그룹에 대한 쿼럼 검
사를 해제할 수 있습니다. 이 유형의 볼륨 그룹을 비쿼럼 볼륨 그룹이라고 합니다. 논리적 볼륨이 미러된 경우에
비쿼럼 볼륨 그룹이 가장 일반적으로 생깁니다. 디스크가 유실된 경우 사용 가능한 디스크에 논리적 볼륨 사본이
상주하고 여기에 액세스할 수 있는 경우에는 데이터가 유실되지 않습니다. 그러나 사용 불가능해진 디스크에 데
이터(사본 포함)가 상주하는 경우에는 비쿼럼 볼륨 그룹에 미러되었거나 미러되지 않은 인스턴스가 있을 수 있습
니다. 이러한 인스턴스에서는 볼륨 그룹이 계속 연결 변환되더라도 데이터에 액세스하지 못할 수 있습니다.
미러 풀
미러 풀은 볼륨 그룹의 물리적 볼륨을 별도의 풀로 나누는 것을 가정하게 합니다.
미러 풀은 하나 이상의 물리적 볼륨으로 구성됩니다. 각 물리적 볼륨은 한 번에 하나의 미러 풀에만 속할 수 있습
니다. 논리적 볼륨을 작성할 때 작성되는 논리적 사본의 각 사본은 미러 풀에 지정될 수 있습니다. 미러 풀에 지정
되는 논리적 볼륨 사본은 파티션을 해당 미러 풀의 물리적 볼륨에서만 할당합니다. 이는 논리적 볼륨 사본이 사용
할 수 있는 디스크를 제한하는 기능을 제공합니다. 미러 풀이 없으면 논리적 볼륨을 작성하거나 확장할 때 할당에
어떤 물리적 볼륨이 사용되는지를 제한하기 위한 유일한 방법은 맵 파일을 사용하는 것입니다. 따라서 미러 풀을
사용하면 이 프로세스가 대폭 단순화됩니다. 미러 풀은 extendvg 명령 또는 chpv 명령으로 작성될 수 있습니다.
새 미러 풀을 작성할 때 미러 풀 이름을 지정해야 합니다. 미러 풀 이름은 다음 규칙을 준수해야 합니다.

• 영숫자 문자 또는 _(밑줄 문자), -(빼기 부호) 또는 .(마침표) 문자만 사용할 수 있습니다.
• 15자 이하여야 합니다.
• 볼륨 그룹에서 고유해야 합니다.
2 AIX 버전 7.2: 장치 관리
미러 풀이 볼륨 그룹에 사용된 후에는 볼륨 그룹은 더 이상 미러 풀을 지원하지 않는 AIX의 버전으로 반입될 수
없습니다. 여기에는 6.1.1.0 이전의 AIX 버전이 포함됩니다. 또한, 미러 풀을 개선된 동시 모드 LVM과 함께 사용
하기 위해서는 클러스터의 모든 노드가 미러 풀을 지원해야 합니다.
미러 풀 엄격성
미러 풀 엄격성은 미러 풀 사용에 대해 더 엄격한 제한사항을 강제하는 데 사용할 수 있습니다. 미러 풀 엄격성은
다음 세 값 중 하나를 가질 수 있습니다.
off
미러 풀 엄격성이 off로 설정되면 미러 풀 사용에 제한이 없습니다. 이것이 기본값입니다.
on
미러 풀 엄격성이 on으로 설정되면, 볼륨 그룹에서 작성된 각 논리적 볼륨 사본이 미러 풀에 지정되어야 합니
다.
super
미러 풀 엄격성이 super로 설정되면 다음 제한사항이 적용됩니다.
• 로컬 및 원격 물리적 볼륨은 동일한 미러 풀에 속할 수 없습니다.
참고: 로컬 및 원격 물리적 볼륨에 대한 자세한 정보는 HACMP/XD GLVM 문서를 참조하십시오.
• 볼륨 그룹에는 최대 세 개의 미러 풀이 있을 수 있습니다.
• 각 미러 풀에는 볼륨 그룹에 각 논리적 볼륨의 사본이 하나 이상 있어야 합니다.
지리적 논리적 볼륨 관리자

지리적 논리적 볼륨 관리자(GLVM)를 사용하면 지리적으로 먼 위치에 있는 데이터의 미러 사본을 유지보수할 수
있습니다.
GLVM은 중요한 데이터를 원격 재해 복구 사이트로 미러링하여 재해로부터 비즈니스를 보호해줍니다. 화재나 홍
수와 같은 재해가 프로덕션 사이트의 데이터를 파괴하는 경우, 재해 복구 사이트에 데이터의 백업 사본이 있습니
다.
데이터는 표준 TCP/IP 네트워크를 통해 미러링됩니다. 프로덕션 및 재해 복구 사이트는 동일한 물리적 네트워크
에 있을 필요가 없습니다. 두 사이트 사이에서 라우터와 게이트웨이를 사용할 수 있습니다. 너무 긴 디스크 케이
블 대신에, TCP/IP 네트워크 및 원격 물리적 볼륨(RPV) 장치 드라이버가 원격 디스크 액세스에 사용됩니다.
사용자는 지리적으로 먼 디스크를 원격 물리적 볼륨으로 구성한 다음에 이러한 원격 물리적 볼륨을 로컬 물리적
볼륨과 결합하여 지리적으로 미러링된 볼륨 그룹을 형성합니다. 이러한 볼륨 그룹은 논리적 볼륨 관리자(LVM)가
관리하며 일반 볼륨 그룹과 유사하게 작동합니다. GLVM은 동기 및 비동기 원격 미러링 둘 모두를 지원합니다.
비동기 GLVM
비동기 지리적 논리적 볼륨 관리자(GLVM)는 표준 TCP/IP 네트워크를 통해 1차 및 2차 사이트에서 데이터를 미
러링합니다. 여기서 1차 사이트는 프로덕션 사이트가 될 수 있고, 2차 사이트는 재해 복구 사이트가 될 수 있습니
다.
다음 그림에서는 비동기 GLVM 조작을 표시합니다. 여기서 GLVM 환경에는 두 개의 노드(Node 1_1 및 Node
2_1)가 있습니다. 이러한 노드는 표준 TCP/IP 네트워크를 통해 사이트 1과 사이트 2에서 링크됩니다.
장치 관리 3
그림 1.
네트워크
사이트 1 사이트 2
Node 1_1 Node 2_1
cachelv
버퍼 디스크
asynchronous_GLVM
1차 디스크 백업 디스크
1차 사이트(사이트 1)의 Node 1_1에서 실행 중인 워크로드는 1차 사이트에 있는 로컬 디스크(1차 디스크)에 데

이터를 기록합니다. 이러한 쓰기 조작은 논리적 볼륨 관리자(LVM)에서 추적하며 2차 사이트(사이트 2)의 Node
2_1에서 실행 중인 워크로드는 1차 사이트의 버퍼 디스크인 캐시 논리적 볼륨(캐시)으로 데이터를 기록합니다.
비동기 GLVM은 캐시 논리적 볼륨에서 원격 사이트(사이트 2)로 TCP/IP 네트워크를 통해 데이터를 전송하고 원
격 사이트에 있는 백업 디스크로 데이터를 기록합니다. 원격 사이트의 Node 2_1에서 실행 중인 워크로드도 2차
사이트의 백업 디스크로 데이터를 기록합니다.
비동기 GLVM 계획
비동기 미러링을 위해 GLVM을 배치하는 경우 최적 네트워크 속도, 캐시 논리적 볼륨(cachelv)의 크기 등을 고
려해야 합니다.
비동기 원격 미러링을 위해 GLVM을 배치하려면 다음 지침을 고려하십시오.
• 사용자 환경에 있는 데이터 크기에 따라 필요한 최적의 네트워크 속도를 확인하십시오.
데이터 크기 네트워크 속도
1TB 미만 1Gbps 이상
1 - 10TB 5Gbps 이상
10TB - 100TB 10Gbps 이상
• 1차 사이트에 cachelv 논리적 볼륨에 대해 충분한 디스크 공간이 포함되도록 1차 사이트에 있는 캐시 논리적
볼륨(cachelv)의 크기가 적절히 표시되는지 확인하십시오. 최대 입출력 조작 및 네트워크 대역폭을 기반으로 1
차 사이트에 필요한 버퍼 디스크의 최대 디스크 공간을 계산하십시오. 버퍼 디스크 공간 양의 두 배를
cachelv 논리적 볼륨에 할당하십시오.
• 최대 기간 및 입출력 조작양을 식별하기 위해 GLVM 배치 주간 이후 성능 도구를 사용하여 환경에서 CPU 및 메
모리 자원의 사용량을 모니터하십시오. 최대 기간 도중에라도 CPU 및 메모리 사용량이 전체 용량의 80%를 초
과하지 않도록 하십시오. 논리적 파티션(LPAR) 메모리가 고갈되면 운영 체제 장애가 발생할 수 있습니다.
• 비동기 원격 미러링을 위해 GLVM을 배치하는 도중 LVM 및 GLVM 조정 가능 매개변수가 수정되지 않도록 하십
시오. 조정 가능 매개변수를 수정하려는 경우 varyoffvg 명령을 사용하여 GLVM을 오프라인으로 만든 후
LVM 또는 GLVM 구성 설정을 수정하십시오. 예를 들어 chdev 명령을 사용하여 max_transfer_size 조정
가능 매개변수를 변경하려는 경우 비동기 원격 미러링을 위해 GLVM을 배치하는 동안 max_transfer_size
조정 가능 매개변수 값이 동일한지 확인하십시오. 그렇지 않으면 입출력 오류가 사이트에서 발생할 수 있습니
다.
• 사용자는 비동기 미러링을 지원하는 GLVM을 사용하여 볼륨 그룹 분할 조작을 수행할 수 없습니다.
• 비동기 미러링을 지원하는 GLVM은 동시 확장 가능하지 않은 볼륨 그룹만을 지원합니다. 비동기 미러링을 지원
하는 GLVM은 스냅샷 볼륨 그룹과 같은 기타 볼륨 그룹을 지원하지 않습니다.
• 1차 사이트에 있는 노드가 실패하면 1차 사이트는 복구 사이트에서 워크로드를 유지하려 시도합니다. 비동기
미러링을 지원하는 GLVM이 온라인이 되면 GLVM을 온라인으로 만드는 데 사용되는 시간은 cachelv 논리적
볼륨에서 보류 중인 워크로드의 잔여 데이터 크기에 따라 달라집니다. 잔여 데이터는 네트워크를 통해 복구 사
이트로 전송되어야 합니다. 이 기간 동안 애플리케이션이 수행하는 쓰기 조작은 캐시 복구 조작이 완료될 때까
지 완료할 수 없습니다. 그러므로 캐시 복구 조작 도중 잔여 데이터의 복구 동기화를 위해 약간의 중지 시간을
계획하십시오.
• 비동기 미러링을 지원하는 GLVM은 사용자 환경의 요구사항을 기반으로 수정할 수 있는 많은 조정 가능 매개변
수를 제공합니다.
– 네트워크 지연을 기반으로 RPVlevel 조정 가능 매개변수를 검토하고 수정하십시오. 동기화 조작을 완료하
도록 허용되는 디폴트 시간종료 지속 시간을 지정하기 위해 RPVlevel 조정 가능 매개변수를 사용할 수 있
습니다. 디폴트 시간종료 값은 180초입니다.
– LVM에 지정된 메모리(물리적) 버퍼 디스크 수를 늘려 cachelv 논리적 볼륨을 관리하십시오. 최적 값인
16,000을 사용할 수 있습니다.
• 일부 LVM 메타데이터 관련 조작에서는 LVM 메타데이터가 두 사이트에서 올바른지 확인하기 위해 사이트 사이
에서의 동기 입출력 조작이 필요합니다. cachelv 논리적 볼륨에 있는 이전에 버퍼링된 데이터가 복구 사이트
로 완전하게 전송되는 경우에만 이러한 유형의 동기 입출력 조작을 수행할 수 있습니다. 그러므로 이러한 유형
의 조작은 버퍼링된 데이터가 목표 사이트로 전송되기를 기다리는 동안 오랜 시간이 소요될 수 있습니다. 더 빠
른 조작이 필요한 경우, cachelv 논리적 볼륨에 있는 잔여 버퍼 데이터가 최소인 경우 동기 입출력 조작을 수
행하도록 계획하십시오. rpvstat -C 명령을 사용하여 cachelv 디스크에 있는 잔여 버퍼 데이터를 확인할
수 있습니다. 다음 조작은 잔여 버퍼 데이터로 인해 완료하는 데 시간이 소요될 수 있습니다.
– 논리적 볼륨 크기 축소 또는 파일 시스템 크기 축소.
– 논리적 볼륨 제거.
– 비동기 미러링을 지원하는 GLVM 닫기.
• 잔여 버퍼 데이터가 cachelv 논리적 볼륨에서 대량인 경우 원격 파티션 동기화가 실패할 수 있습니다. 동기화
를 완료하려면 RPVlevel 조정 가능 매개변수의 디폴트 값보다 더 많은 시간이 필요할 수 있습니다. 성공적인
동기화 조작을 위해 잔여 버퍼 데이터에 따라 RPVlevel 조정 가능 매개변수를 업데이트하십시오.
• LPAR에 900개 이상의 디스크가 있는 GLVM이 구성되면, 다음 명령을 실행하여 FC 어댑터의 DMA 설정값을 늘
리십시오.
# chdev -l fcs1 -a lg_term_dma=0x8000000 -P
# rmdev -Rl fcs1
# cfgmgr -l fcs1 -v
• rpvclient 장치별로 하나의 네트워크가 구성되면 비동기 GLVM은 LPAR별로 최대 1020개의 rpvclients를 지원
합니다.
표 1. 지원되는 rpvclients 최대 수
각 rpvclient에 사용되는 네트워크 지원되는 rpvclients 최대 수
1 1020
2 510
3 340
4 255
비동기 GLVM 설정
기본적으로 지리적 논리적 볼륨 관리자(GLVM) 패키지가 AIX 운영 체제에 설치됩니다.
장치 관리 5
선행 조건
• 시스템이 AIX 버전 AIX 7(7200-04 포함) 이상에서 실행 중인지 확인하십시오.
• 통신을 위해 1차 및 2차 사이트에서 TCP/UDP 포트 6192를 사용 중인지 확인하십시오.
• 원격 물리적 볼륨(RPV) 서버와 RPV 클라이언트를 작성하기 위한 디스크가 충분한지 확인하십시오.
비동기 GLVM을 설정하려면 다음 단계를 완료하십시오.
1. 다음과 같이 SMIT glvm_utils 단축 경로를 사용하여 RPV 서버 및 RPV 클라이언트를 구성하십시오.
a. RPV 서버를 작성하려면 Remote Physical Volume Servers Ad>Remote Physical Volume Servers를
선택하고 Enter를 누르십시오.
PowerHA® SystemMirror® for AIX에서 RPV 서버 및 RPV 클라이언트 작성에 대한 자세한 정보는 지리적
으로 미러링된 볼륨 그룹 구성을 참조하십시오.
b. RPV 사이트 이름을 정의하려면 Remote Physical Volume Servers > Remote Physical Volume
Server Site Name Configuration > Define / Change / Show Remote Physical Volume Server Site
Name를 선택한 후 Enter를 누르십시오.
c. RPV 클라이언트를 작성하려면 Remote Physical Volume Clients > Add Remote Physical Volume
Clients를 선택하고 Enter를 누르십시오.
2. 다음 단계를 완료하여 GLVM에서 사용할 수 있는 비동기 볼륨 그룹을 작성하십시오.
a. 다음 명령을 실행하여 확장 가능한 볼륨 그룹을 작성하십시오.
mkvg -f -S -y agmvg hdisk5 hdisk15
이 명령을 실행하는 경우, 비동기 agmvg 볼륨 그룹이 작성됩니다. 볼륨 그룹에는 두 개의 디스크(hdisk5

및 hdisk15)가 있습니다.
b. 다음 명령을 실행하여 비동기 볼륨 그룹과 연관되는 디스크의 미러 풀을 작성하십시오.
chpv -p mp1 hdisk5 hdisk15
이 명령을 실행하는 경우 미러 풀 mp1이 hdisk5 및 hdisk15 디스크에 대해 작성됩니다.

1) 이제는 1차 사이트의 노드에서 RPV 서버 및 RPV 클라이언트를 구성하는 경우 작성할 수 있는 기타 디
스크를 포함하도록 비동기 볼륨 그룹을 확장하십시오.
extendvg -f -p mp2 agmvg hdisk22 hdisk23
이 명령을 실행하면 agmvg 비동기 볼륨 그룹이 hdisk22 및 hdisk23 디스크를 포함하도록 확장됩니다. 미
러 풀 mp2도 작성됩니다.
c. 다음 명령을 실행하여 agmvg 비동기 볼륨 그룹의 논리적 볼륨(giv)을 작성하십시오. 논리적 볼륨의 파일
시스템은 data 논리적 볼륨 및 log 논리적 볼륨의 일부인 파일로 구성됩니다.
• 다음 명령을 실행하여 data 논리적 볼륨을 작성하십시오.
mklv -t jfs2 -y glv -p copy1=mp1 -b n -s s -u 1 agmvg 10
• 다음 명령을 실행하여 log 논리적 볼륨을 작성하십시오.
mklv -t jfs2log -y glv_log -p copy1=mp1 -b n -s s -u 1 agmvg 10
d. 다음 명령을 실행하여 data 논리적 볼륨 및 log 논리적 볼륨에 사용해야 하는 저널 파일 시스템(JFS2) 파

일 시스템을 작성하십시오.
crfs -v jfs2 -A no -m /gfs -d glv -a logname=glv_log
e. RPV 서버 및 RPV 클라이언트에서 비동기 볼륨 그룹의 미러 사본을 작성하십시오.

mirrorvg -c 2 -p copy2=mp2 agmvg
미러 풀 mp1의 모든 데이터(1차 사이트의 디스크)는 표준 TCP/IP 네트워크를 통해 동기 모드에서 미러 풀
mp2(2차 사이트의 원격 디스크)로 복사됩니다.
f. 다음 명령을 실행하여 비동기 볼륨 그룹 쓰기 요청을 캐싱하기 위한 캐시 논리적 볼륨을 작성하십시오.
mklv -t aio_cache -y mp1_cache -p copy1=mp1 -b n agmvg 5 hdisk5
mklv -t aio_cache -y mp2_cache -p copy1=mp2 -b n agmvg 5 hdisk23
이러한 캐시 논리적 볼륨은 사이트에서 미러링되지 않아야 합니다. 새 aio_cache 논리적 볼륨을 관리할
수 있는 super strict 디스크 할당 정책을 사용하여 미러 풀을 작성할 수 있습니다.
g. 새 쓰기 요청이 원격 디스크에 대한 미러링을 반드시 대기하도록 하기 전에 쓰기 요청에 대한 최대 용량을
지정하도록 캐시 논리적 볼륨 및 2차 사이트의 비동기 미러링 특성을 구성하십시오.
• 다음 명령을 실행하여 캐시 LV의 비동기 미러링 특성을 구성하십시오.
chmp -A -h 80 -m mp2 agmvg
• 다음 명령을 실행하여 2차 사이트의 비동기 미러링 특성을 구성하십시오.

chmp -A -h 50 -m mp1 agmvg
• 다음 명령을 실행하여 chmp 명령이 성공적인지를 검증하십시오.
lsmp agmvg
비동기 미러링 특성을 구성한 후 미러 풀의 상태가 비동기 상태에 도달하고 미러 풀이 활성화된 경우, 원격 입
출력 조작 요청은 캐시 논리적 볼륨(cachelv)에 기록되고 입출력 조작 요청은 cachelv에서 2차 사이트로
미러링됩니다. 그런 다음 2차 사이트에서 논리적 볼륨의 파일 시스템을 마운트하여 1차 사이트에서 2차 사이
트로 미러링된 애플리케이션을 시작할 수 있습니다.
3. 다음 단계를 수행하여 비동기 GLVM 설정을 검증하십시오.
• 다음 명령을 실행하여 적절한 네트워크 연결을 확인하고 물리적 볼륨(PV) 디스크의 상태가 활성인지 확인
하십시오.
# lsvg -p agmvg
다음 예제와 유사한 출력이 표시됩니다.
agmpvg:
PV_NAME PV_STATE TOTAL_PPs FREE_PPs FREE DISTRIBUTION
hdisk6 active 957 627 192..00..52..191..192
hdiskl active 957 937 192..171..191..191..192
hdisk8 active 951 617 192..00..42..191..192
hdisk9 active 951 947 192..181..191..191..192
• 다음 명령을 실행하여 GLVM 환경에서 활성화된 비동기 입출력 조작 요청 및 연결 수를 모니터하십시오.

rpvstat -A
다음 예제와 유사한 출력이 표시됩니다.
Remote Physical Volume Statistics:

Completed Completed Cached Cached Pending Pending
Async Async Async Async Async Async
RPV Client ax Writes KB Writes Writes KB Writes Writes KB Writes
----------------------------------------------------------------------------------------
hdisk9 A 0 0 0 0 0 0
hdisk8 A 2061696 1018176796 21 10240 0 0
rpvstat -n 명령을 사용하여 사이트에 연결하는 네트워크의 상태 및 사용법을 확인할 수 있습니다.

rpvstat -A 명령은 비동기 입출력 조작의 상태를 확인하는 데 사용할 수 있습니다. rpvstat -C 명령은
캐시 논리적 볼륨의 통계를 확인하는 데 사용할 수 있습니다.
장치 관리 7
비동기 GLVM 배치의 우수사례
비동기 지리적 논리적 볼륨 관리자(GLVM) 배치를 위한 다음 우수사례를 고려하십시오.
• 입출력 시간종료 값과 관련된 네트워크 대기 시간 문제점을 예방하기 위해 chdev 명령을 사용하여 RPV
level I/O timeout 매개변수 값을 구성하십시오. rpv 디스크가 defined 상태인 경우 이 시간종료 매개
변수를 수정할 수 있습니다. 이 매개변수의 디폴트 값은 180초입니다.
• 독립형 GLVM 환경에서는 볼륨 그룹이 온라인이 되기 전 2차 사이트에 있는 모든 백업 디스크가 활성 상태가
되었는지 확인해야 합니다. 볼륨 그룹의 온라인 복구 도중 RPV 장치 드라이버에서 RPV 서버가 특정 비동기 입
출력 조작을 수행하기 위한 온라인이 아님을 발견한 경우, RPV 장치 드라이버는 캐시 디스크에서 실패한 요청
에 대해 업데이트합니다. 입출력 조작은 계속해서 동기식으로 실행됩니다. 프로그램을 수정한 후 비동기 미러
링으로 복귀하려는 경우 chmp 명령을 사용할 수 있습니다.
• 사이트 실패 후 2차 사이트에서 비동기 미러링 상태는 비활성일 수 있습니다. 1차 사이트와 2차 사이트를 다시
통합한 후 미러 풀은 비동기 미러링으로 변환되어야 비동기 미러링 배치를 계속할 수 있습니다.
• GLVM의 비동기 미러링 상태가 lsmp 명령을 사용하여 활성화되는지 정기적으로 모니터하십시오. rpvstat
–A 명령은 비동기 미러링의 통계 및 상태를 표시합니다.
• GLVM 환경에서 정기적으로 비동기 입출력 조작 및 활성 연결 수를 모니터하십시오. rpvstat -n 명령은 특
정 네트워크에 대한 세부사항을 표시합니다. rpvstat -A 명령은 비동기 입출력 조작에 대한 세부사항을 표
시합니다. rpvstat -C 명령은 캐시 논리적 볼륨에 대한 통계를 표시합니다.
• 보다 나은 성능을 위해 사용자 환경에서 배치되는 스토리지 장치의 디스크 드라이버 매개변수가 올바로 구성되
었는지 확인하십시오.
비쿼럼 볼륨 그룹
볼륨 그룹 설명자 영역(VGDA) 또는 볼륨 그룹 상태 영역(VGSA)의 쿼럼이 부족하면 논리적 볼륨 관리자(LVM)는
자동으로 볼륨 그룹을 비활성화합니다. 그러나 완전한 하나의 VGDA/VGSA 쌍이 있는 한 그룹을 온라인으로 유
지시킬 수 있는 옵션을 선택할 수 있습니다. 이 옵션은 비쿼럼 볼륨 그룹을 생성합니다.
비활성화가 허용되려면 먼저 LVM에는 비쿼럼 볼륨 그룹의 모든 디스크에 대한 액세스 권한이 있어야 합니다. 이
를 통해 VGDA 및 VGSA는 최신 상태를 유지할 수 있습니다.
각 논리적 볼륨에 최소 두 개의 사본이 있는 시스템에 비쿼럼 볼륨 그룹을 생성할 수 있습니다. 디스크 장애가 발
생하는 경우 하나의 활성 디스크만 있어도 볼륨 그룹은 활성 상태를 유지합니다.
참고: 사용자 정의 볼륨 그룹과 rootvg 볼륨 그룹은 모두 비쿼럼 상태로 작동할 수 있지만 하드웨어 실패 후 복구
를 위해 비쿼럼으로 사용자 정의 볼륨 그룹 및 rootvg 볼륨 그룹을 구성하는 데 사용되는 방법은 서로 다릅니다.
볼륨 그룹마다 올바른 방법을 사용하십시오.
비쿼럼 볼륨 그룹을 사용하는 경우에도 쿼럼을 유실할 수 있습니다. errpt 명령 출력의 다음 메시지를 참조하십
시오.
QUORUM LOST, VOLUME GROUP CLOSING LVM.
이 메시지는 모든 물리적 볼륨이 missing 상태에 있으며 LVM이 자동으로 볼륨 그룹을 연결 변환 해제하는 경우
에 발생합니다.
메시지에 QUORUM LOST가 표시됩니다. 볼륨 그룹에 대한 쿼럼이 사용 불가능한 경우 쿼럼 요구사항이 1로 감소
합니다. lsvg vgname 명령을 사용하여 QUORUM: 필드에 있는 쿼럼 값을 표시할 수 있습니다. 모든 물리적 볼륨
이 missing 상태인 경우 최소 쿼럼 요구사항에 위배되어 유실된 쿼럼 메시지가 발생하고 볼륨 그룹은 자동으로
연결 변환 해제됩니다.
볼륨 그룹을 비쿼럼 상태로 변환

볼륨 그룹을 비쿼럼 상태로 변경하여 쿼럼이 없는 경우에도 데이터를 계속해서 사용할 수 있게 만들 수 있습니다.
이 절차는 다음과 같은 구성을 가진 시스템에 주로 사용됩니다.
• 논리적 볼륨이 미러된 2-디스크 볼륨 그룹
• 논리적 볼륨이 한 번 또는 두 번 미러된 3-디스크 볼륨 그룹
이러한 상황 아래에 있는 볼륨 그룹이 비쿼럼 상태에서 작동할 수 있는 경우에는 디스크 장애가 발생하더라고 볼
륨 그룹은 볼륨 그룹에서 적어도 하나의 디스크가 활성인 한 활성 상태로 남아 있습니다.
가능한 비쿼럼 그룹을 복구하려면 다음을 수행하십시오.
• 시스템에서 JFS 또는 JFS2 파일 시스템을 사용할 경우, JFS 로그 논리적 볼륨을 미러하십시오.
• 미러 사본들을 서로 다른 디스크에 배치하십시오. 구성을 확실하게 모를 경우, 다음 명령을 입력하여 각 논리적
파티션의 물리적 위치(PV1, PV2 및 PV3)를 확인하십시오. 서로 다른 디스크에 사본들을 배치하려면 PV1, PV2
및 PV3 열에 서로 다른 hdisk 번호가 포함되어야 합니다.
lslv -m LVName
논리적 볼륨의 유일한 사본들이 동일한 디스크에 상주하며 이 디스크를 사용할 수 없을 경우, 볼륨 그룹의 상태
가 쿼럼 상태인지 비쿼럼 상태인지 여부에 관계없이 사용자가 볼륨을 사용할 수 없습니다.
사용자 정의 볼륨 그룹과 rootvg 볼륨 그룹은 모두 비쿼럼 상태에서 작동할 수 있지만 해당 구성과 복구 방법은
서로 다릅니다.
비쿼럼 사용자 정의 볼륨 그룹을 활성화하려면 볼륨 그룹의 모든 물리적 볼륨에 액세스할 수 있어야 합니다. 그렇
지 않으면 활성화에 실패합니다. 마지막 디스크에 액세스할 수 없게 될 때까지 비쿼럼 볼륨 그룹이 온라인 상태에
있을 수 있으므로, 활성화할 때 각 디스크를 액세스 가능 상태로 만들어야 합니다.
주의: rootvg 볼륨 그룹과 연관된 디스크가 누락된 경우 누락된 디스크를 수리할 가능성이 있는 한 시스템에 전원
을 공급하지 마십시오. LVM(논리적 볼륨 관리자)은 항상 -f 플래그를 사용하여 비쿼럼 rootvg를 강제로 활성화
하는데(연결 변환) 이 작업에는 위험이 따릅니다. 운영 체제는 rootvg가 활성화되지 않는 한 시작할 수 없으므로
LVM은 활성화를 강제 실행해야 합니다. 다시 말해, 단일 디스크에만 액세스할 수 있는 경우에도 LVM은 비쿼럼
rootvg를 활성화하려고(연결 변환) 시도합니다.
관련 개념
어댑터 또는 전원 공급장치 장애 시 고가용성
어댑터 또는 전원 공급장치 장애가 발생할 경우 시스템을 보호하려면, 사용자 요구사항에 따라 다음 중 하나 이상
을 수행하십시오.
논리적 볼륨 관리자 구성
LVM(논리적 볼륨 관리자)는 기본 운영 체제(BOS)와 함께 설치되므로 추가 구성이 필요하지 않습니다. 하지만
LVM이 디스크를 사용할 수 있으려면 디스크를 물리적 볼륨으로 구성 및 정의해야 합니다.
관련 태스크
애플리케이션을 위한 원시 논리적 볼륨 정의
원시 논리적 볼륨은 운영 체제나 파일 시스템에서 직접 제어를 받지 않고 데이터베이스나 파티션과 같은 애플리
케이션에서 직접 제어를 받는 물리적 및 논리적 디스크 공간의 한 영역입니다.
LVM 유지보수 명령 및 단축 경로
다음 표에는 LVM이 제어하는 엔터티(물리적, 논리적 볼륨, 볼륨 그룹, 파일 시스템)를 유지보수할 때 필요한 가장
단순한 태스크가 그룹별로 분류되어 있습니다.
표 2. 논리적 볼륨 및 스토리지 관리 태스크

태스크 SMIT 단축 경로 명령 또는 파일
볼륨 그룹 활성화 smit varyonvg
데이터가 없는 하드 디스크를 기존 smit extendvg

볼륨 그룹에 추가
데이터가 없는 하드 디스크를 새 볼 smit mkvg
륨 그룹에 추가
논리적 볼륨 추가주 1 smit mklv
볼륨 그룹 추가 smit mkvg
새 볼륨 그룹 추가 및 활성화 smit mkvg
데이터 할당을 사용하도록 논리적 smit chlv1

볼륨 변경
장치 관리 9
표 2. 논리적 볼륨 및 스토리지 관리 태스크 (계속)
볼륨 그룹 이름 변경주 2 1. smit varyoffvg 1. varyoffvg OldVGName
2. smit exportvg 2. exportvg OldVGName
3. smit importvg 3. importvg NewVGName
4. smit mountfs 4. mount all
자동 활성화를 사용하도록 볼륨 그 smit chvg

룹 변경
논리적 볼륨 정책 변경 또는 설정 smit chlv1
새 논리적 볼륨에 논리적 볼륨 복사 smit cplv

주3
크기가 동일한 기존 논리적 볼륨에 smit cplv

논리적 볼륨 복사주의 1
크기가 작은 기존 논리적 볼륨에 논 SMIT를 사용하지 마십시오.주의 2 1. 논리적 볼륨을 작성하십시오.
리적 볼륨 복사주의 1 주 3 예: mklv -y hdiskN vg00 4
2. 새 논리적 볼륨에 새 파일 시스
템을 작성하십시오. 예: crfs -v
jfs -d hdiskN -m /doc -A yes
3. 파일 시스템을 마운트하십시오.
예: mount /doc
4. 새 마운트 위치에 디렉토리를 작
성하십시오. 예: mkdir /doc/
options
5. 소스에서 대상 논리적 볼륨으로
파일 시스템을 전송하십시오.
예: cp -R /usr/adam/
oldoptions/* \ /doc/options
크기가 큰 기존 논리적 볼륨에 논리 smit cplv

적 볼륨 복사주의 1
볼륨 그룹 비활성화 smit varyoffvg
기록 검증 및 변경 계획 정책 사용 smit chlv1
가능하게 만들기
논리적 볼륨의 최대 크기 늘리기 smit chlv1
논리적 볼륨의 크기 늘리기 smit extendlv
볼륨 그룹별로 모든 논리적 볼륨 나 smit lslv2

열
시스템의 모든 물리적 볼륨 나열 smit lspv2
모든 볼륨 그룹 나열 smit lsvg2
물리적 볼륨의 상태, 논리적 볼륨 또 smit lspv

는 파티션 나열
볼륨 그룹의 내용 나열 smit lsvg1
논리적 볼륨의 상태 또는 맵핑 나열 smit lslv
표 2. 논리적 볼륨 및 스토리지 관리 태스크 (계속)
데이터 할당을 사용하거나 사용하 smit mklvcopy
지 않고 논리적 볼륨 미러
이동식 디스크 전원 차단 smit offdsk 핫 제거 기능이 지원될 경우에만 사
용할 수 있음
이동식 디스크 전원 공급 smit ondsk 핫 제거 기능이 지원될 경우에만 사
용할 수 있음
볼륨 그룹에서 미러링 제거 smit unmirrorvg
볼륨 그룹 제거 smit reducevg2
볼륨 그룹 재구성 smit reorgvg
디스크 구성 해제 및 전원 차단 smit rmvdsk1 또는 smit

rmvdsk 실행 후에 smit
opendoor 실행
주의:
1. 이 절차를 사용하여 기존 논리적 볼륨에 복사하면 사용자 확인을 요청하지 않고 해당 볼륨에 있던 데
이터가 겹쳐쓰입니다.
2. 큰 논리적 볼륨을 이보다 작은 논리적 볼륨에 복사할 때는 SMIT 절차나 cplv 명령을 사용하지 마십
시오. 이 경우, 수퍼 블록을 비롯한 일부 데이터가 작은 논리적 볼륨에 복사되지 않아서 파일 시스템이
손상될 수 있습니다.
참고:
1. 논리적 볼륨을 작성한 후에는 이 논리적 볼륨을 사용하는 LVM 구조가 없으므로 상태가 닫힙니다. 파일 시스
템이 논리적 볼륨에 마운트되었거나 논리적 볼륨이 원시 I/O를 위해 열릴 때까지 닫힌 상태로 남아 있습니다.
2. rootvg는 이름을 변경하거나 반입 또는 반출할 수 없습니다.
3. 특정 논리적 볼륨을 복제하려면 충분한 직접 액세스 스토리지가 있어야 합니다.
시스템 가동 중 디스크 추가
다음 절차에서는 시스템 전원을 차단하지 않고 디스크를 추가할 수 있는 핫 제거 기능을 사용하여 디스크를 켜고
구성하는 방법에 대해 설명합니다.
스토리지를 추가하기 위해 또는 디스크 장애를 해결하기 위해 디스크를 추가할 수 있습니다. 이 기능은 특정 시스
템에서만 사용할 수 있습니다.
1. 캐비넷의 사용 가능한 슬롯에 디스크를 설치하십시오. 설치 절차에 대한 자세한 정보는 시스템의 서비스 안내
서를 참조하십시오.
2. 명령행에 다음 단축 경로를 입력하여 새 디스크에 전원을 공급하십시오.
smit ondsk
이때, 시스템에 디스크가 추가되지만 아직 디스크를 사용할 수는 없습니다. 다음에 수행할 작업은 새 디스크에 데
이터가 포함되어 있는지 여부에 따라서 다릅니다.
• 디스크에 데이터가 없을 경우, 다음 방법 중 하나를 사용하여 디스크를 물리적 볼륨으로 볼륨 그룹에 추가하십
시오.
– 기존 볼륨 그룹에 디스크를 추가하려면 명령행에 다음 단축 경로를 입력하십시오.
smit extendvg
– 새 볼륨 그룹에 디스크를 추가하려면 명령행에 다음 단축 경로를 입력하십시오.
장치 관리 11
smit mkvg
• 디스크에 데이터가 포함된 경우 데이터를 반입하십시오.
논리적 볼륨의 이름 변경
다음 절차에서는 논리적 볼륨의 데이터를 그대로 유지하면서 논리적 볼륨의 이름을 바꾸는 방법을 설명합니다.
다음 예제에서는 논리적 볼륨 이름이 lv00에서 lv33으로 변경됩니다.
1. 다음을 입력하여, 논리적 볼륨과 연관된 모든 파일 시스템을 마운트 해제하십시오.
unmount /FSname
여기서 FSname은 파일 시스템의 전체 이름입니다.

참고:
a. 마운트 해제하려는 파일 시스템이 현재 사용 중인 경우 unmount 명령은 실패합니다. unmount 명령은
파일 시스템이 열려 있지 않고 사용자의 현재 디렉토리가 해당 장치에 있지 않은 경우에만 실행됩니다.
b. unmount 명령의 또 다른 이름은 umount입니다. 이들 이름은 바꿔 사용할 수 있습니다.
2. 다음을 입력하여 논리적 볼륨의 이름을 바꾸십시오.
chlv -n NewLVname OldLVname
여기서 -n 플래그는 새 논리적 볼륨의 이름(NewLVname)을 지정하고 OldLVname은 변경할 이름입니다. 예

를 들어 다음과 같습니다.
chlv -n lv33 lv00
참고: JFS 또는 JFS2 로그의 이름을 바꿀 경우, 이름이 바뀐 로그 장치를 사용하는 모든 파일 시스템에서
chfs 명령을 실행할지 묻는 프롬프트가 표시됩니다.
3. 다음을 입력하여, 12 페이지의 『1』단계에서 마운트 해제한 파일 시스템을 다시 마운트하십시오.
mount /test1
이때, 논리적 볼륨의 이름이 바뀌고 사용할 수 있게 됩니다.
논리적 볼륨을 또 다른 물리적 볼륨으로 복사하기

사용자의 필요에 따라 몇 가지 방법으로, 다른 물리적 볼륨에 논리적 볼륨을 복사하면서 파일 시스템 무결성을 유
지할 수 있습니다.
논리적 볼륨이나 JFS를 다른 물리적 볼륨에 사용하는 방법에는 여러 가지가 있습니다. 고유한 요구사항에 가장
적합한 방법을 선택하십시오.
논리적 볼륨 복사
논리적 볼륨을 복사하는 가장 간단한 방법은 cplv 명령을 사용하여 원래 논리적 볼륨을 복사한 다음 대상 물리
적 볼륨에 새 논리적 볼륨을 작성하는 것입니다.
1. 논리적 볼륨 사용을 정지하십시오. 파일 시스템을 마운트 해제하고, 논리적 볼륨에 액세스하는 애플리케이션
을 정지하십시오.
2. 원래 논리적 볼륨의 데이터를 모두 포함할 수 있는 용량이 되는 물리적 볼륨을 선택하십시오.
주의: 데이터가 포함된 큰 논리적 볼륨을 이보다 작은 논리적 볼륨에 복사할 경우, 수퍼 블록을 비롯한
일부 데이터가 유실되어 파일 시스템이 손상될 수 있습니다.
3. 최초 논리적 볼륨을 복사하십시오(이 예에서는 lv00으로 지정됨). 그리고 다음 명령을 사용하여 새로 작성하
십시오.
참고: 다음 cplv 명령이 새 논리적 볼륨을 작성하는데 이 볼륨 그룹이 동시 모드로 연결 변환된 경우에는 명
령이 실패합니다.
cplv lv00
4. 파일 시스템을 마운트하고 애플리케이션을 재시작하여 논리적 볼륨 사용을 시작하십시오.
이때, 논리적 볼륨 사본이 사용 가능하게 됩니다.
원래 논리적 볼륨을 사용 가능한 상태로 유지하면서 논리적 볼륨 복사

사용자 환경에서 원래 논리적 볼륨을 계속해서 사용해야 하는 경우, 다음 예제와 같이 splitlvcopy 명령을 사
용하여 해당 내용을 복사할 수 있습니다.
1. 다음 SMIT 단축 경로를 사용하여 논리적 볼륨을 미러하십시오.
smit mklvcopy
2. 논리적 볼륨 사용을 정지하십시오. 파일 시스템을 마운트 해제하고, 논리적 볼륨에 액세스하는 애플리케이션
을 정지하거나 정지 모드로 전환하십시오.
주의: 다음 단계에서는 splitlvcopy 명령을 사용합니다. 논리적 볼륨을 분할하기 전에는 항상 논리

적 볼륨을 닫고 이 명령을 사용하기 전에 논리적 볼륨이 포함된 파일 시스템을 마운트 해제하십시오.
열려 있는 논리적 볼륨을 분할할 경우 파일 시스템이 손상될 수 있으며, 여러 프로세스에서 동시에 이
논리적 볼륨에 액세스할 경우에는 원래 논리적 볼륨과 사본 간에 일관성이 유지되지 않게 됩니다.
3. 루트 권한으로, 다음 명령을 사용하여 원래 논리적 볼륨(oldlv)을 새 논리적 볼륨(newlv)에 복사하십시오.
splitlvcopy -y newlv oldlv
-y 플래그는 새 논리적 볼륨의 이름을 지정합니다. oldlv 볼륨에 논리적 볼륨 제어 블록이 없을 경우,
splitlvcopy 명령이 성공적으로 완료되기는 하지만 논리적 볼륨 제어 블록 없이 newlv 볼륨이 작성되었
음을 나타내는 메시지가 생성됩니다.
4. 파일 시스템을 마운트하고 애플리케이션을 재시작하여 논리적 볼륨 사용을 시작하십시오.
이때, 논리적 볼륨 사본이 사용 가능하게 됩니다.
다른 물리적 볼륨에 원시 논리적 볼륨 복사

다른 물리적 볼륨에 원시 논리적 볼륨을 복사하려면 다음 단계를 수행하십시오.
1. 다음 명령을 사용하여, 볼륨 그룹의 새 물리적 볼륨에 논리적 볼륨의 미러 사본을 작성하십시오.
mklvcopy LogVol_name 2 new_PhysVol_name
2. 다음 명령을 사용하여, 새 미러 사본의 파티션을 동기화하십시오.

syncvg -l LogVol_name
3. 다음 명령을 사용하여, 물리적 볼륨에서 논리적 볼륨 사본을 제거하십시오.

rmlvcopy LogVol_name 1 old_PhysVol_name
이때, 원시 논리적 볼륨 사본이 사용 가능하게 됩니다.
사용자 정의 볼륨 그룹용 전용 디스크에 파일 시스템 로그 작성

JFS 또는 JFS2 파일 시스템 로그는 파일 시스템 트랜잭션 레코드가 형식화된 리스트입니다. 트랜잭션이 완료되
기 전에 시스템이 작동 중지되는 경우에 로그는 파일 시스템의 무결성(그러나 반드시 데이터 무결성일 필요는 없
음)을 보증합니다.
시스템이 설치될 때 rootvg용 hd8에 전용 디스크가 작성됩니다. 다음 절차에서는 다른 볼륨 그룹에 대한 별도의
디스크에 JFS 로그를 작성하는 방법을 보여 줍니다. JFS2 로그를 작성할 경우에는 이 절차에서 다음 사항이 변경
되어야 합니다.
• 로그 장치 유형이 jfs2log입니다.
• logform 명령에는 JFS2 로그 장치를 지정하기 위해 -V jfs2 옵션이 필요합니다.
• crfs 명령에 jfs 대신 jfs2를 지정해야 합니다.
장치 관리 13
참고: JFS2 로그가 파일 시스템으로서 별도의 디스크에 있어야 한다는 요구사항은 없습니다. 유일한 요구사항은
로그 장치가 파일 시스템과 동일한 볼륨 그룹에 있어야 한다는 것입니다. 이 프로시저에서는 JFS2 로그는 성능
향상을 위해 별도의 디스크에 있어야 합니다.
사용자 정의 볼륨 그룹을 위해 파일 시스템 로그 파일을 작성하면 NFS 서버가 있고 이 서버의 트랜잭션이 다른 프
로세스와 경합하지 않고 처리되기를 원하는 경우와 같은 특정 조건에서 성능을 향상시킬 수 있습니다.
두 개의 물리적 볼륨(hdisk1 및 hdisk2)을 사용하여 볼륨 그룹(fsvg1)을 작성하는 다음 프로시저를 사용할 수 있
습니다. 파일 시스템은 hdisk2(/u/myfs에 마운트되는 256MB 파일 시스템)에 있고 로그는 hdisk1에 있습니다.
JFS의 디폴트 로그 크기는 4MB입니다. 성능에 영향을 미치지 않고 자주 사용하지 않는 프로그램(예: /blv)을 로
그와 동일한 물리적 볼륨에 배치할 수 있습니다.
SMIT 및 명령행 인터페이스를 사용하여 사용자 정의 볼륨 그룹에 대해 JFS 로그를 작성하려면 다음 단계를 수행
하십시오.
1. SMIT 단축 경로를 사용하여 새 볼륨 그룹(이 예에서는 fsvg1)을 추가하십시오.
smit mkvg
2. SMIT 단축 경로를 사용하여 새 논리적 볼륨을 이 볼륨 그룹에 추가하십시오.

smit mklv
3. 논리적 볼륨 추가 화면에서, 다음 필드에 데이터를 추가하십시오. 예를 들어 다음과 같습니다.

Logical Volumes NAME fsvg1log
Number of LOGICAL PARTITIONS 1
PHYSICAL VOLUME names hdisk1
Logical volume TYPE jfslog
POSITION on Physical Volume center
4. 필드를 설정한 후, Enter 키를 눌러 변경사항을 승인하고 SMIT를 종료하십시오.

5. 명령행에 다음 명령을 입력하십시오.
/usr/sbin/logform /dev/fsvg1log
6. 다음 프롬프트가 나타나면 y를 입력하고 Enter를 누르십시오.

Destroy /dev/fsvg1log
이 프롬프트가 의미하는 바와는 달리 어떤 것도 삭제되지 않습니다. 이 프롬프트에 y를 응답하면 시스템은

파일 시스템 트랜잭션을 레코드할 수 있도록 JFS 로그의 논리적 볼륨을 형식화합니다.
7. 다음 SMIT 단축 경로를 사용하여 또 다른 논리적 볼륨을 추가하십시오.
smit mklv
8. 2단계에서 사용한 것과 동일한 볼륨 그룹의 이름(이 예제에서는 fsvg1)을 입력하십시오. 논리적 볼륨 화면

에서, 다음 필드에 데이터를 추가하십시오. 이 논리적 볼륨에는 3단계에서 지정한 것과는 다른 물리적 볼륨
을 지정해야 합니다. 예를 들어 다음과 같습니다.
Logical Volumes NAME fslv1
Number of LOGICAL PARTITIONS 64
PHYSICAL VOLUME names hdisk2
Logical volume TYPE jfs
필드를 설정한 후, Enter 키를 눌러 변경사항을 승인하고 SMIT를 종료하십시오.

9. 파일 시스템을 새 논리적 볼륨에 추가하고, 로그를 지정하고, 다음 명령 순서를 사용하여 새 파일 시스템을
마운트하십시오.
crfs -v jfs -d LogVolName -m FileSysName -a logname=FSLogPath
mount FileSysName
여기서 LogVolName은 단계 2에서 작성한 논리적 볼륨의 이름이고, FileSysName은 이 논리적 볼륨에 마운
트하고 싶은 파일 시스템의 이름이고, FSLogPath는 단계 2에서 작성한 논리적 볼륨의 이름입니다. 예를 들
어 다음과 같습니다.
crfs -v jfs -d fslv1 -m /u/myfs -a logname=/dev/fsvg1log
mount /u/myfs
10. 파일 시스템과 로그를 올바르게 설정했는지 검증하려면 다음 명령(볼륨 그룹 이름을 대체함)을 입력하십시
오.
lsvg -l fsvg1
출력은 다음 예에서와 같이 사용자의 파일 시스템 유형으로 작성한 두 개의 논리적 볼륨 모두를 표시합니다.

LV NAME TYPE ...
/dev/fsvg1log jfslog ...
fslv1 jfs ...
별도의 물리적 볼륨에 두 개 이상의 논리적 볼륨을 포함하는 볼륨 그룹을 작성했고 이러한 논리적 볼륨 중 하나에
는 파일 시스템 로그가 들어 있습니다.
참고: 중복성을 제공하기 위해 JFS2 로그 장치에 논리적 볼륨 레벨에서 미러링을 제공할 수 있습니다. 그러나, 미
러링을 제공하는 것은 일반적인 사례가 아니므로 필요하지 않습니다.
볼륨 그룹 반입 또는 반출
다음 표에서는 반입 및 반출을 통해 한 시스템에서 다른 시스템으로 사용자 정의 볼륨 그룹을 이동하는 방법을 설
명합니다. rootvg 볼륨 그룹은 반출하거나 반입할 수 없습니다.
반출 프로시저는 시스템에서 볼륨 그룹의 정의를 제거합니다. 반입 프로시저는 새 시스템에 볼륨 그룹을 도입합
니다.
반입 프로시저를 사용하여 이전에 연관되어 있었지만 반출되었던 시스템으로 볼륨 그룹을 다시 도입할 수도 있
습니다. 또한 반입 및 반출을 통해 데이터가 포함된 물리적 볼륨을 볼륨 그룹에 추가할 수도 있습니다. 데이터가
포함된 디스크를 해당 볼륨 그룹에 추가하면 됩니다.
주의: 반입된 논리적 볼륨과 이름이 같은 논리적 볼륨이 새 시스템에 이미 있을 경우, importvg 명령은
반입된 논리적 볼륨의 이름을 변경합니다. importvg 명령이 논리적 볼륨의 이름을 바꿔야 할 경우, 표준
오류에 오류 메시지를 출력합니다. 이름이 충돌되지 않으면 importvg 명령이 /etc/filesystems 파
일에 파일 마운트 위치와 항목도 작성합니다.
볼륨 그룹 반입 및 반출 태스크
볼륨 그룹 가져오기 smit importvg
볼륨 그룹 반출 1. 볼륨 그룹의 논리적 볼륨에 있는

파일 시스템을 마운트 해제하십
시오. smit umntdsk
2. 볼륨 그룹의 연결 변환을 해제하
십시오. smit varyoffvg
3. 볼륨 그룹을 반출하십시오.
smit exportvg
주의: 페이징 공간이 활성화되어 있는 동안에는 페이징 공간 볼륨이 있는 볼륨 그룹을 반출할 수 없습니
다. 활성 페이징 공간이 있는 볼륨 그룹을 반출하기 전에, 다음 명령을 입력하여 시스템 초기화 시 페이징
공간이 자동으로 활성화되지 않았는지 확인하십시오.
장치 관리 15
chps -a n paging_space name
그런 다음 시스템을 재부트하여 페이징 공간을 비활성화하십시오.
물리적 볼륨의 컨텐츠 마이그레이션

하나 이상의 지정된 물리적 볼륨에 속하는 물리적 파티션을 볼륨 그룹에 있는 하나 이상의 다른 물리적 볼륨으로
이동하려면 다음 지시사항을 따르십시오. 장애가 발생한 디스크를 대체하거나 복구하기 전에 디스크의 데이터를
다른 곳으로 이동할 때도 이 절차를 사용할 수 있습니다. 이 프로시저는 루트 볼륨 그룹 또는 사용자 정의 볼륨 그
룹의 물리적 볼륨에 사용할 수 있습니다.
주의: 부트 논리적 볼륨이 물리적 볼륨에서 이주된 경우, 소스의 부트 레코드를 지워야 합니다. 그렇지 않
으면 시스템이 정지될 수 있습니다. bosboot 명령을 실행할 경우, 다음 절차의 4단계에 설명된 chpv -
c 명령도 실행해야 합니다.
1. 데이터를 새 디스크로 마이그레이션하려면 다음 단계를 수행하십시오. 그렇지 않으면 2단계로 진행하십시
오.
a. 다음을 입력하여, 시스템에서 디스크를 인식할 수 있는지, 그리고 디스크가 사용 가능한지 확인하십시오.
lsdev -Cc disk
출력은 다음과 같습니다.

hdisk0 Available 10-60-00-8,0 16 Bit LVD SCSI Disk Drive
b. 디스크가 나열되고 사용 가능 상태이면 다음을 입력하여 디스크가 다른 볼륨 그룹에 속하지 않는지 확인

하십시오.
lspv
다음과 유사한 출력이 표시됩니다.

hdisk0 0004234583aa7879 rootvg active
hdisk1 00042345e05603c1 none active
hdisk2 00083772caa7896e imagesvg active
이 예제에서 hdisk1은 대상 디스크로 사용될 수 있습니다. 세 번째 필드를 보면 현재 이 디스크가 볼륨 그

룹에 사용되고 있지 않음을 알 수 있습니다.
새 디스크가 나열되지 않거나 사용할 수 없으면 디스크나 논리적 볼륨 스토리지를 구성해야 합니다.
c. 다음을 입력하여 볼륨 그룹에 새 디스크를 추가하십시오.
extendvg VGName diskname
여기서 VGName은 사용자 볼륨 그룹의 이름이고, diskname은 새 디스크의 이름입니다. 앞 단계의 예제에
서 diskname은 hdisk1로 대체됩니다.
2. 소스와 대상 물리적 볼륨이 동일한 볼륨 그룹에 있어야 합니다. 두 물리적 볼륨 모두 볼륨 그룹에 있는지 확인
하려면 다음을 입력하십시오.
lsvg -p VGname
여기서 VGname은 사용자의 볼륨 그룹 이름입니다. 루트 볼륨 그룹에 대한 출력은 다음과 유사합니다.

rootvg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk0 active 542 85 00..00..00..26..59
hdisk1 active 542 306 00..00..00..00..06
FREE PP의 수에 주목하십시오.

3. 대상 디스크에, 소스 디스크를 이동할 충분한 공간이 있는지 확인하십시오.
a. 다음을 입력하여 소스 디스크의 물리적 파티션 수를 확인하십시오.
lspv SourceDiskName | grep "USED PPs"
여기서 SourceDiskName은 hdisk0과 같은 소스 디스크의 이름입니다. 다음과 유사한 출력이 표시됩니다.

USED PPs: 159 (636 megabytes)
이 예제의 경우, 마이그레이션을 성공적으로 완료하려면 대상 디스크에 159개의 FREE PP가 있어야 합니
다.
b. 소스 디스크의 USED PP 수를 대상 디스크(2단계)의 FREE PP 수와 비교하십시오. FREE PP 수가 USED
PP 수보다 크면 마이그레이션할 공간이 충분합니다.
4. rootvg 볼륨 그룹의 디스크에서 데이터를 마이그레이션할 경우에만 이 단계를 수행하십시오.
사용자 정의 볼륨 그룹의 디스크에서 데이터를 마이그레이션할 경우에는 5단계로 건너 뛰십시오.
다음을 입력하여, 부트 논리적 볼륨(hd5)이 소스 디스크에 있는지 확인하십시오.
lspv -l SourceDiskNumber | grep hd5
출력이 표시되지 않으면 부트 논리적 볼륨이 소스 디스크에 없음을 나타냅니다. 5단계로 진행하십시오.
다음과 유사한 출력이 표시될 경우에는
hd5 2 2 02..00..00..00..00 /blv
다음 명령을 실행하십시오.
migratepv -l hd5 SourceDiskName DestinationDiskName
대상 디스크에서 bosboot 명령을 실행하라는 메시지가 나타납니다. mkboot -c 명령도 실행하여 소스의
부트 레코드를 지워야 합니다. 다음 명령을 순서대로 입력하십시오.
bosboot -a -d /dev/DestinationDiskName
bootlist -m normal DestinationDiskName
mkboot -c -d /dev/SourceDiskName
5. 다음 SMIT 단축 경로를 입력하여 데이터를 마이그레이션하십시오.

smit migratepv
6. 물리적 볼륨을 나열한 후, 앞에서 검토한 소스 물리적 볼륨을 선택하십시오.

7. 대상 물리적 볼륨 필드로 이동하십시오. 디폴트 값을 승인할 경우, 볼륨 그룹의 모든 물리적 볼륨을 전송할 수
있게 됩니다. 그렇지 않으면, 이동할 파티션(4단계에서)에 적합한 공간이 있는 디스크를 하나 이상 선택하십
시오.
8. 필요하면 이 논리적 볼륨 필드에 속하는 데이터만 이동으로 이동한 다음 논리적 볼륨을 나열하고 선택하십시
오. 이 경우, 소스 물리적 볼륨으로 선택된 물리적 볼륨에 있는 논리적 볼륨 중 지정된 논리적 볼륨에 할당된
물리적 파티션만 이동하게 됩니다.
9. Enter 키를 눌러 물리적 파티션을 이동하십시오.
이때, 데이터가 새(대상) 디스크에 상주하게 됩니다. 하지만 원래(소스) 디스크는 볼륨 그룹에 남아 있습니다. 디
스크가 여전히 신뢰할 수 있는 경우에는 이를 계속해서 핫 스패어로 사용할 수 있습니다. 특히 디스크에 장애가
발생한 경우 다음 단계를 수행하는 것이 좋습니다.
1. 볼륨 그룹에서 소스 디스크를 제거하려면 다음을 입력하십시오.
reducevg VGNname SourceDiskName
2. 시스템에서 소스 디스크를 실제로 제거하려면 다음을 입력하십시오.

rmdev -l SourceDiskName -d
디스크 구성
다양한 방법으로 새 디스크를 구성할 수 있습니다.
다음과 같은 방법으로 새 디스크를 구성할 수 있습니다.
장치 관리 17
• 시스템을 종료하고 전원을 끌 수 있는 경우, 방법 1을 사용하십시오. 시스템에 물리적 디스크를 연결할 때는 항
상 시스템을 종료하고 전원을 끄는 것이 바람직합니다.
• 시스템을 종료하고 전원을 끌 수 없지만 서브클래스, 상위 이름 및 연결된 위치와 같은 디스크 세부 정보를 알
고 있는 경우, 방법 2를 사용하십시오.
• 시스템을 종료하고 전원을 끌 수 없으며 디스크 위치만 알고 있는 경우, 방법 3을 사용하십시오.
디스크를 구성한 후에는 대개 곧바로 사용할 수 있지만, 논리적 볼륨 관리자가 디스크를 물리적 볼륨으로 식별해
야 할 경우도 있습니다.
방법 1
디스크를 연결하기 전에 시스템을 종료하고 전원을 끌 수 있을 때는 다음 방법을 사용하십시오.
1. 시스템에 새 디스크를 물리적으로 연결한 다음 시스템과 함께 제공된 문서를 참조하여 디스크와 시스템의 전
원을 켜십시오.
2. 시스템 부트 중, 구성 관리자(cfgmgr)가 자동으로 디스크를 구성하도록 하십시오.
3. 시스템 부트 후, 루트 권한으로 명령행에 lspv 명령을 입력하여 새 디스크 이름을 검색하십시오.
시스템에서 다음 중 하나와 유사한 항목을 리턴합니다.
hdisk1 none none
또는
hdisk1 00005264d21adb2e none
첫 번째 필드는 시스템에서 지정한 디스크 이름을 식별합니다. 두 번째 필드는 물리적 볼륨 ID(PVID)를 표시

합니다(있는 경우). lspv 출력에 새 디스크가 나타나지 않으면 설치 및 마이그레이션을 참조하십시오.
이 때 디스크는 시스템이 사용할 수 있지만 LVM이 사용하려면 PVID가 있어야 합니다. 새 디스크에 PVID가 없으
면 19 페이지의 『사용 가능한 디스크를 물리적 볼륨으로 설정』의 내용을 참조하십시오.
방법 2
시스템을 종료하고 전원을 끌 수 없지만 새 디스크에 대해 다음과 같은 정보를 알고 있을 때는 다음 방법을 사용
하십시오.
• 디스크가 접속된 방법(서브클래스)
• 디스크 유형(유형)
• 디스크가 연결된 시스템 접속장치(상위 이름)
• 디스크의 논리적 주소(연결된 위치)
다음과 같이 하십시오.
2. 디스크를 구성하고, 물리적 볼륨에서 디스크를 사용할 수 있는지 확인하려면 다음 예제에서와 같이 플래그와
함께 mkdev 명령을 사용하십시오.
mkdev -c disk -s scsi -t 2200mb -p scsi3 \

-w 6,0 -a pv=yes
이 예제에서는 SCSI ID가 6이고 논리적 장치 번호가 0인 2.2GB 크기 디스크를 scsi3 SCSI 버스에 추가합니
다. -c 플래그는 장치의 클래스를 정의합니다. -s 플래그는 서브클래스를 정의합니다. -t 플래그는 장치의 유
형을 정의합니다. -p 플래그는 지정할 상위 장치 이름을 정의합니다. -w 플래그는 SCSI ID 및 논리적 장치 번
호에 따른 디스크 위치를 지정합니다. -a 플래그는 장치 속성-값 쌍 pv=yes를 지정합니다. 그러면 디스크가
물리적 볼륨으로 변경되고 고유한 물리적 볼륨 ID가 있는 부트 레코드가 디스크에 기록됩니다(없는 경우).
이때 디스크가 사용 가능한 장치 및 물리적 볼륨으로 정의됩니다. 명령행에서 lspv 명령을 입력하여 새 디스크
항목을 나열할 수 있습니다. lspv 출력에 새 디스크가 나타나지 않으면 설치 및 마이그레이션을 참조하십시오.
방법 3
시스템을 종료하고 전원을 끌 수 없으며 디스크 위치만 알고 있을 때는 다음 방법을 사용하십시오.
2. 물리적 디스크가 시스템에 이미 구성되어 있는지 확인하려면 명령행에 lspv 명령을 입력하십시오. lspv 명
령에 대한 자세한 정보는 lspv command 주제를 참조하십시오. 다음과 유사한 출력이 표시됩니다.
hdisk0 000005265ac63976 rootvg
3. 명령행에 cfgmgr을 입력하여 구성 관리자를 표시하십시오. 구성 관리자는 새 디스크를 비롯하여 시스템에

새로 연결된 모든 장치를 자동으로 검색하고 구성합니다. cfgmgr 명령에 대한 자세한 정보는 cfgmgr을 참
조하십시오.
4. 새 디스크가 구성되었는지 확인하려면 lspv 명령을 다시 입력하십시오. 다음 중 하나와 유사한 출력이 표시
됩니다.
hdisk1 none none
또는
hdisk1 00005264d21adb2e none
첫 번째 필드는 시스템에서 지정한 디스크 이름을 식별합니다. 두 번째 필드는 물리적 볼륨 ID(PVID)를 표시

합니다(있는 경우). lspv 출력에 새 디스크가 나타나지 않으면 설치 및 마이그레이션을 참조하십시오.
이 때 디스크는 시스템이 사용할 수 있지만 LVM이 사용하려면 PVID가 있어야 합니다. 새 디스크에 PVID가 없으
면 19 페이지의 『사용 가능한 디스크를 물리적 볼륨으로 설정』의 내용을 참조하십시오.
사용 가능한 디스크를 물리적 볼륨으로 설정

디스크를 볼륨 그룹에 지정하고 LVM에서 사용하려면 먼저 디스크를 물리적 볼륨으로 구성해야 합니다.
다음 지시사항을 사용하여 물리적 볼륨을 구성하십시오.
1. 디스크가 운영 체제에서 인식되는지, 사용 가능한지 및 운영 체제 또는 임의의 애플리케이션에 의해 사용되고
있지 않은지 확인하십시오. 명령행에 lspv 명령을 입력하십시오. 다음과 유사한 출력이 표시됩니다.
hdisk1 none none
출력에서 다음 사항을 확인하십시오.

• 새 디스크의 이름이 명령 출력에 표시되지 않으면 17 페이지의 『디스크 구성』의 내용을 참조하십시오.
• 출력의 두 번째 필드에 시스템 생성 물리적 볼륨 ID(PVID)(예: 00005264d21adb2e)가 표시되면 디스크
가 이미 물리적 볼륨으로 구성된 것이므로 이 프로시저를 수행할 필요가 없습니다.
• 출력의 세 번째 필드에 볼륨 그룹 이름(예: rootvg)이 표시되면 디스크가 현재 사용 중이므로 이 프로시저
에 적합하지 않습니다.
새 디스크에 PVID가 없고 현재 사용 중이 아니면 다음 단계를 계속하십시오.
2. 사용 가능한 디스크를 물리적 볼륨으로 변경하려면 명령행에 chdev 명령을 입력하십시오. 예를 들어 다음과
같습니다.
chdev -l hdisk3 -a pv=yes
-l 플래그는 디스크의 장치 이름을 지정합니다. -a 플래그는 장치 속성-값 쌍 pv=yes를 지정합니다. 그러면

디스크가 물리적 볼륨으로 변경되고 고유한 물리적 볼륨 ID가 있는 부트 레코드가 디스크에 기록됩니다(없는
경우).
이 때 디스크가 물리적 볼륨으로 정의됩니다. 명령행에 lspv 명령을 입력하여 새 디스크 항목을 나열할 수 있습
니다.
rootvg의 PVID 및 VGID 변경

시스템 부트 단계 동안에 rootvg 볼륨 그룹의 물리적 볼륨 ID(PVID) 및 볼륨 그룹 ID(VGID)를 변경할 수 있습니
다.
장치 관리 19
rootvg의 PVID 및 VGID를 변경하려면 값 2로 sys0 dev ghostdev 속성을 설정하고 시스템을 재부트하십시오.
sys0 device ghostdev 속성은 비트 방식 플래그입니다.
• rootvg 볼륨 그룹의 PVID 및 VGID를 변경하기 위해 sys0 device ghostdev 속성을 설정하려면 다음 명령을 입
력하십시오.
chdev -l sys0 -a ghostdev=2
참고: ipl_varyon 명령이 rootvg에서 모든 디스크의 PVID 및 VGID를 변경한 후에 sys0 device ghostdev 속
성의 값 2가 설정 해제됩니다. rootvg 디스크의 PVID를 변경하기 위한 chdev 명령이 실패하면 ipl_varyon
명령은 경고 메시지를 전송하고 rootvg에서 계속 연결 변환합니다. rootvg에서 디스크의 PVID를 변경하기 위
한 chdev 명령이 실패하고 다음 재부트 동안에 PVID 및 VGID를 변경하고 싶은 경우에는 sys0 device
ghostdev 속성을 다시 2로 설정하십시오.
• ghostdev 속성의 값을 나열하려면 다음 명령을 입력하십시오.
lsattr -E -l sys0 -a ghostdev
미러링된 볼륨 그룹에서 실패한 물리적 볼륨 대체

다음 프로시저는 미러링된 볼륨 그룹 내에서 실패한 물리적 볼륨(PV)을 대체합니다. replacepv 명령은 대부
분의 구성에서 실패한 PV의 대체 메소드를 제공합니다. 또한 replacepv 명령을 사용할 수 없는 구성에 대한
대체 프로시저도 제공합니다.
소개
이 시나리오의 정보는 특정 버전의 AIX를 사용하여 테스트했습니다. 결과는 AIX 버전 및 레벨에 따라 차이가 있
을 수 있습니다.
실패한 PV를 사용하는 모든 논리적 볼륨에는 기타 사용 가능한 PV에 대한 유효한 사본이 있습니다. 이 때 전용 덤
프 논리적 볼륨은 제외될 수 있습니다.
replacepv 명령을 사용하여 실패한 PV 대체

다음 전제조건을 충족할 수 없으면 대체 프로시저를 참조하십시오.
• 실패한 PV를 포함하는 볼륨 그룹이 rootvg가 아닙니다.
• 교체 PV는 실패한 PV를 포함하는 볼륨 그룹에 추가될 수 있습니다. PV당 최대 PP 등의 볼륨 그룹 특성 및 PV
크기에 따라 가능하지 않을 수도 있습니다.
• 교체 PV가 실패한 PV와 동시에 시스템에 구성될 수 있어야 합니다.
• 교체 PV의 이름이 실패한 PV의 이름과 다를 수 있습니다.
• 교체 PV의 크기는 최소한 실패한 PV의 크기보다 커야 합니다.
• 실패한 PV를 포함하는 볼륨 그룹은 스냅샷 볼륨 그룹이 아니거나 스냅샷 볼륨 그룹이 없어야 합니다.
실패한 PV가 hdisk2이며 교체 PV가 hdisk10라고 가정하고 다음 단계를 완료하십시오.
1. 대체 PV가 아직 시스템에 설치되지 않은 경우, 필요한 단계를 수행하여 설치하십시오. 구성 관리자를 사용하
여 새 PV를 정의하려면 다음 명령을 실행하십시오.
cfgmgr
PV에 지정된 이름을 판별하려면 lspv 명령을 사용하십시오. 이 예제에서는 새 PV의 이름을 hdisk10으로
가정합니다.
2. 실패한 PV를 1단계에서 정의한 PV로 대체하려면 다음 명령을 실행하십시오.
replacepv hdisk2 hdisk10
명령이 실행되면 hdisk2가 hdisk10으로 대체되고 hdisk2가 더 이상 볼륨 그룹에 지정되지 않습니다.

3. 실패한 PV를 정의 해제하려면 다음 명령을 실행하십시오.
rmdev -dl hdisk2
4. 실패한 디스크를 시스템에서 실제로 제거하십시오.

5. 다음 단계를 완료하여 프로시저가 성공적인지 확인하십시오.
a. 지정된 대로 새 PV로 모든 논리적 볼륨이 미러링되는지 확인하려면 다음 명령을 실행하십시오.
lslv lvname
실패한 PV의 영향을 받은 각 논리적 볼륨의 COPIES 속성을 확인하여 이제 필요한 만큼의 사본이 있는지
확인하십시오. 논리적 볼륨의 사본 개수가 원하는 개수 미만인 경우, mklvcopy 명령을 사용하여 추가 사
본을 작성하십시오.
b. 모든 논리적 볼륨 파티션이 동기화되고 효력이 상실된 파티션이 없는지 확인하려면 다음 명령을 실행하십
시오.
lspv hdisk10
대체된 PV의 STALE PARTITIONS 속성에서 개수가 0인지 확인하십시오. 효력이 상실된 파티션이 있으
면 syncvg 명령을 사용하여 파티션을 동기화하십시오.
5단계는 실패한 PV에 대한 교체 프로시저를 완료합니다.
구성에서 replacepv 명령을 사용할 수 없는 경우 실패한 PV 대체

실패한 물리적 볼륨 hdisk0과 해당 미러 hdisk1이 yourvg 볼륨 그룹의 일부라고 가정하십시오.
1. 실패한 PV에서 미러 사본을 제거하려면 다음 명령을 실행하십시오.
unmirrorvg yourvg hdisk0
2. rootvg에서 PV가 실패하면 다음 명령을 실행하여 부트 리스트에서 hdisk0을 제거하십시오.

참고: 구성에서 hdisk0과 hdisk1 이외의 부트 장치를 사용하면 부트 장치를 명령 구문에 추가하십시오.
bootlist -om normal hdisk1
이 단계에서는 hdisk1이 rootvg 내의 부트 가능 장치에 남아 있어야 합니다. 이 단계를 완료한 후에

hdisk0이 출력에 표시되지 않는지 확인하십시오.
3. rootvg에서 PV 실패가 발생한 경우 실패한 PV로부터 전용 덤프 장치를 모두 다시 작성하십시오.
실패한 PV에 있었던 전용 덤프 장치를 가지고 있을 경우, mklv 명령을 사용하여 기존 PV에 새 논리적 볼륨
을 작성할 수 있습니다. 새 논리적 볼륨을 1차 덤프 장치로 설정하려면, sysdumpdev 명령을 사용하십시오.
4. 실패한 PV를 정의 해제하려면 다음 명령을 실행하십시오.
참고: 디스크 장치 항목을 제거하면 실패한 PV가 시스템을 부팅하는 데 사용된 PV인 경우 /dev/ipldevice 하
드 링크도 제거됩니다.
reducevg yourvg hdisk0

rmdev -dl hdisk0
5. 실패한 PV가 가장 최근에 사용된 부트 장치인 경우, 다음 명령을 실행하여 4단계에서 제거된 /dev/
ipldevice 하드 링크를 다시 작성하십시오.
ln /dev/rhdisk1 /dev/ipldevice
PV 이름 앞에 r이라는 접두어가 있다는 점에 주목하십시오.

/dev/ipldevice 하드 링크가 다시 작성되었는지 확인하려면 다음 명령을 실행하십시오.
ls /dev/ipldevice
6. 실패한 디스크를 대체하십시오.

7. 새 PV를 정의하려면 다음 명령을 실행하십시오.
장치 관리 21
cfgmgr
cfgmgr 명령은 대체 PV에 PV 이름을 지정합니다. 대개 새로 지정되는 PV 이름은 이전에 실패한 PV에 지정
되었던 이름과 동일합니다. 이 예제에서는 hdisk0 장치가 교체 PV에 지정된다고 가정합니다.
8. 새 PV를 볼륨 그룹에 추가하려면 다음 명령을 실행하십시오.
extendvg yourvg hdisk0
다음 오류 메시지가 표시될 수도 있습니다.

0516-050 Not enough descriptor space left in this volume group.
Either try adding a smaller PV or use another volume group.
이 오류가 발생하고 PV를 볼륨 그룹에 추가할 수 없는 경우, 이미 볼륨 그룹에 존재하는 다른 PV에 논리적 볼
륨을 미러링하거나 더 작은 PV를 추가하는 방법을 시도할 수 있습니다. 가능한 옵션이 없으면 chvg 명령을
사용하여 볼륨 그룹을 대형 유형 또는 확장 가능 유형 볼륨 그룹으로 업그레이드하여 이 제한을 극복할 수 있
습니다.
9. 볼륨 그룹을 미러링하십시오.
참고: 다음 조건이 모두 해당되면 mirrorvg 명령을 사용할 수 없습니다.
• 목표 시스템이 논리적 파티션(LPAR)입니다.
• 부트 논리적 볼륨(디폴트로 hd5)의 사본이 실패한 PV에 상주합니다.
• 대체 PV의 어댑터가 마지막 콜드 부트(cold boot) 후 LPAR에 동적으로 구성되었습니다.
위의 조건이 모두 해당되면 mklvcopy 명령을 사용하여 다음과 같이 각 논리적 볼륨의 미러 사본을 다시 작
성하십시오.
a. 물리적 파티션의 연속 시리즈에 부트 논리적 볼륨이 할당되었는지 확인하려면 사본을 작성하십시오.
b. 나머지 논리적 볼륨의 사본을 작성한 다음 syncvg 명령을 사용하여 사본을 동기화하십시오.
c. shutdown 또는 reboot 명령을 사용하여 재부트하는 대신 LPAR을 종료한 후 활성화하여 디스크를 부트
할 수 있게 만드십시오. 즉시 종료할 필요는 없습니다. 하지만 시스템이 새 PV에서 부트할 수 있으려면 종
료해야 합니다.
그렇지 않으면 다음 명령으로 새 PV를 사용하여 볼륨 그룹에 새 논리적 볼륨의 사본을 작성하십시오.
참고: mirrorvg 명령은 디폴트로 쿼럼을 사용 불가능으로 설정합니다. rootvg의 경우 -m 옵션을 사용하면
작업 중인 디스크와 동일한 방식으로 새로운 논리적 볼륨 사본이 hdisk0에 맵핑되도록 할 수 있습니다.
mirrorvg yourvg hdisk0
10. 구성이 일부 논리적 볼륨의 사본을 보유하고 있는 경우 다음 명령을 사용하여 해당 사본을 다시 작성해야 할
수 있습니다.
mklvcopy -k
11. rootvg에서 PV 실패가 발생한 경우 다음 명령을 실행하여 부트 레코드를 초기화하십시오.

bosboot -a
12. rootvg에서 PV가 실패한 경우, 다음 명령을 실행하여 부트 리스트를 갱신하십시오.

참고: 구성에서 hdisk0 및 hdisk1 외의 부트 장치를 사용하는 경우, 해당 장치를 명령에 추가하십시오.
bootlist -om normal hdisk0 hdisk1
13. 프로시저가 성공적인지 확인하십시오.

• 모든 논리적 볼륨이 새로운 PV로 미러되었는지 확인하려면 다음 명령을 실행하십시오.
lslv lvname
실패한 PV의 영향을 받은 각 논리적 볼륨의 COPIES 속성을 확인하여 이제 필요한 만큼의 사본이 있는지
확인하십시오. 논리적 볼륨의 사본 개수가 원하는 개수 미만인 경우, mklvcopy 명령을 사용하여 추가 사
본을 작성하십시오.
• 모든 논리적 볼륨 파티션이 동기화되었는지 확인하려면 다음 명령을 실행하여 효력이 상실된 파티션이 없
는지 확인하십시오.
lspv hdisk0
대체된 PV의 STALE PARTITIONS 속성에서 개수가 0인지 확인하십시오. 효력이 상실된 파티션이 있으
면 syncvg 명령을 사용하여 파티션을 동기화하십시오.
rootvg에서 PV가 실패하면 다음 단계를 사용하여 이 프로시저의 다른 항목을 확인하십시오.
• 부트 리스트를 확인하려면 다음 명령을 실행하십시오.
bootlist -om normal
• 덤프 장치를 확인하려면 다음 명령을 실행하십시오.

sysdumpdev -l
• 부트 가능 PV 리스트를 확인하려면 다음 명령을 실행하십시오.

ipl_varyon -i
• /dev/ipl_device를 확인하려면 다음 명령을 실행하십시오.
ls -i /dev/rhdisk1 /dev/ipldevice
ls 명령의 출력이 두 항목에 대해 동일한 i-node 번호를 갖는지 확인하십시오.

이 단계는 프로시저를 완료합니다.
관련 정보
논리적 볼륨 관리자 파헤치기: 소개와 개념
물리적 볼륨이 누락되었을 때 시스템 관리자에게 통지

물리적 볼륨에 액세스할 수 없게 되면 AIX 에서 오류를 기록하지만 이러한 오류를 감지할 수 없는 경우도 있습니
다.
예를 들어, 물리적 볼륨이 미러된 볼륨 그룹의 일부일 경우 대부분의 데이터 사본에 액세스할 수 있으므로 사용자
가 문제를 발견하지 못합니다. 이런 경우, 사용자가 작업에 방해가 있음을 알아차리기 전에 자동 통지가 시스템
관리자에게 문제점을 경고할 수 있습니다.
다음 프로시저에서는 물리적 볼륨이 없는 것으로 선언될 경우 이를 자동으로 통지하는 자동 통지를 설정하는 방
법을 설명합니다. 다음 프로시저를 적절히 수정하여 다른 중요한 문제를 추적할 수도 있습니다.
1. 루트 권한을 사용하여 /etc/objrepos/errnotify ODM 파일의 백업 사본을 작성하십시오.
백업 사본에 원하는 아무 이름이나 지정할 수 있습니다. 다음 예제에서는 백업 사본에 현재 날짜와 함께
errnotify 파일 이름이 첨가됩니다.
cd /etc/objrepos
cp errnotify errnotifycurrent_date
2. 즐겨찾기 편집기를 사용하여 다음 스탠자를 포함하는 /tmp/pvmiss.add라는 이름의 파일을 작성하십시

오.
errnotify:
en_pid = 0
en_name = "LVM_SA_PVMISS"
en_persistenceflg = 1
en_label = "LVM_SA_PVMISS"
장치 관리 23
en_crcid = 0
en_type = "UNKN"
en_alertflg = ""
en_resource = "LVDD"
en_rtype = "NONE"
en_rclass = "NONE"
en_method = "/usr/lib/ras/pvmiss.notify $1 $2 $3 $4 $5 $6 $7 $8 $9"
이 주제의 모든 단계를 완료한 후에 오류 통지 디먼은 통지 메시지 내에서 오류 로그 항목의 자세한 정보와 함

께 이 스크립트에서 $1에서 $9까지 자동으로 확장합니다.
3. 즐겨찾기 편집기를 사용하여, 다음 컨텐츠가 있는 /usr/lib/ras/pvmiss.notify라는 파일을 작성하십
시오.
#!/bin/ksh
exec 3>/dev/console
print -u3 "?"
print -u3 - "----------------------------------------------"
print -u3 "ALERT! ALERT! ALERT! ALERT! ALERT! ALERT!"
print -u3 ""
print -u3 "Desc: PHYSICAL VOLUME IS MISSING. SEE ERRPT."
print -u3 ""
print -u3 "Error label: $9"
print -u3 "Sequence number: $1"
print -u3 "Error ID: $2"
print -u3 "Error class: $3"
print -u3 "Error type: $4"
print -u3 "Resource name: $6"
print -u3 "Resource type: $7"
print -u3 "Resource class: $8"
print -u3 - "----------------------------------------------"
print -u3 "?"
mail - "PHSYICAL VOLUME DECLARED MISSING" root <<-EOF
----------------------------------------------
ALERT! ALERT! ALERT! ALERT! ALERT! ALERT! Desc: PHYSICAL VOLUME IS MISSING. SEE ERRPT.
Error label: $9
Sequence number: $1
Error ID: $2
Error class: $3
Error type: $4
Resource name: $6
Resource type: $7
Resource class: $8
----------------------------------------------
EOF
4. 파일을 저장하고 편집기를 종료하십시오.

5. 작성한 파일에 적합한 권한을 설정하십시오.
예를 들어 다음과 같습니다.
chmod 755 /usr/lib/ras/pvmiss.notify
6. 다음 명령을 입력하여 2단계에서 작성한 LVM_SA_PVMISS 정의를 ODM에 추가하십시오.

odmadd /tmp/pvmiss.add
이제, 시스템은 LVM_SA_PVMISS 오류가 발생할 때마다 /usr/lib/ras/pvmiss.notify 스크립트를 실행

합니다. 이 스크립트는 콘솔에 메시지를 보내고 루트 사용자에게도 메일을 보냅니다.
관련 개념
논리적 볼륨 스토리지
논리적 볼륨은 물리적 볼륨에 있는 정보의 그룹입니다.
관련 정보
odmadd 명령
볼륨 그룹에서 미러링된 디스크 분할

스냅샷 지원은 잠재적인 디스크 장애로부터 미러링된 볼륨 그룹의 일관성을 보호하도록 도와줍니다.
스냅샷 기능을 사용하면 미러된 디스크를 분할하여 볼륨 그룹에 대한 신뢰할 수 있는(LVM 메타데이터의 관점에
서 신뢰할 수 있는) 특정 시점 백업으로 사용할 수 있고, 필요한 경우, 분할된 디스크를 볼륨 그룹으로 안전하게 다
시 통합할 수 있습니다. 다음 시나리오에서 먼저 볼륨 그룹으로부터 미러링된 디스크를 분할한 후, 분할된 디스크
를 원래의 볼륨 그룹으로 병합합니다. 스냅샷의 신뢰성을 높이려면, 파일 시스템을 마운트 해제해야 하고, 원시
논리적 볼륨을 사용하는 애플리케이션이 알려진 상태(백업을 사용해야 할 경우, 애플리케이션이 복구될 수 있는
상태)에 있어야 합니다.
다음 중 하나가 참이면 볼륨 그룹을 분할할 수 없습니다.
• 디스크가 이미 누락되었습니다.
• 효력이 상실되지 않은 마지막 파티션이 분할된 볼륨 그룹에 있습니다.
• splitvg 명령과 함께 강행 플래그(-f)를 사용하지 않는 한, 효력이 상실된 파티션이 볼륨 그룹에 존재합니다.
또한 향상된 동시 모드나 클래식 동시 모드에서는 스냅샷 기능(특히, splitvg 명령)을 사용할 수 없습니다. 분할
된 볼륨 그룹은 동시 또는 향상된 동시 모드가 될 수 없고 분할 볼륨 그룹과 원래의 볼륨 그룹 둘 다에 허용되는 변
경사항에 대한 제한이 있습니다. 자세한 사항은 chvg 명령 설명을 읽으십시오.
1. 볼륨 그룹이 충분히 미러링되었는지와 미러가 이 미러 세트만을 포함하는 디스크 또는 디스크 세트에 존재하
는지 확인하십시오.
2. 스냅샷 지원을 사용하려면 다음 명령을 사용하여 원래 볼륨 그룹(origVG)을 다른 디스크 또는 디스크 세트로
분할하십시오.
splitvg origVG
이때, 원래 볼륨 그룹에 대한 신뢰할 수 있는 특정 시점 백업이 만들어집니다. 그러나, 분할된 볼륨 그룹에서는

할당을 변경할 수 없음을 유의하십시오.
3. 분할된 디스크를 다시 활성화하고, 다음 명령을 사용하여 원래 볼륨 그룹에 병합하십시오.
joinvg origVG
이 시점에서 분할 볼륨 그룹이 원래 볼륨 그룹과 다시 통합됩니다.

관련 개념
관련 정보
chvg 명령
recreatevg 명령
splitvg 명령
LVM 문제점 해결
해결할 수 있는 LVM에 대한 몇 가지 일반 유형의 문제점이 있습니다.
디스크 드라이브 문제점 해결

이 정보는 디스크 드라이브 문제점을 진단 및 수정하는 방법을 알려줍니다.
디스크 드라이브에 기계적 장애가 있는 것으로 여겨지면 디스크에서 진단 프로그램을 실행하여 다음 절차를 사
용하십시오.
1. 루트 권한으로 명령행에 다음 SMIT 단축 경로를 입력하십시오.
smit diag
2. 현재 쉘 진단 프로그램을 선택하여 AIX 진단 프로그램 도구를 입력하십시오.

3. 진단 프로그램 작동 지시사항 화면을 읽은 후 Enter를 누르십시오.
4. 진단 프로그램 루틴을 선택하십시오.
5. 시스템 검증을 선택하십시오.
6. 리스트를 스크롤하여 테스트할 드라이브를 찾아서 선택하십시오.
장치 관리 25
7. 확정을 선택하십시오.
진단 프로그램 결과에 따라 디스크의 조건을 결정해야 합니다.
• 디스크 드라이브에 장애가 있는 것으로 여겨지면 해당 디스크에서 데이터를 복구하는 것이 가장 중요합니다.
Migration is the preferred way to recover data from a failing disk. 다음 절차는 이주를 완료할 수 없는 경우
논리적 볼륨에서 데이터를 복구 또는 복원하는 방법을 설명합니다.
• 드라이브에 장애가 있는 경우 다시 형식화하지 않고 드라이브를 복구할 수 있으면 데이터가 유실되지 않습니
다.
• 디스크 드라이브를 다시 형식화하거나 대체해야 될 경우 가능하면 백업하고 볼륨 그룹과 시스템 구성에서 디스
크 드라이브를 제거한 후 대체하십시오. 단일 사본 파일 시스템의 일부 데이터가 유실될 수 있습니다.
디스크 드라이브 공간
디스크 드라이브의 공간이 부족하면 몇 가지 방법으로 이 문제를 해결할 수 있습니다. 원치 않는 파일을 자동으로
추적하여 제거하거나, 특정 디렉토리에 대해서는 사용자 액세스를 제한하거나, 다른 디스크 드라이브에서 공간
을 마운트할 수 있습니다.
이러한 태스크를 수행하려면 루트 사용자, 시스템 그룹 또는 시스템 관리 그룹 권한을 가지고 있어야 합니다.
자동으로 파일 시스템을 정리하기 위한 명령

skulker 명령을 사용하면 원하지 않는 파일을 제거하여 파일 시스템을 정리할 수 있습니다.
명령행에서 다음을 입력하십시오.
skulker -p
skulker 명령은 더 이상 사용하지 않거나 불필요한 파일을 파일 시스템에서 주기적으로 제거하는 데 사용됩니
다. 이러한 파일에는 /tmp 디렉토리의 파일, 지정된 연한보다 오래된 파일, a.out 파일, 코어 파일 또는
ed.hup 파일이 있습니다. skulker 명령에 대한 자세한 정보는 skulker를 참조하십시오.
skulker 명령은 대개 시스템 사용량이 적은 시간대에 cron 명령에 의해 실행되는 사용통계 프로시저의 일부로
매일 실행됩니다.
특정 디렉토리에서 사용자 제한
디렉토리에 대한 액세스를 제한하고 디스크 사용량을 모니터링하여 디스크 공간을 비우고 사용 가능하게 할 수
있습니다.
1. 다음을 입력하여 특정 디렉토리에서 사용자를 제한하십시오.

chmod 755 DirName
이 명령은 소유자(루트)에 대한 읽기 및 쓰기 권한을 설정하고 그룹 등에 대한 읽기 전용 권한을 설정합니다.

DirName은 제한할 디렉토리의 전체 경로 이름입니다.
2. 다음 행을 /var/spool/cron/crontabs/adm 파일에 추가하여 개별 사용자의 디스크 사용량을 모니터링
하십시오.
0 2 * * 4 /usr/sbin/acct/dodisk
이 행은 dodisk 명령을 목요일(4)마다 오전 2시(0 2)에 실행합니다. dodisk 명령은 디스크 사용통계를 초
기화합니다. 이 명령은 일반적으로 오프피크 시간 동안에 cron 명령이 실행하는 사용통계 프로시저의 일부
로서 실행됩니다.
다른 디스크 드라이브에서 공간 마운팅

다른 드라이브에서 공간을 마운트하여 디스크 드라이브의 공간을 늘릴 수 있습니다.
다음과 같은 방법으로, 한 디스크 드라이브에서 다른 디스크 드라이브로 공간을 마운트할 수 있습니다.
• smit mountfs 단축 경로 사용
• mount 명령 사용 예를 들어 다음과 같습니다.
mount -n nodeA -vnfs /usr/spool /usr/myspool
mount 명령은 특정 위치에서 파일 시스템을 사용 가능하게 만듭니다.
다시 포맷하지 않고 디스크 드라이브 복구

고장난 디스크를 복구한 후 다시 포맷하지 않고 시스템에 놓으면, 시스템에서는 부트 시, 자동으로 드라이브의 효
력이 상실된 물리적 파티션을 활성화하고 다시 동기화합니다. 효력이 상실된 물리적 파티션에는 시스템에서 사
용할 수 없는 데이터가 포함됩니다.
물리적 파티션의 효력이 상실되었다고 의심될 경우 명령행에 다음을 입력하십시오.
lspv -M PhysVolName
여기서 PhysVolName은 물리적 볼륨의 이름입니다. lspv 명령 출력은 물리적 볼륨의 모든 파티션을 나열합니
다. 다음은 예제 출력에서 발췌한 것입니다.
hdisk16:112 lv01:4:2 stale
첫 번째 열에는 물리적 파티션이 표시되고, 두 번째 열에는 논리적 파티션이 표시됩니다. 효력이 상실된 물리적
파티션은 세 번째 열에 표시됩니다.
재형식화되거나 교체 디스크 드라이브를 사용하여 복구

실패한 디스크를 다시 포맷하거나 대체해야 하는 경우 실패한 디스크 드라이브에서 데이터를 복구할 수 있습니
다.
주의: 디스크 드라이브를 재형식화하거나 교체하기 전에 실패한 디스크에서 미러링되지 않은 파일 시스
템에 대한 모든 참조를 제거하고 디스크를 볼륨 그룹과 시스템 구성에서 제거하십시오. 이를 수행하지 않
으면 오브젝트 데이터 관리자(ODM) 및 시스템 구성 데이터베이스에 문제점이 발생합니다. 이러한 주요
단계에 대한 지시사항은 이미 실패했거나 실패하는 디스크를 대체 또는 다시 포맷하기 전에 아래의 다음
절차에 포함되어 있습니다.
다음 프로시저는 myvg라는 볼륨 그룹에 hdisk2, hdisk3 및 hdisk4라는 세 개의 디스크 드라이브가 포함되는 시
나리오를 사용합니다. 이 시나리오에서는 hdisk3이 잘못됩니다. 미러링되지 않은 논리적 볼륨 lv01과 mylv 논리
적 볼륨의 사본이 hdisk2에 포함됩니다. mylv 논리적 볼륨은 미러되며 세 개의 사본을 포함합니다. 각 사본은 해
당 디스크에서 두 개의 물리적 파티션을 차지합니다. 실패한 hdisk3에는 mylv의 또 다른 사본과 lv00이라는 미러
링되지 않은 논리적 볼륨이 포함됩니다. 마지막으로, hdisk4에는 mylv의 세 번째 사본뿐만 아니라 lv02라는 논리
적 볼륨이 포함됩니다. 다음 그림에는 이러한 시나리오가 나타나 있습니다.
이 프로시저는 다음과 같은 주요 세그먼트로 구분됩니다.

• 실패한 디스크를 대체하거나 재형식화하기 전에 데이터를 보호하기 위해 해야 할 일
• 디스크를 재형식화하거나 대체하기 위해 수행해야 할 프로시저
• 디스크가 재형식화되거나 대체된 후에 데이터를 복구하기 위해 해야 할 일
실패했거나 실패 중인 디스크를 대체하거나 재형식화하기 전에:
장치 관리 27
1. 루트 권한으로 로그인하십시오.
2. 실패 드라이브에 있는 논리적 볼륨에 익숙하지 않으면 작동 디스크를 사용하여 실패 디스크의 내용을 보십
시오.
예를 들어, hdisk4를 사용하여 hdisk3을 보려면 명령행에 다음을 입력하십시오.
lspv -M -n hdisk4 hdisk3
lspv 명령은 볼륨 그룹에 있는 물리적 볼륨에 대한 정보를 표시합니다. 다음과 유사한 출력이 표시됩니다.
hdisk3:1 mylv:1
hdisk3:2 mylv:2
hdisk3:3 lv00:1
hdisk3:4-50
첫 번째 열에는 물리적 파티션이 표시되고 두 번째 열에는 논리적 파티션이 표시됩니다. 파티션 4 - 50을 사
용할 수 있습니다.
3. 가능하면 실패 장치의 단일 사본 논리적 볼륨을 모두 백업하십시오. 지시사항은 사용자 파일 또는 파일 시스
템 백업을 참조하십시오.
4. 단일 사본 파일 시스템이 있는 경우 디스크에서 이를 마운트 해제하십시오.
(lspv 명령 출력에서 단일 사본 파일 시스템을 식별할 수 있습니다. 단일 사본 파일 시스템에는 출력의 물리
적 파티션과 동일한 수의 논리적 파티션이 있습니다.) 미러렁된 파일 시스템은 마운트 해재할 필요가 없습니
다.
시나리오에서 실패 디스크 hdisk3의 lv00은 단일 사본 파일 시스템입니다. 이 파일 시스템을 마운트 해제
하려면 다음을 입력하십시오.
unmount /dev/lv00
파일 시스템의 이름을 모르는 경우, /etc/filesystems 파일이 실패한 디스크에 단독으로 있지 않다고
가정하고, 명령행에 mount를 입력하여 마운트된 모든 파일 시스템을 나열하고 논리적 볼륨과 연관된 이름
을 찾으십시오. 또한 /etc/filesystems 파일에 대해 grep 명령을 사용하여 논리적 볼륨과 연관된 파일
시스템 이름(있는 경우)만 나열할 수도 있습니다. 예를 들어 다음과 같습니다.
grep lv00 /etc/filesystems
결과물은 다음 예와 비슷하게 표시됩니다.

dev = /dev/lv00
log = /dev/loglv00
참고:
a. 마운트 해제하려는 파일 시스템이 사용 중인 경우 unmount 명령은 실패합니다. unmount 명령은 파일
시스템이 열려 있지 않고 사용자의 현재 디렉토리가 해당 장치에 있지 않은 경우에만 실행됩니다.
5. rmfs 명령을 입력하여 모든 단일 사본 파일 시스템을 실패한 물리적 볼륨에서 제거하십시오.
rmfs /FSname
6. 실패한 디스크에서 모든 미러링된 논리적 볼륨을 제거하십시오.

참고: rootvg 볼륨 그룹에서 물리적 볼륨의 hd5 및 hd7 논리적 볼륨에 대해 rmlvcopy를 사용할 수 없습니
다. 이러한 논리적 볼륨은 사본이 하나만 있으므로 제거할 수 없습니다.
rmlvcopy 명령은 각 논리적 파티션에서 사본을 제거합니다. 예를 들어, 다음을 입력하십시오.
rmlvcopy mylv 2 hdisk3
hdisk3에서 사본을 제거하여, mylv 논리적 볼륨에 속하는 각 논리적 파티션의 사본의 수를 세 개에서 두 개
로(hdisk4에 하나와 hdisk2에 하나) 줄일 수 있습니다.
7. 실패한 디스크가 루트 볼륨 그룹과 포함된 논리적 볼륨 hd7의 일부인 경우, 명령행에 다음을 입력하여 1차
덤프 장치(hd7)를 제거하십시오.
sysdumpdev -P -p /dev/sysdumpnull
sysdumpdev 명령은 실행 중인 시스템에 대한 1차 또는 2차 덤프 장치 위치를 변경합니다. 재부트하는 경

우 덤프 장치는 원래 위치로 돌아갑니다.
참고: DVD 장치에 덤프하기로 선택할 수 있습니다. 덤프 장치가 되도록 DVD를 구성하는 방법에 대한 자세
한 정보는 sysdumpdev의 내용을 참조하십시오.
8. 다음 명령을 사용하여 디스크에서 페이징 공간을 제거하십시오.
rmps PSname
여기서 PSname은 제거할 페이징 공간의 이름인데, 이는 실제로 페이징 공간이 상주하는 논리적 볼륨의 이
름입니다.
rmps 명령이 성공하지 못한 경우, smit chps 단축 경로를 사용하여 1차 페이징 공간을 비활성화하고 이
프로시저를 계속하기 전에 재부트하십시오. 활성 페이징 공간이 있는 경우 10단계의 reducevg 명령은 실
패할 수 있습니다.
9. rmlv 명령을 사용하여 볼륨 그룹에서 파일 시스템을 포함하지 않는 논리적 볼륨 등과 같은 다른 논리적 볼
륨을 제거합니다.
예를 들어, 다음을 입력하십시오.
rmlv -f lv00
10. reducevg 명령을 사용하여 볼륨 그룹에서 실패한 디스크를 제거하십시오.

reducevg -df myvg hdisk3
reducevg 명령을 실행할 수 없거나 명령이 실패한 경우, 13 단계의 프로시저는 사용자가 드라이브를 재형
식화하거나 대체한 후에 VGDA/ODM 정보를 정리하는 데 도움을 줄 수 있습니다.
이미 실패했거나 실패하는 디스크 대체 또는 재형식화:
11. 다음 단계는 디스크를 재형식화할지 아니면 대체할지 여부 및 사용 중인 하드웨어 유형에 따라 달라집니다.
• 디스크 드라이브를 재형식화하려는 경우 다음 프로시저를 수행하십시오.
a. 루트 권한으로 명령행에 다음 SMIT 단축 경로를 입력하십시오.
smit diag
b. 현재 쉘 진단 프로그램을 선택하여 AIX 진단 프로그램 도구로 들어가십시오.

c. 진단 프로그램 조작 지시사항 화면을 읽은 다음에 Enter를 누르십시오.
d. 태스크 선택을 선택하십시오.
e. 태스크 리스트를 아래로 스크롤하여 미디어 형식화를 찾아서 선택하십시오.
f. 재형식화할 디스크를 선택하십시오. 디스크를 재형식화하려고 함을 확인한 후에는 디스크의 모든 내
용은 지워집니다.
디스크가 재형식화되면 12단계를 계속 진행하십시오.
• 시스템에서 핫스왑 디스크를 지원하는 경우 32 페이지의 『시스템 가동 중 디스크 장애에서 복구』의 프
로시저에 따라 13단계를 계속 진행하십시오.
• 시스템이 핫스왑 디스크를 지원하지 않는 경우에는 다음 단계를 수행하십시오.
– SMIT 단축 경로 smit rmvdsk를 사용하여 이전 드라이브의 전원을 끄십시오. 데이터베이스 필드의
KEEP 정의를 No로 변경하십시오.
– 다음 레벨의 시스템 지원에 문의하여 디스크 드라이브를 대체하십시오.
실패했거나 실패 중인 디스크를 대체하거나 재형식화한 후에:
장치 관리 29
12. 17 페이지의 『디스크 구성』 및 19 페이지의 『사용 가능한 디스크를 물리적 볼륨으로 설정』의 지시사항
을 따르십시오.
13. 디스크가 형식화되기 전에(10 단계) 이전 볼륨 그룹에서 디스크에서 reducevg 명령을 사용할 수 없는 경
우 다음 프로시저는 VGDA/ODM 정보를 정리하는데 도움을 줄 수 있습니다.
a. 볼륨 그룹이 재형식화된 하나의 디스크로만 구성된 경우 다음을 입력하십시오.
exportvg VGName
여기서 VGName은 사용자의 볼륨 그룹 이름입니다.

b. 볼륨 그룹이 둘 이상의 디스크로 구성된 경우 명령행에 다음을 입력하십시오.
varyonvg VGName
시스템에 디스크가 누락되었거나 사용 불가능하다는 메시지가 표시되고 새 디스크(또는 재형식화된 디

스크)가 나열됩니다. varyonvg 메시지에 나열된 새 디스크의 물리적 볼륨 ID(PVID)를 기록해 놓으십시
오. 이름은 누락된 디스크 이름과 레이블 PVNOTFND 사이의 16자 문자열입니다. 예를 들어 다음과 같습
니다.
hdisk3 00083772caa7896e PVNOTFND
다음을 입력하십시오.
varyonvg -f VGName
이제 누락된 디스크가 PVREMOVED 레이블과 함께 표시됩니다. 예를 들어 다음과 같습니다.

hdisk3 00083772caa7896e PVREMOVED
그 다음 다음 명령을 입력하십시오.
reducevg -df VGName PVID
여기서 PVID는 물리적 볼륨 ID입니다(이 시나리오에서는 00083772caa7896e).

14. 새 디스크 드라이브를 볼륨 그룹에 추가하려면 extendvg 명령을 사용하십시오.
extendvg myvg hdisk3
15. 새 디스크 드라이브(또는 재형식화된 디스크 드라이브)에 단일 사본 논리적 볼륨을 다시 작성하려면 mklv
명령을 사용하십시오.
mklv -y lv00 myvg 1 hdisk3
이 예는 hdisk3 드라이브에서 lv00 논리적 볼륨을 다시 작성합니다. 1은 이 논리적 볼륨이 미러되지 않음을
의미합니다.
16. 논리적 볼륨에 파일 시스템을 다시 작성하려면 crfs 명령을 사용하십시오.
crfs -v jfs -d lv00 -m /dev/lv00
17. 백업 미디어에서 단일 사본 파일 시스템 데이터를 복원하려면 사용자 파일 또는 파일 시스템 백업을 참조하

십시오.
18. 논리적 볼륨의 미러된 사본을 다시 작성하려면 mklvcopy 명령을 사용하십시오.
mklvcopy mylv 3 hdisk3
이 예는 hdisk3에서 mylv 논리적 볼륨의 미러링된 세 번째 파티션을 작성합니다.
19. 새 미러를 다른 미러의 데이터와 동기화하려면(이 예에서는 hdisk2 및 hdisk4), syncvg 명령을 사용하십시
오.
syncvg -p hdisk3
결과적으로 미러링된 모든 파일 시스템이 복원되고 최신 상태여야 합니다. 단일 사본 파일 시스템을 백업할 수 있

었으면 사용할 준비가 된 것입니다. 시스템을 정상적으로 계속 사용할 수 있어야 합니다.
실패한 디스크 드라이브에서의 복구 예제

실패한 디스크 드라이브에서 복구하려면 단계를 거꾸로 수행하십시오. 즉, 볼륨 그룹을 작성하기 위해 수행한 단
계를 나열한 다음 역방향으로 수행하십시오.
다음 예제는 이러한 방법에 대한 설명입니다. 미러된 논리적 볼륨을 작성하는 방법 및 디스크 실패 시 한 번에 한
단계씩 취소하여 해당 볼륨을 변경하는 방법을 보여 줍니다.
참고: 다음 예제에서는 특정 인스턴스를 설명합니다. 그러나 이는 일반 복구 프로시저의 기초가 되는 일반 원형은
아닙니다.
1. 시스템 관리자인 Jane은 다음을 입력하여 hdisk1에 workvg라는 볼륨 그룹을 작성했습니다.
mkvg -y workvg hdisk1
2. 그리고 다음을 입력하여 이 볼륨 그룹에 대해 둘 이상의 디스크를 작성했습니다.

extendvg workvg hdisk2
3. Jane은 세 개의 사본을 가진 40MB의 논리적 볼륨을 작성했습니다.

각 사본은 workvg 볼륨 그룹을 구성하는 세 개의 각 디스크에 있습니다. 다음과 같은 명령이 사용되었습니다.
mklv -y testlv workvg 10
mklvcopy testlv 3
미러된 workvg 볼륨 그룹을 작성한 후 hdisk2가 실패했습니다. 그러므로 복구를 위해 다음과 같은 단계를 수행
했습니다.
1. 다음을 입력하여 hdisk2에서 논리적 볼륨 사본을 제거했습니다.
rmlvcopy testlv 2 hdisk2
2. 다음을 입력하여 ODM 및 VGDA가 갱신되도록 시스템에서 hdisk2를 접속 해제했습니다.

reducevg workvg hdisk2
3. 다음을 입력하여 대체 준비를 위해 hdisk2를 시스템 구성에서 제거했습니다.

rmdev -l hdisk2 -d
4. 다음을 입력하여 시스템을 종료하도록 선택했습니다.

shutdown -F
5. 디스크를 대체했습니다. 새 디스크는 이전 hdisk2와 같은 SCSI ID를 갖지 않습니다.

6. 시스템을 재부트했습니다.
디스크를 새로 만들었으므로(시스템에서 이 디스크에 새 PVID가 있음을 인식함) 시스템에서는 첫 번째 열린
hdisk 이름을 선택합니다. 3단계에서 -d 플래그가 사용되었으므로 hdisk2 이름이 해제되어 새 디스크의 이름
으로 hdisk2를 선택할 수 있습니다. -d 플래그를 사용하지 않은 경우에는 새 이름으로 hdisk4가 선택됩니다.
7. Jane은 다음을 입력하여 이 디스크를 workvg 볼륨 그룹에 추가했습니다.
장치 관리 31
8. 그리고 다음을 입력하여 논리적 볼륨의 미러된 두 사본을 작성했습니다.
mklvcopy testlv 3
논리적 볼륨 관리자는 새 hdisk2에서 세 번째 논리적 볼륨 사본을 자동으로 찾습니다.
시스템 가동 중 디스크 장애에서 복구

핫 제거 기능을 사용하면 디스크 장애에서 복구할 수 있습니다.
핫 제거 기능을 사용하여 디스크 장애에서 복구하는 절차는 대부분의 경우 다음을 제외하고 27 페이지의 『다시
포맷하지 않고 디스크 드라이브 복구』에 설명된 절차와 동일합니다.
1. 디스크에서 파일 시스템을 마운트 해제하려면 JFS 또는 JFS2 마운트 절차를 수행하십시오.
2. 볼륨 그룹 및 운영 체제에서 디스크를 제거하려면 47 페이지의 『데이터가 포함되지 않은 디스크 제거』 절
차를 수행하십시오.
3. 실패한 디스크를 새 디스크로 대체하는 경우 시스템을 종료하지 않아도 됩니다. 다음 절차 순서를 사용하십시
오.
a) 35 페이지의 『논리적 볼륨 스토리지』
b) 17 페이지의 『디스크 구성』
c) 27 페이지의 『재형식화되거나 교체 디스크 드라이브를 사용하여 복구』의 13단계로 계속 진행하십시
오.
볼륨 그룹이 하나의 디스크로 구성된 경우 디스크 대체

볼륨 그룹의 일부로서 잘못된 디스크에 액세스할 수 있는 경우 다음 프로시저 중 하나를 사용하십시오.
• 16 페이지의 『물리적 볼륨의 컨텐츠 마이그레이션』
디스크가 잘못되어서 액세스할 수 없으면 다음 단계를 수행하십시오.
1. 볼륨 그룹을 반출하십시오.
2. 드라이브를 교체하십시오.
3. 존재하는 백업 미디어에서 데이터를 다시 작성하십시오.
물리적 및 논리적 볼륨 오류
해결할 수 있는 물리적 볼륨 및 논리적 볼륨에 대한 몇 가지 일반 오류가 있습니다.
핫 스팟 문제점
논리적 볼륨에 액세스할 때 성능이 저하되면 논리적 볼륨에 디스크 입출력이 너무 많이 이루어지는 핫 스팟이 있
추가 정보는 60 페이지의 『논리적 볼륨의 핫 스팟 관리』의 내용을 참조하십시오.
LVCB 경고
LVCB에 유효하지 않은 정보가 포함되면 경고가 발생합니다.
논리적 볼륨 제어 블록(LVCB)은 논리적 볼륨의 첫 번째 블록입니다. LVCB의 크기는 볼륨 그룹 내에서 물리적 볼
륨의 블록 크기입니다. 이 영역에는 논리적 볼륨의 작성 날짜, 미러 사본에 대한 정보, JFS의 가능한 마운트 위치
와 같은 중요한 정보가 보관됩니다. LVM 알고리즘의 일부로 LVCB를 갱신하려면 특정 LVM 명령을 실행해야 합
니다. 유효성 여부를 검토하기 위해 이전의 LVCB가 읽히고 분석됩니다. LVCB 정보가 유효하면 LVCB가 갱신됩
니다. 정보가 유효하지 않으면 LVCB가 갱신되지 않습니다. 다음 메시지를 수신할 수도 있습니다.
Warning, cannot write lv control block data.
대부분의 경우, 데이터베이스 프로그램이 JFS를 생략하고 스토리지 미디어로 원시 논리적 볼륨에 액세스할 때
이 메시지가 표시됩니다. 이와 같은 경우 데이터베이스 정보가 그대로 LVCB 위에 기록됩니다. 원시 논리적 볼륨
의 경우에는 이러한 상황이 치명적인 결과를 야기하지 않습니다. LVCB가 겹쳐쓰인 후에도 사용자는 다음 작업을
수행할 수 있습니다.
• 논리적 볼륨 확장
• 논리적 볼륨의 미러 사본 작성
• 논리적 볼륨 제거
• 저널 파일 시스템을 작성하여 논리적 볼륨 마운트
LVCB를 삭제하는 데는 한계가 있습니다. 삭제된 LVCB가 있는 논리적 볼륨은 다른 시스템에 성공적으로 반입되
지 않을 수도 있습니다. 반입 중, LVM importvg 명령이 볼륨 그룹에 정의된 모든 논리적 볼륨의 LVCB에서 논리
적 볼륨과 관련된 정보를 스캔합니다. LVCB가 없을 경우, 반입된 볼륨 그룹이 이 볼륨 그룹에 액세스하는 새 시스
템에 논리적 볼륨을 정의하며, 사용자는 계속해서 원시 논리적 볼륨에 액세스할 수 있습니다. 하지만 대개는 다음
과 같은 상황이 발생합니다.
• JFS 정보가 유실되고 연관된 마운트 위치가 새 시스템으로 반입되지 않습니다. 이 경우, 새 마운트 위치를 작성
해야 합니다. 파일 시스템에 저장되어 있던 이전 데이터의 가용성은 보장되지 않습니다.
• 논리적 볼륨과 관련된 일부 비 JFS 정보를 찾을 수 없습니다. 이러한 경우, 시스템에서는 디폴트 논리적 볼륨 정
보를 사용하여 ODM 정보를 채웁니다. 따라서 lslv 명령의 출력 중 일부가 실제 논리적 볼륨과 일치하지 않을
수도 있습니다. 논리적 볼륨 사본이 여전히 원래 디스크에 존재하면 정보는 ODM 데이터베이스에 정확하게 반
영되지 않습니다. rmlvcopy와 mklvcopy 명령을 사용하여 논리적 볼륨 사본을 재빌드한 후 ODM과 동기화
하십시오.
물리적 파티션 한계
논리적 볼륨 관리자(LVM) 설계에서 각 논리적 파티션은 하나의 물리적 파티션(PP)에 맵핑됩니다. 그리고 각 물
리적 파티션은 여러 디스크 섹터에 맵핑됩니다. LVM 설계에서는 LVM에서 디스크당 추적할 수 있는 물리적 파티
션 수를 1016으로 제한합니다. 대부분의 경우 1016개의 트랙 파티션을 모두 디스크에서 사용하지는 않습니다.
이 한계를 초과하면 다음과 같은 메시지가 표시될 수 있습니다.
0516-1162 extendvg: Warning, The Physical Partition Size of PPsize requires the
creation of TotalPPs partitions for PVname. The limitation for volume group
VGname is LIMIT physical partitions per physical volume. Use chvg command
with -t option to attempt to change the maximum Physical Partitions per
Physical volume for this volume group.
여기서,
PPsize
1MB ~ 1GB의 2 거듭제곱
Total PPs
PPsize가 제공된 경우 이 디스크에 있는 총 물리적 파티션 수
PVname
물리적 볼륨의 이름(예: hdisk3)
VGname
볼륨 그룹의 이름입니다.
LIMIT
1016 또는 1016의 배수입니다.
다음과 같은 경우에 이러한 제한사항이 적용됩니다.
1. mkvg 명령을 사용하여 볼륨 그룹을 작성하는 경우 볼륨 그룹의 디스크에 있는 물리적 파티션의 지정된 수가
1016을 초과했습니다. 이러한 제한사항을 없애려면 1, 2, 4(디폴트), 8, 16, 32, 64, 128, 256, 512 또는
1024MB의 물리적 파티션 크기 범위에서 선택하고 mkvg -s 명령을 사용하여 볼륨 그룹을 작성할 수 있습니
다. 또는 디스크당 1016개 파티션의 배수를 허용하는 적절한 요소를 사용하고 mkvg -t 명령을 사용하여 볼륨
그룹을 작성할 수 있습니다.
2. extendvg 명령을 사용하여 기존 볼륨 그룹에 디스크를 추가하는 경우 새 디스크로 인해 1016 제한 위반이
발생했습니다. 이러한 상황을 해결하려면 chvg -t 명령을 사용하여 디스크당 1016개 파티션의 배수를 보유
하도록 기존 볼륨 그룹을 변환하십시오. 또는 새 디스크를 허용하는 더 큰 파티션 크기를 가진 볼륨 그룹을 다
시 작성하거나, 새 디스크에 대해 더 큰 물리적 크기로 구성된 독립형 볼륨 그룹을 작성할 수 있습니다.
파티션 제한사항 및 rootvg

설치 코드에서 rootvg 드라이브가 4GB를 초과하는 것을 발견하면 전체 디스크 용량을 사용 가능한 1016개의 트
랙으로 맵핑할 수 있을 때까지 mkvg-s 값을 변경합니다. 이러한 설치 변경은 또한 크기에 상관없이 rootvg에 추
가된 다른 모든 디스크는 해당 물리적 파티션 크기에도 정의되었음을 의미합니다.
장치 관리 33
파티션 제한사항 및 RAID 시스템
RAID(Redundant Array of Identical Disk)를 사용하는 시스템의 경우 LVM에 사용되는 /dev/hdiskX 이름은
다수의 비4GB 디스크로 구성될 수 있습니다. 이런 경우에도 1016 요구사항은 계속 존재합니다. LVM에서는 실
제로 /dev/hdiskX를 구성하는 개별 디스크의 크기를 인식할 수 없습니다. LVM에서는 /dev/hdiskX를 구성
하는 실제 물리적 디스크가 아닌 인식된 /dev/hdiskX 크기에 1016 제한사항의 기초를 둡니다.
장치 구성 데이터베이스 동기화
시스템 고장이 발생하면 장치 구성 데이터베이스와 LVM이 일치하지 않게 될 수 있습니다. 장치 구성 데이터베이
스와 LVM 정보를 동기화할 수 있습니다.
장치 구성 데이터베이스가 LVM과 일치하지 않게 되면 논리적 볼륨 명령이 다음과 같은 오류 메시지를 생성합니
다.
0516-322 The Device Configuration Database is inconsistent ...
OR
0516-306 Unable to find logical volume LVname in the Device

Configuration Database.
여기서 정상적인 경우에는 LVname이라는 논리적 볼륨이 사용 가능합니다.

주의: 볼륨 그룹이나 논리적 볼륨에 대한 /dev 항목을 제거하지 마십시오. 오브젝트 데이터 관리자
(ODM)를 사용하여 볼륨 그룹이나 논리적 볼륨에 대한 데이터베이스 항목을 변경하지 마십시오.
장치 구성 데이터베이스와 LVM 정보를 동기화하려면 루트 권한으로 명령행에 다음을 입력하십시오.
synclvodm -v VGName
여기서 VGName은 동기화할 볼륨 그룹의 이름입니다.
볼륨 그룹 오류 수정
볼륨 그룹 오류를 수정하려면 다음 방법을 사용하십시오.
importvg 명령이 제대로 작동하지 않으면 장치 구성 데이터베이스를 갱신하십시오.
연결 변환 실패 재정의
주의: 연결 변환 실패를 재정의하는 것은 특별한 조작입니다. 진행하기 전에 하드웨어, 케이블, 어댑터 및
전원 공급 장치와 같이 문제가 발생할 소지가 있는 원인을 확인하십시오. 연결 변환 프로세스 중의 쿼럼
실패 재정의는 응급 시와 최후의 수단(예: 장애가 있는 디스크에서 데이터 복구)으로만 사용됩니다. 쿼럼
실패가 재정의되면 VGDA와 VGSA의 선택된 사본에 들어 있는 관리 데이터의 데이터 무결성을 보증할 수
없습니다.
존재하지 않는 쿼럼을 재정의하여 볼륨 그룹을 강제로 연결 변환할 경우 이 연결 변환 프로세스 중에 누락된 모든
물리적 볼륨의 PV STATE는 제거됨 상태로 변경됩니다. 그러므로 이러한 물리적 볼륨에서 모든 VGDA와 VGSA
사본이 제거됩니다. 이러한 사본이 제거되면 물리적 볼륨은 더 이상 쿼럼 확인에 관여하지 않으며 사용자가 볼륨
그룹으로 돌아올 때까지 볼륨 그룹 내에서 활성화될 수 없습니다. 볼륨 그룹이 쿼럼을 잃지 않은 경우 varyonvg -
f 플래그(쿼럼 유실을 재정의하는 데 사용됨)는 무시됩니다.
다음 조건에 한 개 이상 해당할 경우 볼륨 그룹에 있는 사용 가능한 디스크의 데이터에 액세스할 수 있도록 연결
변환 실패를 재정의할 수 있습니다.
• 사용 불가능한 물리적 볼륨이 영구 손상된 것으로 표시됩니다.
• 볼륨 그룹이 마지막으로 연결 변환될 때 현재 액세스 가능한 물리적 볼륨(적절한 VGDA 및 VGSA 사본도 포함
되어야 함) 중 최소한 하나가 온라인인지 확인할 수 있습니다. 누락된 물리적 볼륨을 진단하고 복구할 때까지
구성을 해제하고 전원을 차단하십시오.
하나의 디스크가 누락된 경우 다음 절차를 사용하여 쿼럼 유실을 방지하십시오. 그렇지 않으면 실패하여 복구가
필요할 수 있습니다.
1. 볼륨 그룹에서 볼륨을 임시로 제거하려면 다음을 입력하십시오.
chpv -vr PVname
이 명령이 완료되면 물리적 볼륨 PVname은 더 이상 쿼럼 확인에 관여하지 않습니다. 그러나 두 VGDA/VGSA

가 포함된 디스크에서 chpv 명령을 시도하는 경우 이 명령은 두 디스크 볼륨 그룹에서 실패합니다. 이 명령을
사용하면 쿼럼이 유실되지 않습니다.
2. 복구를 위해 디스크를 제거할 경우 시스템 전원을 차단하고 디스크를 제거하십시오. 지시사항은 25 페이지의
『디스크 드라이브 문제점 해결 』의 내용을 참조하십시오. 디스크를 수정하고 시스템으로 리턴했으면 다음
단계를 계속 진행하십시오.
3. 쿼럼 확인을 위해 디스크를 다시 볼륨 그룹에서 다시 사용할 수 있게 하려면 다음을 입력하십시오.
chpv -v a PVname
참고: chpv 명령은 쿼럼 확인 변경에만 사용됩니다. 디스크가 시스템으로 리턴하지 않으면 디스크에 상주하
는 데이터가 계속 있는 것이므로 다른 디스크로 이동하거나 복사해야 합니다.
VGDA 경고
경우에 따라 새 디스크를 기존 볼륨 그룹에 추가하거나 새 볼륨 그룹을 작성하는 데 문제가 발생할 수 있습니다.
LVM이 제공하는 메시지는 다음과 같습니다.
0516-1163 extendvg: VGname already has maximum physical volumes. With the maximum
number of physical partitions per physical volume being LIMIT, the maximum
number of physical volumes for volume group VGname is MaxDisks.
여기서,
VGname
볼륨 그룹의 이름입니다.
LIMIT
1016 또는 1016의 배수입니다.
MaxDisks
볼륨 그룹의 최대 디스크 수입니다. 예를 들어, 각 디스크에 1016개의 물리적 파티션(PP)이 있으면 MaxDisk
는 32입니다. 2032개 있으면 MaxDisk는 16입니다.
image.data 파일을 수정한 후 대체 디스크 설치를 사용하거나 mksysb 명령으로 시스템을 복원하여 볼륨 그
룹을 큰 볼륨 그룹으로 다시 작성하십시오. 자세한 정보는 설치 및 마이그레이션을 참조하십시오.
이전 AIX 버전에서 제한이 32개 디스크 미만이면 rootvg는 최대 VGDA의 설명에서 제외됩니다. 사용자에게 추
가 디스크 여유 공간을 제공하기 위해 mkvg -d 명령은 rootvg가 작성될 때 설치 메뉴에서 선택된 디스크 수를 참
조 번호로 사용합니다. 이 -d 숫자는 디스크가 1개일 경우 7이고 추가로 디스크를 선택할 때마다 하나씩 더 추가
됩니다. 예를 들어, 두 개의 디스크가 선택되면 숫자는 8이고 세 개의 디스크가 선택되면 숫자는 9입니다.
구조의 계층은 디스크 스토리지를 관리하는 데 사용됩니다. 물리적 볼륨(PV)이라고 하는 각각의 개별 디스크 드
라이브에는 /dev/hdisk0과 같은 이름이 있습니다. 사용 중인 모든 물리적 볼륨은 볼륨 그룹(VG)에 속합니다.
볼륨 그룹에 있는 모든 물리적 볼륨은 동일한 크기의 물리적 파티션(PP)들로 나뉩니다. 공간 할당을 위해 각 물리
적 볼륨은 다섯 개의 영역(outer_edge, inner_edge, outer_middle, inner_middle 및 center)으로 나뉩니다.
각 영역에 배치되는 물리적 파티션의 수는 디스크 드라이브의 총 용량에 따라 다릅니다.
각 볼륨 그룹 내에는 하나 이상의 논리적 볼륨(LV)이 정의됩니다. 논리적 볼륨의 데이터는 사용자에게 인접하게
나타나지만 실제 볼륨에서는 인접하지 않을 수 있습니다. 그러면 파일 시스템, 페이징 공간 및 다른 논리적 볼륨
이 크기가 조정되거나 재배치되어 여러 물리적 볼륨에 걸쳐지게 하고, 데이터 스토리지에서 더 많은 유연성과 가
용성을 위해 복제할 수 있습니다.
각 논리적 볼륨은 하나 이상의 논리적 파티션(LP)으로 구성됩니다. 각 논리적 파티션은 적어도 하나의 물리적 파
티션에 대응됩니다. 논리적 볼륨에 미러링이 지정된 경우, 각 논리적 파티션의 추가 사본을 저장하기 위해 물리적
파티션이 추가로 할당됩니다. 논리적 파티션에는 연속해서 번호가 매겨지지만 기본 물리적 파티션의 경우에는
반드시 연속할 필요는 없습니다.
장치 관리 35
논리적 볼륨은 페이징과 같은 시스템 작업에 사용될 수 있습니다. 하지만 각 논리적 볼륨은 각각 하나의 시스템
작업에만 사용됩니다. 대부분의 논리적 볼륨에는 저널 파일 시스템(JFS 또는 JFS2)이 포함됩니다. 각 JFS는 페
이지 크기(4KB) 블록의 풀로 구성됩니다. 데이터를 파일에 써야 할 경우, 하나 이상의 추가 블록이 그 파일에 할
당됩니다. 이러한 블록은 서로 인접하지 않거나 이전에 이 파일에 할당된 다른 블록과 인접하지 않을 수도 있습니
다. 지정한 파일 시스템의 프래그먼트 크기가 4KB 미만(512바이트, 1KB, 2KB)인 것으로 정의할 수 있습니다.
설치 후, 시스템에는 시스템을 시작하는 데 필요한 기본 논리적 볼륨 세트로 구성된 하나의 볼륨 그룹(rootvg 볼
륨 그룹)과 사용자가 설치 스크립트에 지정한 기타 논리적 볼륨이 포함됩니다. 사용자가 시스템에 연결한 이외 다
른 물리적 볼륨도 볼륨 그룹에 추가할 수 있습니다(extendvg 명령 사용). rootvg 볼륨 그룹 또는 mkvg 명령으로
정의한 다른 볼륨 그룹에 물리적 볼륨을 추가할 수 있습니다. 논리적 볼륨은 명령, 메뉴 구동 SMIT(System
Management Interface Tool) 인터페이스를 사용하여 조정할 수 있습니다.
관련 태스크
물리적 볼륨이 누락되었을 때 시스템 관리자에게 통지
물리적 볼륨에 액세스할 수 없게 되면 AIX 에서 오류를 기록하지만 이러한 오류를 감지할 수 없는 경우도 있습니
다.
볼륨 그룹에서 미러링된 디스크 분할
스냅샷 지원은 잠재적인 디스크 장애로부터 미러링된 볼륨 그룹의 일관성을 보호하도록 도와줍니다.
루트 볼륨 그룹에서 파일 시스템의 크기 줄이기
모든 파일 시스템을 최소 크기로 줄이는 가장 쉬운 방법은 백업에서 기본 운영 체제(BOS)를 복원할 때 SHRINK
옵션을 예로 설정하는 것입니다.
장치 설치 준비
시스템에 장치를 설치하는 작업은 장치를 연결할 위치 식별하고, 장치를 물리적으로 연결하고, 구성 관리자 또는
SMIT를 사용하여 장치를 구성하는 작업으로 구성됩니다.
참고: 장치를 설치하기 위해 다음 프로시저를 수행하려면 시스템을 종료해야 합니다. 모든 장치를 설치할 때 시스
템을 종료해야 하는 것은 아닙니다. 장치와 함께 제공되는 문서를 참조하십시오.
이 항목에서는 모든 장치에 공통된 설치 태스크에 대해 설명합니다. 시스템에 설치할 수 있는 장치는 매우 광범위
하므로 여기서는 일반적인 절차만 제공합니다. 장치별 자세한 정보는 장치와 함께 제공되는 설치 지시사항을 참
조하십시오.
1. 시스템에서 실행 중인 모든 애플리케이션을 정지하고 shutdown 명령을 사용하여 시스템을 종료하십시오.
2. 시스템 및 시스템에 연결된 모든 장치의 전원을 끄십시오.
3. 시스템 및 시스템에 연결된 모든 장치의 플러그를 빼십시오.
4. 해당 장치의 설치 및 운영자 안내서에 설명된 절차에 따라 시스템에 새 장치를 연결하십시오.
5. 시스템 및 시스템에 연결된 모든 장치의 플러그를 꽂으십시오.
6. 시스템 전원은 끈 상태로 연결된 모든 장치의 전원을 켜십시오.
7. 모든 장치의 시스템 시동 시 자체 테스트(POST)가 완료되면 시스템 전원을 켜십시오.
구성 관리자는 연결된 장치를 자동으로 스캔하고 새 장치를 발견하면 구성합니다. 새로운 장치는 디폴트 속성으
로 구성되고 사용 가능 상태로 사용자 조정 구성 데이터베이스에 기록됩니다.
SMIT 단축 경로, smit dev를 사용하여 장치를 수동으로 구성할 수 있습니다. 장치 속성을 조정해야 하거나 장
치를 자동으로 구성할 수 없을 경우, 장치와 함께 제공되는 장치 문서에서 장치 고유의 구성 요구사항을 확인하십
시오.
읽기/쓰기 광 드라이브 구성
두 가지 방법으로 읽기/쓰기 광 드라이브를 구성할 수 있습니다.
읽기/쓰기 광 드라이브가 시스템에 연결되어 있어야 하고 전원이 켜져 있어야 합니다.
방법 1
이 방법은 다른 방법보다 빠릅니다. 이 방법은 지정된 읽기/쓰기 광 드라이브만 구성합니다. 이 방법을 사용하려
면 다음 정보를 제공해야 합니다.
항목 설명
서브클래스 드라이브가 연결된 방식을 정의합니다.
유형 읽기/쓰기 광 드라이브의 유형을 지정합니다.
상위 이름 드라이브가 연결된 시스템 접속장치를 지정합니다.
연결된 위치 드라이브의 논리적 주소를 지정합니다.
다음 명령을 입력하여 읽기/쓰기 광 드라이브를 구성하십시오.

mkdev -c rwoptical -s Subclass -t Type -p ParentName -w WhereConnected
다음은 SCSI ID가 6이고 논리적 장치 번호는 0이며 세 번째(scsi3) SCSI 버스에 연결된 읽기/쓰기 광 드라이브의
예입니다.
mkdev -c rwoptical -s scsi -t osomd -p scsi3 -w 6,0 -a pv=yes
방법 2
이 방법은 현재 구성을 검색하고 새로운 장치를 검색하여 장치를 자동으로 구성하는 구성 관리자를 사용합니다.
이 방법은 읽기/쓰기 광 드라이브에 대해 아는 것이 거의 없을 때 사용합니다.
1. 구성 관리자를 사용하고, 다음을 입력하여 시스템에서 새로 검색된 모든 장치(읽기/쓰기 시스템 포함)를 구성
하십시오.
cfgmgr
2. 다음 명령을 입력하여 현재 구성된 모든 읽기/쓰기 광 드라이브의 이름, 위치 코드 및 유형을 나열하십시오.

lsdev -C -c rwoptical
3. 추가할 드라이브의 위치와 일치하는 위치 코드를 참조하여 새로 구성된 읽기/쓰기 광 드라이브의 이름을 확인
하십시오.
다수의 장치 구성
장치에는 프린터, 드라이브, 어댑터, 버스, 엔클로저(enclosure)와 같은 하드웨어 구성요소와 오류 특수 파일 및
널(null) 특수 파일과 같은 의사 장치가 포함됩니다. 장치 드라이버는 /usr/lib/drivers 디렉토리에 있습니
다.
AIX 에서 지원 가능한 장치의 수는 몇 가지 중요한 요소에 따라 시스템마다 다를 수 있습니다. 장치를 지원하는
파일 시스템에 영향을 주는 요소는 다음과 같습니다.
• 다수의 장치를 구성하려면 ODM 장치 구성 데이터베이스에 더 많은 정보를 저장할 수 있는 스토리지가 필요합
니다. 더 많은 장치 특수 파일이 필요할 수도 있습니다. 따라서 파일 시스템에서 더 많은 공간과 i-노드를 사용해
야 합니다.
• 일부 장치는 다른 장치보다 ODM 장치 구성 데이터베이스에서 더 많은 공간을 사용합니다. 사용되는 특수 파일
이나 i-노드 수 또한 장치마다 다릅니다. 따라서 파일 시스템에서 필요한 공간과 i-노드 수는 시스템의 장치 유
형에 따라 다릅니다.
• 다중 경로 입출력(MPIO) 장치는 비 MPIO 장치보다 많은 공간을 필요로 합니다. 이는 장치 자체에 대한 정보와
함께 장치에 대한 각각의 경로가 ODM에 저장되기 때문입니다. 각 경로는 장치 자체가 차지하는 공간의 20%
정도를 차지한다고 보면 됩니다. 예를 들어, 경로가 5개인 MPIO 장치는 두 개의 비 MPIO 장치가 사용하는 공
간을 사용합니다.
• AIX 에서는 ODM 장치 구성 데이터베이스에 논리적 장치와 물리적 장치를 모두 포함합니다. 논리적 장치에는
볼륨 그룹, 논리적 볼륨, 네트워크 인터페이스 등이 포함됩니다. 논리적 장치와 물리적 장치 간의 관계가 지원
되는 총 장치 수에 많은 영향을 주는 경우도 있습니다. 예를 들어, 시스템에 연결된 각 물리적 디스크에 대해 논
리적 볼륨이 두 개씩 있는 볼륨 그룹을 정의할 경우, 각 디스크에 대해 4개의 AIX 장치가 만들어집니다. 반면,
각 물리적 디스크에 대해 논리적 볼륨이 6개씩 있는 볼륨 그룹을 정의할 경우, 각 디스크에 대해 8개의 AIX 장
치가 만들어집니다. 따라서 이 중 절반만 연결이 가능합니다.
장치 관리 37
• 장치 속성을 디폴트 설정에서 다른 설정으로 변경하면 ODM 장치 구성 데이터베이스의 크기가 커져서 지원되
는 장치 수가 줄어들 수 있습니다.
• 장치가 많을수록 필요한 실제 메모리도 늘어납니다.
장치를 지원하기 위해 AIX 에서 사용하는 두 파일 시스템은 다음과 같습니다.
• RAM 파일 시스템 - 페이징 공간이 없고 디스크 파일 시스템이 마운트되지 않은 환경에서 부트 중 사용됩니다.
RAM 파일 시스템의 크기는 시스템 메모리 크기의 25%이며 최대 128MB입니다. RAM 파일 시스템의 각 KB에
한 개의 i-노드가 할당됩니다. AIX 운영 체제의 최소 시스템 메모리 요구사항은 256MB이고, 이는 65536 i-노
드가 있는 64MB 크기의 최소 RAM 파일 시스템으로 변환됩니다. 시스템 메모리 크기가 512MB 이상이면 RAM
파일 시스템의 최대 크기가 i-노드가 131072개인 128MB가 됩니다. 연결된 장치를 지원하는 데 필요한 RAM
파일 시스템 공간의 크기나 i-노드 수가 RAM 디스크에 할당된 크기를 초과하면 시스템이 부트되지 않을 수도
있습니다. 이와 같은 경우에는 장치 중 일부를 제거해야 합니다.
• 디스크의 루트 파일 시스템(rootvg)의 공간 및 i-노드 수 - rootvg에 할당되지 않은 파티션이 있으면 디스크의
루트 파일 시스템(rootvg)의 공간 및 i-노드 수를 늘릴 수 있습니다. 최대 RAM 파일 시스템 크기에서는 최대
25,000개의 AIX 장치를 구성할 수 있습니다. 이 수치에는 물리적 장치와 논리적 장치가 모두 포함됩니다. 이
절에서 언급한 다양한 요소에 따라 시스템에서 구성할 수 있는 장치가 이보다 많거나 적을 수 있습니다.
참고: 시스템에 다수의 장치가 있으면 구성하는 데 걸리는 시간이 늘어나고 이에 따라 부트 시간도 길어집니다.
이동식 매체 드라이브 추가
이동식 매체 드라이브를 추가할 수 있습니다.
다음 프로시저에서는 SMIT를 사용하여 시스템에 CD-ROM 드라이브를 추가합니다. 다른 유형의 이동식 매체는
서로 단축 경로를 사용하여 추가되나 모두 같은 일반 프로시저를 따릅니다. 구성 관리자 또는 mkdev 명령을 사용
하여 이동식 매체 드라이브를 추가할 수도 있습니다.
1. 시스템에 CD-ROM 드라이브를 추가하려면 시스템과 함께 제공되는 문서에 따라 하드웨어를 설치하십시오.
2. 루트 권한을 사용하여 다음과 같은 SMIT 단축 경로를 입력하십시오.
smit makcdr
3. 다음 화면에서는 지원되는 드라이브의 사용 가능 리스트에서 드라이브 유형을 선택하십시오.

4. 다음 화면에서는 사용 가능 리스트에서 상위 어댑터를 선택하십시오.
5. 다음 화면에서는 사용 가능 리스트에서 최소한 연결 주소를 선택하십시오. 또한 이 화면에서 기타 옵션도 선
택할 수 있습니다. 종료되면 Enter를 누르십시오. 그러면 SMIT가 새로운 CD-ROM 드라이브를 추가합니다.
이 시점에서 새로운 CD-ROM 드라이브가 시스템에 의해 인식됩니다. 읽기/쓰기 광 드라이브를 추가하려면,
smit makomd 단축 경로를 사용하십시오. 테이프 드라이브를 추가하려면 smit maktpe 단축 경로를 사용하
십시오.
논리적 볼륨 스토리지를 위한 공간 재이용 지원

7200-01 기술 레벨 이상이 있는 AIX 7.2에서 논리적 볼륨 관리자(LVM)는 공간 재이용이 가능한 물리적 볼륨을
위한 공간 재이용을 지원합니다.
LVM은 디스크 드라이브에게 알리고, 이는 차례로 스토리지 서브시스템에 파티션 공간이 더 이상 사용 중이 아님
을 알리고 스토리지 서브시스템은 할당된 공간을 재이용합니다. 디스크 드라이브는 LVM이 물리적 볼륨의 공간
재이용 기능을 발견하도록 돕습니다. LVM 및 rmlv 명령, rmlvcopy 명령 및 chfs(shrink fs) 명령 등과 같
은 파일 시스템 구성 명령은 공간이 사용 가능하게 된 후에 파티션의 공간 재이용을 초기화합니다. LVM은
varyonvg 또는 extendvg 명령의 실행 동안에 볼륨을 열 때 물리적 볼륨의 공간 재이용 기능을 발견합니다.
LVM은 또한 볼륨 그룹이 온라인인 동안 이를 발견하려고 시도합니다. 상태 변경 발견을 위해 물리적 볼륨을 다시
열어야 하는 경우에는 관리자는 varyoffvg 명령을 실행한 다음 볼륨 그룹을 위해 varyonvg 명령을 실행해야
합니다.
AIX 7.2 기술 레벨 1 이전에 작성된 볼륨 그룹에는 여유 파티션 공간이 있을 수 있으며, 이는 자동 재이용에 적합
하지 않습니다. 관리자는 이 공간을 재이용하기 위해 이러한 여유 파티션에 더미 논리적 볼륨을 작성하고 삭제할
수 있습니다. 그러나 AIX 7.2 기술 레벨 1의 설치 후부터는 사용 가능하게 되어 공간은 파티션을 위해 자동으로
재이용됩니다.
공간을 재이용하기 위한 LVM 프로세스는 rmlv 등과 같은 명령이 실행을 완료한 후에 백그라운드에서 실행됩니
다. LVM 프로세스가 모든 파티션의 재이용 프로세스를 완료하기 전에 시스템이 고장나는 경우에는 파티션은 사
용 가능하게 되지만 공간은 보류 중인 파티션을 위해 재이용되지 않습니다. 이 시나리오가 발생하는 경우에는 더
미 논리적 볼륨을 작성하고 삭제하여 나머지 파티션의 공간을 재이용할 수 있습니다.
LVM 프로세스는 공간 재이용 프로세스가 보류 중이더라도 varyoffvg 명령 또는 reducevg 명령의 처리를 지
연하지 않습니다. 공간 재이용 프로세스는 프로세스가 완료되기를 기다리는 대신에 버려집니다.
참고: 명령은 디스크 드라이버에 제출된 미결 공간 재이용 요청만을 기다립니다.
공간 재이용 기능은 물리적 볼륨으로부터 사용 가능한 공간을 재이용하기 위해 스토리지 서브시스템에서 사용
가능합니다. 각 스토리지 서브시스템은 재이용 요청이 특정 수의 물리적 블록에 정렬되어 있을 것으로 예상하고
물리적 블록의 수는 스토리지 서브시스템에 따라 다릅니다. 따라서 때로는 재이용 크기가 파티션의 물리적 블록
에 정렬되지 않았기 때문에 파티션으로부터 블록 재이용(전부 또는 일부)이 불가능합니다. 일부 스토리지 서브시
스템은 LVM 파티션 크기보다 큰 블록 크기의 재이용을 지원하고, 부분 블록 재이용은 불가능합니다. 이 시나리오
에서 LVM은 심지어 단 하나의 재이용 요청을 생성하기 위해 충분한 연속된 사용 가능 파티션을 누적하지 못할 수
도 있습니다. 그러므로 여러 LVM 파티션을 삭제할 때에는 스토리지 서브시스템에 이와 동일한 공간의 양을 재이
용하지 못할 수도 있습니다. lvmstat 명령을 -r 옵션과 함께 사용하여 LVM이 생성하는 공간 재이용 요청에 대
한 정보를 얻을 수 있습니다.
관련 정보
varyoffvg 명령
논리적 볼륨 스토리지 개념
여러 물리적 볼륨으로 확장될 수 있는 논리적 볼륨은 물리적 파티션에 할당된 논리적 파티션들로 구성됩니다.
다음 그림은 논리적 스토리지의 기본 개념들 간의 관계를 보여 줍니다.
그림 2. 볼륨 그룹
장치 관리 39
물리적 볼륨
디스크를 볼륨 그룹에 지정하려면 먼저 물리적 볼륨에 이를 지정하고 사용 가능한 상태로 전환해야 합니다.
물리적 볼륨에는 특정 구성 및 ID 정보가 기록되어 있습니다. 이 정보로는 시스템에 고유한 물리적 볼륨 ID가 포
함됩니다.
LVM은 동일한 디스크의 불필요한 배열(RAID)이 LUN과 연관된 물리적 볼륨에 물리적 파티션을 추가하여 논리
장치 번호(LUN)에 추가할 수 있는 추가 공간을 사용할 수 있습니다.
볼륨 그룹
볼륨 그룹은 다양한 크기와 유형을 가진 1 - 32개의 물리적 볼륨의 집합입니다.
큰 볼륨 그룹은 1 - 128개의 물리적 볼륨을 포함할 수 있습니다. 확장 가능한 볼륨 그룹은 최대 1024개의 물리적
볼륨을 포함할 수 있습니다. 물리적 볼륨은 시스템마다 하나의 볼륨 그룹에만 속할 수 있으므로 최대 255개의 활
성 볼륨 그룹을 포함할 수 있습니다.
물리적 볼륨이 볼륨 그룹에 지정되면 스토리지 미디어의 물리적 블록은 볼륨 그룹을 작성할 때 지정한 크기의 물
리적 파티션으로 구성됩니다.
시스템을 설치할 때 시스템을 시작하는 데 필요한 논리적 볼륨의 기본 세트를 포함하는 하나의 볼륨 그룹(rootvg
라는 루트 볼륨 그룹)과 설치 스크립트에 지정한 다른 논리적 볼륨이 자동으로 작성됩니다. rootvg에는 각각 별도
의 논리적 볼륨에 페이징 공간, 저널 로그, 부트 데이터 및 덤프 스토리지가 포함됩니다. rootvg는 사용자 정의 볼
륨 그룹과 다른 속성을 가집니다. 예를 들어, rootvg는 반입하거나 반출할 수 없습니다. rootvg에서 명령이나 절
차를 수행할 때는 고유한 특성에 익숙해야 합니다.
볼륨 그룹은 mkvg 명령을 사용하여 작성합니다. extendvg 명령을 사용하여 물리적 볼륨을 볼륨 그룹에 추가하
고 chvg 명령을 사용하여 물리적 볼륨의 변경된 크기를 사용하여 reducevg 명령을 통해 볼륨 그룹에서 물리적
볼륨을 제거합니다. 볼륨 그룹에서 사용하는 다른 명령으로는 list(lsvg), remove(exportvg),
install(importvg), reorganize(reorgvg), synchronize(syncvg), make available for use(varyonvg),
make unavailable for use(varyoffvg) 등이 있습니다.
작은 시스템에는 시스템에 연결된 모든 물리적 볼륨을 포함하는 하나의 볼륨 그룹만 필요할 수 있습니다. 그러나
각 볼륨 그룹이 자체의 보안 권한을 가질 수 있기 때문에 보안 상 별도의 볼륨 그룹을 작성할 수 있습니다. 별도의
볼륨 그룹을 작성하면 서비스 중인 그룹 이외의 그룹이 활성 상태일 수 있으므로 유지보수가 간편합니다. rootvg
는 항상 온라인이어야 하므로 시스템 조작에 필요한 최소의 물리적 볼륨만 포함합니다.
migratepv 명령을 사용하여 하나의 물리적 볼륨에서 같은 볼륨 그룹의 다른 물리적 볼륨으로 데이터를 이동할
수 있습니다. 이 명령을 사용하여 볼륨 그룹에서 제거될 수 있도록 실제 볼륨을 비울 수 있습니다. 예를 들어, 대체
할 데이터를 물리적 볼륨에서 이동할 수 있습니다.
적은 물리적 및 논리적 볼륨 제한으로 작성된 볼륨 그룹을 더 많은 물리적 볼륨과 논리적 볼륨을 보관할 수 있는
형식으로 변환할 수 있습니다. 이 조작에서는 VGDA(volume group descriptor area) 확장을 위해 볼륨 그룹의 모
든 물리적 볼륨에서 사용할 수 있는 파티션이 충분히 있어야 합니다. 필요한 사용 가능한 파티션 수는 현재 VGDA
의 크기와 물리적 파티션 크기에 따라 다릅니다. VGDA가 디스크의 가장자리에 상주하고 연속 공간이 필요하기
때문에 디스크의 가장자리에 사용 가능한 파티션이 필요합니다. 그러한 파티션이 사용자가 사용할 수 있도록 할
당되면 같은 디스크의 다른 사용 가능한 파티션으로 이주합니다. 나머지 물리적 파티션은 VGDA 사용을 위한 파
티션의 유실을 반영하기 위해 번호가 다시 매겨집니다. 번호 다시 매기기로 인해 이 볼륨 그룹의 모든 물리적 파
티션에 있는 물리적 파티션으로 논리적 볼륨의 맵핑이 변경됩니다. 복구 조작을 위해 논리적 볼륨의 맵핑을 저장
한 경우 변환 조작이 완료되면 맵을 다시 생성하십시오. 또한 맵 옵션을 사용하여 볼륨 그룹을 백업한 경우 해당
맵을 사용하여 복원하려면 감소로 인해 파티션 번호가 더 이상 존재하지 않으므로 복원 조작에 실패할 수 있습니
다. 백업은 변환 전에 수행하고 맵 옵션이 사용된 경우에는 변환 후에 수행하는 것이 좋습니다. VGDA 공간이 크
게 늘었기 때문에 모든 VGDA 갱신 조작(논리적 볼륨 작성, 논리적 볼륨 변경, 물리적 볼륨 추가 등)을 실행하는
데 오래 걸릴 수 있습니다.
물리적 파티션
물리적 볼륨을 볼륨 그룹에 추가하는 경우 물리적 볼륨은 물리적 파티션이라는 동일한 크기의 연속 공간 단위로
분할됩니다. 실제 파티션은 스토리지 공간 할당의 가장 작은 단위이며, 실제 볼륨에서 연속적인 공간입니다.
물리적 볼륨은 볼륨 그룹을 작성할 때만 설정할 수 있는 볼륨 그룹의 물리적 파티션 크기를 상속합니다(예: mkvg
-s 명령 사용). 다음 그림은 물리적 볼륨의 물리적 파티션과 볼륨 그룹 간의 관계를 보여 줍니다.
그림 3. 세 개의 물리적 볼륨이 포함된 볼륨 그룹
논리적 볼륨
볼륨 그룹을 작성한 후 이 볼륨 그룹 내에 논리적 볼륨을 작성할 수 있습니다.
논리적 볼륨은 연속되지 않는 여러 물리적 파티션인 둘 이상의 물리적 볼륨에 상주할 수 있지만, 사용자와 애플리
케이션에는 하나의 연속적이며 확장 가능한 디스크 볼륨으로 나타납니다. mklv 명령을 사용하여 논리적 볼륨을
추가로 작성할 수 있습니다. mklv 명령을 사용하면 논리적 볼륨의 이름을 지정할 수 있으며, 논리적 볼륨에 할당
할 논리적 파티션의 수와 위치를 포함하여 논리적 볼륨의 특성을 정의할 수 있습니다.
논리적 볼륨을 작성한 후 chlv 명령을 사용하여 이름 및 특성을 변경하고 extendlv 명령을 사용하여 할당된
논리적 파티션 수를 증가시킬 수 있습니다. 작성시 논리적 볼륨의 디폴트 최대 크기는 더 크게 지정되지 않는 한
512개의 논리적 파티션입니다. chlv 명령은 이 제한을 겹쳐쓰는 데 사용됩니다.
참고: 논리적 볼륨을 작성한 후, 특성 LV STATE가 닫힙니다. 특성 LV STATE는 lslv 명령을 사용하여 볼 수 있습
니다. 그런 다음 논리적 볼륨에 파일 시스템이 작성되고 이 논리적 볼륨이 마운트될 때 열립니다.
또한 논리적 볼륨은 cplv 명령을 사용하여 복사하고, lslv 명령을 사용하여 나열하고, rmlv 명령을 사용하여
제거하고, 각각 mklvcopy 및 rmlvcopy 명령을 사용하여 논리적 볼륨에 유지되는 사본 수를 늘리거나 줄일 수
있습니다. 볼륨 그룹이 재구성되면 논리적 볼륨의 배치를 바꿀 수도 있습니다.
표준 볼륨 그룹당 최대 255개의 논리적 볼륨을 정의할 수 있지만(큰 볼륨 그룹의 경우 511, 확장 가능한 볼륨 그
룹의 경우 4095), 실제로 정의할 수 있는 논리적 볼륨 수는 해당 볼륨 그룹에 정의된 물리적 스토리지의 총 크기
와 사용자가 정의한 논리적 볼륨의 크기에 따라 달라집니다.
장치 관리 41
논리적 파티션
논리적 볼륨을 작성할 때 논리적 볼륨의 논리적 파티션 수를 지정할 수 있습니다.
하나의 논리적 파티션은 유지보수하려고 하는 데이터 인스턴스의 수에 따라 하나, 둘 또는 세 개의 물리적 파티션
에 해당합니다. 인스턴스를 하나 지정하면 논리적 볼륨의 사본이 하나만 있다는 것을 의미합니다(디폴트). 이 경
우, 하나의 논리적 파티션이 하나의 물리적 파티션으로 직접 맵핑됩니다. 첫 번째 인스턴스를 비롯한 각 인스턴스
를 사본이라고 합니다. 물리적 파티션이 배치되는 위치, 즉, 각각의 물리적 파티션이 서로 얼마나 인접해있는지는
사용자가 논리적 볼륨을 작성할 때 지정한 옵션에 따라 달라집니다.
파일 시스템
논리적 볼륨은 물리적 파티션 레벨로의 디스크 공간 할당을 정의합니다. 가상 메모리 관리자 또는 파일 시스템과
같은 상위 레벨 소프트웨어 구성요소에서 세분화된 레벨의 데이터 관리를 수행할 수 있습니다. 그러므로 디스크
전개의 마지막 단계는 파일 시스템 작성입니다.
논리적 볼륨마다 하나의 파일 시스템을 작성할 수 있습니다. 파일 시스템을 작성하려면 crfs 명령을 사용하십시
오.
논리적 스토리지 관리에 대한 제한사항

다음 표에서는 논리적 스토리지 관리 시 따르는 제한사항을 보여 줍니다.
볼륨 그룹당 최대 물리적 볼륨 수는 디폴트로 32(큰 볼륨 그룹의 경우 128, 확장 가능한 볼륨 그룹의 경우 1024)
개이지만 mkvg 명령을 사용하여, 사용자 정의 볼륨 그룹의 최대 크기를 설정할 수 있습니다. 하지만 rootvg에 대
해서는 이 변수가 자동으로 최대값으로 설정됩니다(설치 중 시스템에서).
논리적 스토리지 관리에 대한 제한사항

범주 한계
볼륨 그룹 • 32비트 커널을 위한 255 볼륨 그룹
• 64비트 커널을 위한 4096 볼륨 그룹
참고: 64비트 커널 위의 장치 테이블은 활성 주요 번호
의 수를 1024로 제한합니다. 따라서, 활성 볼륨 그룹의
수를 1024 볼륨 그룹 미만으로 제한됩니다.
물리적 볼륨 볼륨 그룹당 (MAXPVS/볼륨 그룹 인수). MAXPVS는

표준 볼륨 그룹의 경우 32, 큰 볼륨 그룹의 경우 128,
그리고 확장 가능한 볼륨 그룹의 경우 1024입니다.
물리적 파티션 일반 볼륨 그룹 및 큰 볼륨 그룹: 각각 크기가 최대
1024MB인 물리적 볼륨당 (1016 x 볼륨 그룹 인수).
확장 가능한 볼륨 그룹: 크기가 최대 128GB인
2097152개의 파티션. 확장 가능한 볼륨 그룹의 경우
볼륨 그룹 인수가 없습니다.
논리적 볼륨 볼륨 그룹당 MAXLVS. 표준 볼륨 그룹의 경우 255, 큰
볼륨 그룹의 경우 511, 그리고 확장 가능한 볼륨 그룹
의 경우 4095입니다.
물리적 볼륨당 1016개의 물리적 파티션 제한이 적용되기 전에 볼륨 그룹을 작성한 경우, 지원되는 상태로 볼륨
그룹을 변환하지 않으면, 볼륨 그룹에 있는 효력이 상실된 파티션(더 이상 현재 데이터가 포함되지 않은 파티션)
이 올바르게 추적되지 않습니다. chvg -t 명령을 사용하여 볼륨 그룹을 변환할 수 있습니다. 디폴트로, 볼륨 그룹
의 가장 큰 디스크를 수용할 수 있도록 적합한 인수 값이 선택됩니다.
예를 들어, 9GB의 디스크와 4MB 크기의 파티션이 있는 볼륨 그룹을 작성한 경우, 이 볼륨 그룹에는 대략 2250
개의 파티션이 작성됩니다. 변환 인수 3(1016 * 3 = 3048)을 사용하면 2250개의 파티션 모두가 올바르게 추적
됩니다. 표준 볼륨 그룹 또는 큰 볼륨 그룹을 더 높은 인수를 사용하여 변환하면 최대 1016* 인수의 더 큰 디스크
파티션을 포함할 수 있습니다. 파티션 크기가 작은 대형 디스크를 수용하려는 경우에도 볼륨 그룹을 작성할 때 더
높은 인수를 지정할 수 있습니다.
이러한 작업으로 인해, 볼륨 그룹에 추가할 수 있는 총 디스크 수가 줄어듭니다. 추가할 수 있는 새로운 최대 디스
크 수는 MAXPVS/인수입니다. 예를 들어, 정규 볼륨 그룹의 경우 인수 2는 볼륨 그룹의 최대 디스크 수를
16(32/2)으로 줄입니다. 큰 볼륨 그룹의 경우 인수 2는 볼륨 그룹의 최대 디스크 수를 64(128/2)로 줄입니다.
LVM 장치 크기 한계
다음 한계는 LVM 아키텍처 한계입니다. LVM 사용 불가능 블록 재배치가 필요한 경우에는 PV 크기는 128GB보
다 클 수 없습니다. 특정 스토리지 장치의 크기 제한에 대해서는 스토리지 장치 문서를 참조하십시오.
다음 크기 한계는 64비트 커널용입니다.
원래 VG
PV 한계: 1GB (PP) * 16256 (PPs/PV, factor=16) = 15.9 TB
LV 한계: 1GB (PP) * 32512 (PPs/VG) = 31.8 TB
큰 VG
PV 한계: 1GB (PP) * 65024 (PPs/PV, factor=64) = 63.5 TB
LV 한계: 1GB (PP) * 130048 (PPs/VG) = 127 TB
SVG
PV & LV 한계: 128GB (PP) * 2048K (PPs/PV) = 256 PB
다음 크기 한계는 32비트 커널용입니다.
모든 VG 유형
PV 한계: < 1 TB
LV 한계: < 1 TB
논리적 볼륨 스토리지 구성
논리적 볼륨 스토리지를 사용하면 볼륨 그룹을 미러링하고, 논리적 볼륨을 정의하고, 시스템이 실행 중인 디스크
를 제거할 수 있습니다.
볼륨 그룹 미러링
이 시나리오에서는 일반 볼륨 그룹을 미러하는 방법을 설명합니다.
다음 지시사항은 SMIT(System Management Interface Tool)를 사용하여 루트 볼륨 그룹을 미러하는 방법을 보
여 줍니다.
웹 기반 시스템 관리자를 사용할 경우, 볼륨 컨테이너에서 볼륨 그룹을 선택한 다음 선택 메뉴에서 미러를 선택하
십시오. 숙련된 관리자는 mirrorvg 명령을 사용해도 됩니다.
1. 루트 권한으로, 다음 SMIT 단축 경로를 사용하여 볼륨 그룹에 디스크를 추가하십시오.
smit extendvg
2. 다음 SMIT 단축 경로를 입력하여 새 디스크에 볼륨 그룹을 미러하십시오.

smit mirrorvg
3. 첫 번째 패널에서, 미러할 볼륨 그룹을 선택하십시오.

4. 두 번째 패널에서, 미러링 옵션을 정의하거나 디폴트 값을 그대로 사용할 수 있습니다. 필요에 따라 온라인 도
움말을 사용할 수 있습니다.
참고: SMIT 패널을 모두 완료하고 확인을 누르거나 종료하면, 기본 명령의 실행이 완료될 때까지 많은 시간이 걸
릴 수 있습니다. 명령을 완료하는 데 소요되는 시간은 오류 검사, 볼륨 그룹에 있는 논리적 볼륨의 수와 크기, 새로
미러된 논리적 볼륨을 동기화하는 데 걸리는 시간에 따라 다릅니다.
이때, SMIT 패널에서 지정한 논리적 볼륨의 모든 변경사항이 미러됩니다.
루트 볼륨 그룹 미러링
다음 시나리오에서는 루트 볼륨 그룹(rootvg)을 미러하는 방법을 설명합니다.
참고: 루트 볼륨 그룹을 미러링하려면 숙련된 시스템 관리 경험이 필요합니다. 루트 볼륨 그룹을 올바르게 미러링
하지 않으면 시스템을 부트하지 못할 수 있습니다.
장치 관리 43
다음 시나리오에서 rootvg는 hdisk01에 포함되어 있고, hdisk11이라는 디스크로 미러링됩니다.
1. AIX 에서 hdisk11을 부트 장치로 지원하는지 확인하십시오.
bootinfo -B hdisk11
이 명령이 값 1을 리턴하면, AIX 에서 해당 디스크를 부트할 수 있음을 나타냅니다. 이외에 다른 값을 리턴하

면 rootvg를 미러링하는 데 hdisk11을 사용할 수 없음을 나타냅니다.
2. 다음 명령을 사용하여, hdisk11을 포함하도록 rootvg를 확장하십시오.
extendvg rootvg hdisk11
다음 오류 메시지가 표시될 수 있습니다.

0516-050 Not enough descriptor space left in this volume group, Either try
adding a smaller PV or use another volume group.
또는 다음과 유사한 메시지가 표시될 수 있습니다.

0516-1162 extendvg: Warning, The Physical Partition size of 16 requires the
creation of 1084 partitions for hdisk11. The limitation for volume group
rootvg is 1016 physical partitions per physical volume. Use chvg command with
the -t option to attempt to change the maximum physical partitions per Physical
Volume for this volume group.
다음과 같은 옵션이 있습니다.

• 이미 rootvg에 속한, 빈 디스크에 rootvg를 미러링합니다.
• 보다 작은 크기의 디스크를 사용합니다.
• 다음 절차를 사용하여, rootvg에 지원되는 최대 파티션 수를 변경합니다.
a. 메시지를 참조하여 대상 디스크에 필요한 물리적 파티션 수와 현재 rootvg에 지원되는 최대 물리적 파티
션 수를 확인하십시오.
b. chvg -t 명령을 사용하여 현재 rootvg에 허용되는 최대 파티션 수(위 예제에서는 1016)를 대상 디스
크에 필요한 물리적 파티션 수(위 예제에서는 1084)보다 큰 수로 늘리십시오. 예를 들어 다음과 같습니
다.
chvg -t 2 rootvg
c. 2단계를 시작할 때 extendvg 명령을 재수행하십시오.

3. 다음 명령과 같이 정확한 맵핑 옵션을 사용하여 rootvg를 미러링하십시오.
mirrorvg -m rootvg hdisk11
볼륨 그룹이 rootvg일 경우, 이 명령은 쿼럼을 끕니다. 정확한 맵핑 옵션을 사용하지 않을 경우, 부트 논리적
볼륨 hd5의 새 사본이 연속된 파티션으로 구성되었는지 확인해야 합니다.
4. 다음 명령을 사용하여 모든 부트 레코드와 장치를 초기화하십시오.
bosboot -a
5. 다음 명령을 사용하여 부트 리스트를 초기화하십시오.

bootlist -m normal hdisk01 hdisk11
참고:
a. bootlist 명령이 hdisk11을 대체 부트 디스크로 식별하더라도, hdisk01에서 장애가 발생할 경우 시스
템에서 hdisk11을 부트 장치로 사용하는 것을 보장할 수는 없습니다. 이런 경우에는 제품 미디어에서 부
트해야 할 수도 있습니다. 유지보수를 선택한 후 장애가 발생한 디스크를 지정하지 말고 bootlist 명령
을 재수행하십시오.
b. 사용 중인 하드웨어 모델이 bootlist 명령을 지원하지 않을 경우에도 rootvg를 미러할 수는 있습니다.
하지만 원래 디스크를 사용할 수 없을 경우 대체 부트 디스크를 선택해야 합니다.
애플리케이션을 위한 원시 논리적 볼륨 정의
원시 논리적 볼륨은 운영 체제나 파일 시스템에서 직접 제어를 받지 않고 데이터베이스나 파티션과 같은 애플리
케이션에서 직접 제어를 받는 물리적 및 논리적 디스크 공간의 한 영역입니다.
파일 시스템을 무시하면 제어하는 애플리케이션, 특히 데이터베이스 애플리케이션으로부터 더 나은 성능을 낼
수 있습니다. 그러나, 성능의 정도는 데이터베이스나 애플리케이션 드라이버의 크기 등의 요인에 따라 다릅니다.
참고: 애플리케이션에 새로운 원시 논리적 볼륨을 위한 문자나 블록 특수 장치 파일을 적절하게 제공해야 합니다.
애플리케이션이 열고 읽고 쓰는 등의 작업을 시도할 때 이 장치 파일로 링크됩니다.
주의: 각 논리적 볼륨에는 첫 번째 블록에 있는 논리적 볼륨 제어 블록(LVCB)이 있습니다. LVCB의 크기는
볼륨 그룹 내에서 물리적 볼륨의 블록 크기입니다. 데이터는 물리적 볼륨의 두 번째 블록에서 시작합니다.
원시 논리적 볼륨에서는 LVCB는 보호되지 않습니다. 애플리케이션이 LVCB를 겹쳐쓰면, 보통 LVCB를 갱
신하는 명령이 실패하고 메시지를 생성합니다. 논리적 볼륨이 계속 제대로 작동하고 겹쳐쓰기가 허용되
는 이벤트일 수 있지만, LVCB를 겹쳐쓰는 것은 권장하지 않습니다.
다음 지시사항은 SMIT과 명령행 인터페이스를 사용하여 원시 논리적 볼륨을 정의합니다.
1. 루트 권한으로 다음 SMIT 단축 경로를 입력하여 원시 논리적 볼륨을 작성할 수 있는 사용 가능한 물리적 파티
션을 찾으십시오.
smit lspv
2. 디스크를 선택하십시오.
3. 두 번째 대화상자(상태)에서 디폴트를 승인하고 확인을 누르십시오.
4. FREE PP 필드에 있는 값에 PP SIZE 필드의 값을 곱하여 선택한 디스크에서 원시 논리적 볼륨에 사용 가능한
총 메가바이트 수를 얻으십시오.
사용 가능한 공간이 충분하지 않으면 사용 가능한 공간이 충분한 다른 디스크를 찾을 때까지 다른 디스크를
선택하십시오.
5. SMIT를 종료하십시오.
6. mklv 명령을 사용하여 원시 논리적 볼륨을 작성하십시오.
다음 명령을 실행하면 38개의 4MB 물리적 파티션을 사용하여 db2vg 볼륨 그룹 안에 lvdb2003이라는 원
시 논리적 볼륨이 작성됩니다.
mklv -y lvdb2003 db2vg 38
시스템에서 생성한 이름 대신 논리적 볼륨의 이름을 직접 제공하려면 -y 플래그를 사용하십시오.

이 때 원시 논리적 볼륨이 작성됩니다. 볼륨 그룹의 컨텐츠를 나열하면, 원시 논리적 볼륨이 디폴트 유형인 jfs로
표시됩니다. 논리적 볼륨에 대한 이런 유형 항목은 단순히 레이블입니다. 이는 파일 시스템이 원시 논리적 볼륨에
대해 마운트되었음을 나타내지 않습니다.
/dev/rawLVname을 열고 이 원시 공간을 사용하는 방법에 대한 애플리케이션의 지시사항을 참조하십시오.
관련 개념
논리적 볼륨 관리자 구성
LVM(논리적 볼륨 관리자)는 기본 운영 체제(BOS)와 함께 설치되므로 추가 구성이 필요하지 않습니다. 하지만
LVM이 디스크를 사용할 수 있으려면 디스크를 물리적 볼륨으로 구성 및 정의해야 합니다.
관련 정보
mklv 명령
루트 볼륨 그룹 미러 제거
루트 볼륨 그룹의 미러를 제거할 수 있습니다.
주의: 루트 볼륨 그룹의 미러를 제거하려면 전문적인 시스템 관리 경험이 필요합니다. 제대로 수행되지
않으면 시스템을 부팅하지 못하게 될 수 있습니다.
장치 관리 45
다음 시나리오에서 루트 볼륨 그룹은 hdisk01에 있으며 hdisk11로 미러링됩니다. 이 예제에서는 hdisk11에서
미러를 제거합니다. 마지막으로 부팅된 디스크와 관계없이 절차는 같습니다.
1. hdisk11에서 루트 볼륨 그룹의 미러를 제거하려면 다음 명령을 사용하십시오.
unmirrorvg rootvg hdisk11
unmirrorvg 명령은 루트 볼륨 그룹에 대해 쿼럼을 다시 설정합니다.

2. 루트 볼륨 그룹에서 디스크를 줄이려면 다음 명령을 사용하십시오.
reducevg rootvg hdisk11
3. 나머지 디스크의 부트 레코드를 다시 초기화하려면 다음 명령을 사용하십시오.

bosboot -a -d /dev/hdisk01
4. 리스트에서 미러가 제거된 디스크를 제거하려면 다음 명령을 사용하여 부트 리스트를 수정하십시오.

bootlist -m normal hdisk01
디스크 미러가 제거됩니다.
시스템이 사용 가능한 상태로 남아 있는 동안 디스크 제거

다음 절차에서는 시스템 전원을 차단하지 않고 디스크를 제거할 수 있는 핫 제거 기능을 사용하여 디스크를 제거
하는 방법에 대해 설명합니다. 이 기능은 특정 시스템에서만 사용할 수 있습니다.
핫 제거 기능은 다음과 같은 경우에 유용합니다.
• 보안 또는 유지보수를 위해 별도의 비rootvg 볼륨 그룹에 데이터를 포함하는 디스크를 제거하는 경우
• 볼륨 그룹에서 디스크 영구적으로 제거하는 경우
• 디스크 장애를 해결하려는 경우
데이터가 포함된 디스크 제거

시스템을 끄지 않고 데이터가 포함된 디스크를 제거하려면 이 절차를 사용하십시오.
제거하려는 디스크는 별도의 비rootvg 볼륨 그룹에 있어야 합니다. 디스크를 다른 시스템으로 이동하려는 경우
이 절차를 사용하십시오.
1. 제거할 디스크와 연관된 볼륨 그룹을 나열하려면 다음을 입력하십시오.
smit lspv
출력은 다음과 같이 표시됩니다.

PHYSICAL VOLUME: hdisk2 VOLUME GROUP: imagesvg
PV IDENTIFIER: 00083772caa7896e VG IDENTIFIER
0004234500004c00000000e9b5cac262
PV STATE: active
STALE PARTITIONS: 0 ALLOCATABLE: yes
PP SIZE: 16 megabyte(s) LOGICAL VOLUMES: 5
TOTAL PPs: 542 (8672 megabytes) VG DESCRIPTORS: 2
FREE PPs: 19 (304 megabytes) HOT SPARE: no
USED PPs: 523 (8368 megabytes)
FREE DISTRIBUTION: 00..00..00..00..19
USED DISTRIBUTION: 109..108..108..108..90
볼륨 그룹의 이름은 VOLUME GROUP 필드에 나열됩니다. 이 예제에서 볼륨 그룹은 imagesvg입니다.

2. 디스크가 별도의 비rootvg 볼륨 그룹에 있는지 확인하려면 다음을 입력하십시오.
smit lsvg
그런 다음 디스크와 연관된 볼륨 그룹(이 예제에서는 imagesvg)을 선택하십시오. 출력은 다음과 같이 표시됩

니다.
VOLUME GROUP: imagesvg VG IDENTIFIER:
0004234500004c00000000e9b5cac262
VG STATE: active PP SIZE: 16 megabyte(s)

VG PERMISSION: read/write TOTAL PPs: 542 (8672 megabytes)
MAX LVs: 256 FREE PPs: 19 (304 megabytes)
LVs: 5 USED PPs: 523 (8368 megabytes)
OPEN LVs: 4 QUORUM: 2
TOTAL PVs: 1 VG DESCRIPTORS: 2
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 1 AUTO ON: yes
MAX PPs per PV: 1016 MAX PVs: 32
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no
이 예제에서 TOTAL PVs 필드는 imagesvg와 연관된 물리적 볼륨이 한 개뿐임을 나타냅니다. 이 볼륨 그룹의
모든 데이터가 hdisk2에 포함되어 있으면 이 절차를 사용하여 hdisk2를 제거할 수 있습니다.
3. 디스크의 논리적 볼륨에서 파일 시스템을 마운트 해제하려면 다음을 입력하십시오.
smit umountfs
4. 볼륨 그룹을 비활성화하려면 다음을 입력하십시오.

smit varyoffvg
5. 볼륨 그룹을 반출하려면 다음을 입력하십시오.

smit exportvg
6. 디스크를 제거하려면 다음을 입력하십시오.

smit rmvdsk
7. 제거할 디스크의 LED 표시장치를 확인하십시오. 노란색 LED가 꺼졌는지(깜박이지 않음) 확인하십시오.
8. 디스크를 물리적으로 제거하십시오. 제거 절차에 대한 자세한 정보는 시스템용 서비스 안내서를 참조하십시
오.
이제 디스크가 시스템에서 물리적 및 논리적으로 제거됩니다. 이 디스크를 영구 제거하려면 이 절차를 완료하십
시오.
데이터가 포함되지 않은 디스크 제거

다음 절차에서는 보관할 데이터가 포함되지 않은 디스크를 제거하는 방법에 대해 설명합니다.
주의: 다음 절차는 디스크에 상주하는 데이터를 지웁니다.
1. 디스크의 논리적 볼륨에서 파일 시스템을 마운트 해제하려면 다음을 입력하십시오.

smit umountfs
2. 볼륨 그룹을 비활성화하려면 다음을 입력하십시오.

smit varyoffvg
3. 볼륨 그룹을 반출하려면 다음을 입력하십시오.

smit exportvg
4. 디스크를 제거하려면 다음을 입력하십시오.

smit rmvdsk
5. 제거할 디스크의 LED 표시장치를 확인하십시오. 노란색 LED가 꺼졌는지(깜박이지 않음) 확인하십시오.
6. 디스크를 물리적으로 제거하십시오.
제거 절차에 대한 자세한 정보는 시스템용 서비스 안내서를 참조하십시오.
이제 디스크가 시스템에서 물리적 및 논리적으로 제거됩니다. 이 디스크를 영구 제거하려면 이 절차를 완료하십
시오.
장치 관리 47
파일 시스템을 제거하여 논리적 볼륨 제거
다음 절차는 JFS 또는 JFS2 파일 시스템, 연관된 논리적 볼륨, /etc/filesystems 파일의 연관된 스탠자를 제
거하고 선택적으로 파일 시스템이 마운트된 마운트 위치(디렉토리)를 제거하는 방법에 대해 설명합니다.
주의: 파일 시스템을 제거하면 지정된 파일 시스템과 논리적 볼륨의 모든 데이터가 제거됩니다.
마운트된 다른 유형의 파일 시스템과 함께 논리적 볼륨을 제거하거나 파일 시스템을 포함하지 않는 논리적 볼륨

을 제거하려면 논리적 볼륨만을 제거하면 됩니다.
SMIT를 통해 저널 파일 시스템을 제거하려면 다음 절차를 사용하십시오.
1. 다음 예제와 비슷한 명령을 사용하여 논리적 볼륨에 상주하는 파일 시스템을 마운트 해제하십시오.
umount /adam/usr/local
참고: 사용 중인 장치에는 umount 명령을 사용할 수 없습니다. 파일이 열려 있거나 사용자의 현재 디렉토리
가 해당 장치에 있으면 장치를 사용하고 있는 것입니다.
2. 파일 시스템을 제거하려면 다음과 같은 단축 경로를 입력하십시오.
smit rmfs
3.
1. 제거할 파일 시스템의 이름을 선택하십시오.
2. 마운트 위치 제거 필드로 이동하고 기본 설정으로 토글하십시오. yes를 선택하면 기본 명령은 파일 시스템이
마운트된 마운트 위치(디렉토리)도 제거합니다(디렉토리가 비어 있는 경우).
3. Enter를 눌러 파일 시스템을 제거하십시오. SMIT가 파일 시스템을 제거할 것인지 확인하는 프롬프트를 표시
합니다.
4. 파일 시스템을 제거할 것인지 확인하십시오. 파일 시스템이 제거되면 SMIT가 메시지를 표시합니다.
이제 파일 시스템, 데이터 및 연관된 논리적 볼륨이 시스템에서 완전히 제거되었습니다.
관련 태스크
논리적 볼륨만 제거
파일 시스템이 포함되지 않은 논리적 볼륨 또는 여러 유형의 파일 시스템이 마운트된 논리적 볼륨을 제거하려면
논리적 볼륨만 제거
파일 시스템이 포함되지 않은 논리적 볼륨 또는 여러 유형의 파일 시스템이 마운트된 논리적 볼륨을 제거하려면
주의: 논리적 볼륨을 제거하면 지정된 파일 시스템과 논리적 볼륨의 모든 데이터가 제거됩니다.
다음 절차는 논리적 볼륨 및 관련된 파일 시스템을 제거하는 방법에 대해 설명합니다. 이 절차를 사용하면 파일

시스템이 포함되지 않은 비JFS 파일 시스템 또는 논리적 볼륨을 제거할 수 있습니다. 다음 절차 뒤에는 논리적 볼
륨을 제거하는 방법과 /etc/filesystems 파일에서 비JFS 파일 시스템의 스탠자를 제거하는 방법이 설명되
어 있습니다.
SMIT를 통해 논리적 볼륨을 제거하려면 다음 절차를 사용하십시오.
1. 논리적 볼륨에 파일 시스템이 포함되어 있지 않으면 4단계로 건너뛰십시오.
2. 다음을 입력하여 논리적 볼륨과 연관된 파일 시스템을 모두 마운트 해제하십시오.
unmount /FSname
여기서 /FSname은 파일 시스템의 전체 경로 이름입니다.

참고:
a. unmount 명령은 unmount를 시도하는 파일 시스템이 사용 중이면 실패합니다. unmount 명령은 파일
시스템이 열려 있지 않고 사용자의 현재 디렉토리가 해당 장치에 있지 않은 경우에만 실행됩니다.
3. 파일 시스템에 대해 알아야 할 정보를 나열하려면 다음 단축 경로를 입력하십시오.
smit lsfs
다음은 나열되는 정보 중 일부입니다.

Name Nodename Mount Pt ...
/dev/hd3 -- /tmp ...
/dev/locallv -- /adam/usr/local ...
4. 두 번째 나열된 항목에 대한 표준 이름 지정 규칙을 가정하여 파일 시스템의 이름은 /adam/usr/local로

붙여지고 논리적 볼륨은 locallv로 지정됩니다. 이를 확인하려면 다음 단축 경로를 입력하십시오.
smit lslv2
다음은 나열되는 정보 중 일부입니다.

imagesvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd3 jfs 4 4 1 open/syncd /tmp
locallv mine 4 4 1 closed/syncd /adam/usr/local
5. 논리적 볼륨을 제거하려면 명령행에 다음 단축 경로를 입력하십시오.

smit rmlv
6. 제거할 논리적 볼륨의 이름을 선택하십시오.

7. 마운트 위치 제거 필드로 이동하고 기본 설정으로 토글하십시오. 예를 선택하면 기본 명령은 파일 시스템이
마운트된 마운트 위치(디렉토리)도 제거합니다(디렉토리가 있는 경우 및 해당 디렉토리가 비어 있는 경우).
8. Enter를 눌러 논리적 볼륨을 제거하십시오. SMIT가 논리적 볼륨을 제거할 것인지 확인하는 프롬프트를 표
시합니다.
9. 논리적 볼륨을 제거할 것인지 확인하십시오. 논리적 볼륨이 제거되면 SMIT가 메시지를 표시합니다.
10. 논리적 볼륨에 마운트된 비JFS 파일 시스템이 있으면 다음 예제에 표시된 것처럼 파일 시스템 및 /etc/
filesystems 파일의 연관된 스탠자를 제거하십시오.
rmfs /adam/usr/local
또는 파일 시스템 이름을 다음과 같이 사용할 수 있습니다.

rmfs /dev/locallv
이제, 논리적 볼륨이 제거됩니다. 논리적 볼륨에 비JFS 파일 시스템이 포함된 시스템의 스탠자도 /etc/
filesystems 파일에서 제거됩니다.
관련 태스크
파일 시스템을 제거하여 논리적 볼륨 제거
다음 절차는 JFS 또는 JFS2 파일 시스템, 연관된 논리적 볼륨, /etc/filesystems 파일의 연관된 스탠자를 제
거하고 선택적으로 파일 시스템이 마운트된 마운트 위치(디렉토리)를 제거하는 방법에 대해 설명합니다.
RAID 볼륨 그룹 크기 조정
독립 디스크의 불필요한 배열(RAID)을 사용하는 시스템에서는, chvg 및 chpv 명령 옵션은 RAID 그룹에 디스크
를 추가하고 시스템의 사용 또는 가용성을 인터럽트하지 않고 LVM이 사용하는 물리적 볼륨의 크기를 늘리는 기
능을 제공합니다.
참고:
1. 볼륨 그룹이 클래식 모드와 확장 동시 모드에서 활성화되는 동안에는 이 기능을 사용할 수 없습니다.
2. rootvg 볼륨 그룹은 다음 절차를 사용하여 크기를 조정할 수 없습니다.
3. 활성 페이징 공간이 있는 볼륨 그룹은 다음 절차를 사용하여 크기를 조정할 수 없습니다.
장치 관리 49
볼륨 그룹의 모든 디스크 크기는 볼륨 그룹이 활성화될 때(varyon) 자동으로 검사됩니다. 크기 증가가 발견되면
정보 메시지가 생성됩니다.
다음 절차는 RAID 환경에서 디스크 크기를 늘리는 방법에 대해 설명합니다.
1. 디스크가 증가하는지 확인하고 필요에 따라 크기를 조정하려면 다음 명령을 입력하십시오.
chvg -g VGname
여기서 VGname은 사용자의 볼륨 그룹 이름입니다. 이 명령은 볼륨 그룹의 모든 디스크를 검사합니다. 크기

가 증가하면 물리적 파티션이 물리적 볼륨에 추가됩니다. 필요하면 적절한 1016 제한 승수를 결정하고 볼륨
그룹을 큰 볼륨 그룹으로 변환합니다.
2. 볼륨 그룹에 대한 LVM 사용 불가능 블록 재할당을 끄려면 다음 명령을 입력하십시오.
chvg -b ny VGname
여기서 VGname은 사용자의 볼륨 그룹 이름입니다.
논리적 볼륨 암호화
IBM AIX 7.2(기술 레벨 5 포함)부터 논리적 볼륨 관리자(LVM)는 논리적 볼륨(LV) 레벨에서의 데이터 암호화를
지원합니다. 이 기능을 사용하면 저장 데이터를 암호화하여 유실되거나 도난당한 하드 디스크 드라이버로 인해
또는 부적절하게 해제된 컴퓨터로 인해 데이터가 노출되지 않도록 보호할 수 있습니다. 저장 데이터 용어는 물리
적으로 디지털 양식으로 저장되는 비활성 데이터를 말합니다.
각 LV는 고유한 키로 암호화됩니다. 물리적 볼륨으로 데이터를 기록하기 전에 논리적 볼륨 데이터가 암호화됩니
다. 이 데이터는 물리적 볼륨에서 읽을 때 복호화됩니다. 기본적으로 데이터 암호화는 논리적 볼륨에서 사용으로
설정되지 않습니다. 논리적 볼륨 레벨에서 데이터 암호화 옵션을 사용으로 설정하기 전에 볼륨 그룹 레벨에서 데
이터 암호화 옵션을 사용으로 설정해야 합니다.
hdcryptmgr 명령은 논리적 볼륨의 암호화 키, 데이터 암호화 및 데이터 복호화를 관리합니다.
논리적 볼륨 암호화를 사용으로 설정하려면 다음 단계를 완료하십시오.
1. 데이터 암호화 옵션이 사용으로 설정된 상태로 볼륨 그룹을 작성하려면 다음 명령을 실행하십시오.
mkvg -f -k y -y testvg hdisk1 hdisk2
여기서 testvg는 새 볼륨 그룹의 이름이고 hdisk1 및 hdisk2는 볼륨 그룹에 사용되는 물리적 볼륨입니
다.
2. 데이터 암호화 옵션을 사용으로 설정한 상태로 논리적 볼륨을 작성하려면 다음 명령을 실행하십시오.
mklv -k y -y testlv testvg 10
여기서 testlv는 새 논리적 볼륨의 이름이고 testvg는 논리적 볼륨을 작성해야 하는 볼륨 그룹입니다.
3. 논리적 볼륨의 1차 암호화 키를 초기화하려면 다음 명령을 실행하십시오.
hdcryptmgr authinit testlv
볼륨 그룹 전략
디스크 장애는 스토리지 시스템에서 가장 일반적인 하드웨어 장애이며 그 다음은 어댑터 및 전원 공급 장치 장애
입니다. 디스크 장애의 보호는 주로 논리적 볼륨의 구성과 관련됩니다.
어댑터와 전원 공급 장치를 장애로부터 보호하려면 특정 볼륨 그룹에 대한 특수 하드웨어 구성을 수행하십시오.
그러한 구성으로는 두 개의 어댑터, 어댑터에서 미러링되는 어댑터당 최소한 하나의 디스크 및 비쿼럼 볼륨 그룹
구성이 있습니다. 이 구성의 추가 비용은 모든 사이트나 시스템에 적절하지 않습니다. 높은(최신) 가용성을 우선
으로 여기는 경우에만 권장됩니다. 구성에 따라 높은 가용성은 최신 백업과 현재 데이터 항목 사이에서 발생하는
하드웨어 장애에 적용될 수 있습니다. 높은 가용성은 실수로 삭제된 파일에는 적용되지 않습니다.
별도의 볼륨 그룹 작성 시기
물리적 볼륨을 rootvg와 별개의 볼륨 그룹으로 구성하는 이유는 여러 가지가 있습니다.
• 안전하고 간편한 유지보수를 위해
– 운영 체제 갱신, 재설치 및 고장 복구 조작 중에 사용자 파일이 손상되지 않도록 사용자 파일 시스템을 운영
체제와 구분할 수 있기 때문에 이러한 조작이 안전합니다.
– 사용자 데이터를 복원하지 않고도 운영 체제를 갱신하거나 재설치할 수 있으므로 유지보수가 간편합니다.
예를 들어, 갱신하기 전에 파일 시스템을 마운트 해제하여 사용자 정의 볼륨 그룹을 시스템에서 제거할 수 있
습니다. varyoffvg 명령을 사용하여 비활성화한 후 exportvg 명령을 사용하여 그룹을 반출하십시오. 시
스템 소프트웨어를 갱신한 후 importvg 명령을 사용하여 사용자 정의 볼륨 그룹을 다시 도입한 후 파일 시
스템을 다시 마운트할 수 있습니다.
• 다른 물리적 파티션 크기의 경우. 같은 볼륨 그룹 내의 모든 물리적 볼륨은 물리적 파티션 크기가 같아야 합니
다. 물리적 볼륨의 물리적 파티션 크기를 다르게 하려면 각 크기를 별도의 볼륨 그룹에 넣으십시오.
• 다른 쿼럼 특성이 필요한 경우. 비쿼럼 볼륨 그룹을 작성할 파일 시스템이 있는 경우 해당 데이터에 대한 별도
의 볼륨 그룹을 유지하고 다른 파일 시스템은 모두 쿼럼 아래에서 운영되는 볼륨 그룹에 그대로 있어야 합니다.
• 보안 상 예를 들어, 볼륨 그룹을 밤에 제거할 수 있습니다.
• 시스템 사이에서 물리적 볼륨을 전환하기 위해. 둘 이상의 시스템에서 액세스할 수 있는 어댑터에서 각 시스템
에 대해 별도의 볼륨 그룹을 작성할 경우 정상 조작을 인터럽트하지 않고 해당 어댑터에서 액세스할 수 있는 시
스템 간의 물리적 볼륨을 전환할 수 있습니다(varyoffvg, exportvg, importvg 및 varyonvg 명령 참조).
디스크 장애 시 고가용성
디스크 장애로부터 시스템을 보호하는 데 사용되는 기본적인 방법에는 미러링과 같은 논리적 볼륨 구성 설정이
포함됩니다.
볼륨 그룹에 대한 고려사항은 2차적인 문제이기는 하지만 볼륨 그룹당 물리적 볼륨 수와 관련될 경우에는 중대한
경제적 의미를 가지게 됩니다.
• 디폴트로 설정되는 쿼럼 구성은 디스크 쿼럼(51%)이 있는 한 볼륨 그룹을 활성 상태(연결 변환)로 유지합니다.
대부분의 경우, 디스크 장애가 발생할 경우 시스템을 보호할 수 있으려면 볼륨 그룹에 미러된 사본이 있는 적어
도 세 개 이상의 디스크가 있어야 합니다.
• 비 쿼럼 구성은 디스크에서 하나의 VGDA가 제공되는 한, 볼륨 그룹을 활성(연결 변환) 상태로 유지합니다. 이
구성을 사용할 경우, 볼륨 그룹에 미러된 사본이 있는 디스크가 두 개만 있으면 디스크 장애가 발생할 경우 디
스크를 보호할 수 있습니다.
각 볼륨 그룹에 배치할 디스크 수를 결정할 때는 데이터를 미러하는 데 사용할 여유 공간도 계획해야 합니다. 동
일한 볼륨 그룹에 있는 디스크 간에만 데이터를 미러하고 이동할 수 있습니다. 사이트에서 대형 파일 시스템을 사
용할 경우, 나중에는 데이터를 미러할 디스크 공간을 찾는 것이 힘들 수 있습니다. 논리적 볼륨 사본의 디스크 내
부 설정과 논리적 볼륨의 디스크 간 할당의 가용성에 유의하십시오.
어댑터 또는 전원 공급장치 장애 시 고가용성

어댑터 또는 전원 공급장치 장애가 발생할 경우 시스템을 보호하려면, 사용자 요구사항에 따라 다음 중 하나 이상
을 수행하십시오.
• 동일한 섀시 또는 서로 다른 섀시에 있는 두 어댑터를 사용하십시오. 서로 다른 섀시에 어댑터를 배치할 경우
한 섀시에서 전원 공급장치 장애가 발생할 경우 두 어댑터 중 하나는 보호할 수 있습니다.
• 적어도 하나 이상의 디스크가 각 어댑터에 연결된 두 개의 어댑터를 사용하십시오. 이렇게 하면 두 어댑터 중
하나(어댑터가 서로 다른 캐비닛에 있을 경우에는 전원 공급장치)에서 장애가 발생할 경우, 볼륨 그룹에 쿼럼을
유지함으로써 시스템을 보호할 수 있습니다. 이때 디스크 A(어댑터 A)의 논리적 볼륨과 디스크 B(어댑터 B)의
논리적 볼륨 간에 교차 미러링(논리적 파티션의 각 사본이 동일한 물리적 볼륨을 공유할 수 없음)이 이루어진다
고 가정합니다. 이는 어댑터 A에 연결된 디스크에 상주하는 논리적 볼륨을 어댑터 B에 상주하는 디스크에 복사
하는 동시에 어댑터 B에 연결된 디스크에 상주하는 논리적 볼륨을 어댑터 A에 상주하는 디스크에 복사함을 의
미합니다.
• 두 어댑터의 모든 디스크를 동일한 볼륨 그룹에 구성하십시오. 이렇게 하면 어댑터에 장애가 발생할 경우 또는
전원 공급장치에 장애가 발생할 경우(캐비닛이 서로 다른 경우) 적어도 한 개의 논리적 볼륨 사본은 손상되지
않습니다.
• 볼륨 그룹을 비 쿼럼 볼륨 그룹으로 작성하십시오. 이 경우 볼륨 그룹에 있는 어떤 디스크에서든 볼륨 그룹 설
명자 영역(VGDA) 하나에 액세스할 수만 있으면 볼륨 그룹이 활성 상태로 유지됩니다.
장치 관리 51
• 볼륨 그룹에 디스크가 두 개 있을 경우, 어댑터 간에 교차 미러링을 구현하십시오. 각 어댑터에서 두 개 이상의
디스크를 사용할 수 있을 경우, 이중 미러링을 구현하십시오. 이 경우, 동일한 어댑터를 사용하는 디스크와 다
른 어댑터를 사용하는 다른 디스크에 각각 하나씩 미러된 사본을 작성합니다.
관련 개념
볼륨 그룹을 비쿼럼 상태로 변환
볼륨 그룹을 비쿼럼 상태로 변경하여 쿼럼이 없는 경우에도 데이터를 계속해서 사용할 수 있게 만들 수 있습니다.
논리적 볼륨 전략
여기에서 설명하는 정책을 사용하면 사용자 사이트에 적합한 가용성, 성능 및 비용이 보장되는 논리적 볼륨 사용
전략을 세울 수 있습니다.
가용성은 연관된 디스크에서 장애가 발생하거나 디스크에 액세스할 수 없는 경우에도 데이터에 액세스할 수 있
는 상태를 말합니다. 정상적인 시스템 작동 중 작성되어 별도의 디스크 및 어댑터에 유지되는 데이터 사본을 통해
데이터에 액세스할 수 있습니다. 미러링과 같은 기술을 활용하고 핫 스패어 디스크를 사용하면 데이터의 가용성
을 보장할 수 있습니다.
성능은 데이터에 액세스하는 평균 속도입니다. 기록 검증 및 미러링과 같은 정책을 사용할 경우, 가용성은 향상되
지만 시스템 처리 로드가 늘어나 성능이 저하됩니다. 미러링을 사용하면 논리적 볼륨의 크기가 두 배 또는 세 배
로 늘어납니다. 일반적으로 가용성을 높이면 성능이 저하됩니다. 디스크 스트라이핑으로 성능을 높일 수 있습니
다. 디스크 스트라이핑은 미러링과 함께 허용됩니다. 디스크의 일부 논리적 파티션에 시스템 성능을 눈에 띄게 저
하시키는 너무 많은 디스크 입출력이 있는 경우 발생하는 핫 스팟 문제점을 발견하고 치료할 수 있습니다.
디스크 및 디스크 간 데이터 할당을 제어하면 최상의 성능으로 실행되도록 스토리지 시스템을 조정할 수 있습니
다. 스토리지 시스템 성능을 최대화하는 방법에 대한 자세한 정보는 성능 관리를 참조하십시오.
다음 절의 내용을 참조하여 성능, 가용성 및 비용 중에서 어느 것 하나를 개선하거나 그렇지 않았을 때 다른 요소
에 미치는 장점과 단점을 평가하십시오. 대개 가용성이 높아지면 성능이 저하되고 성능이 개선되면 가용성이 떨
어집니다. 미러링은 성능을 높일 수 있지만 LVM은 Reads를 위해 가장 한가한 디스크에서 사본을 선택합니다.
주: 실수로 삭제되거나 소프트웨어 문제로 인해 유실되어 개별 파일이 유실되는 것은 미러링을 통해
보호할 수 없습니다. 이러한 파일은 일반 테이프 또는 디스크 백업에서만 복원할 수 있습니다.
미러링 또는 스트라이핑 요구사항

논리적 볼륨에 저장된 데이터가 미러링으로 인해 야기되는 처리와 디스크 공간을 투자할 만큼 중요한지 결정하
십시오. 성능의 영향을 받기 쉬운 대형 순차적 액세스 파일 시스템을 사용할 경우, 디스크 스트라이핑을 고려해볼
수 있습니다.
성능과 미러링이 항상 상반되는 것은 아닙니다. 논리적 파티션의 서로 다른 인스턴스(사본)가 서로 다른 물리적

볼륨에 있으며 서로 다른 어댑터에 연결되어 있을 경우, LVM이 사용량이 가장 적은 디스크의 사본을 읽어서 읽기
성능을 향상시킬 수 있습니다. 디스크가 서로 다른 어댑터에 연결되어 있지 않을 경우 모든 사본을 갱신해야 하므
로 읽기 성능이 항상 동일하게 저하됩니다. 즉, 한 번의 읽기 작업에서 한 개의 사본만 읽으면 됩니다.
AIX LVM은 다음 RAID 옵션을 지원합니다.
표 3. 논리적 볼륨 관리자의 RAID 지원

항목 설명
RAID 0 스트라이핑
RAID 1 미러링
RAID 10 또는 0+1 미러링 및 스트라이핑
미러링이 스토리지 시스템의 가용성을 개선하기는 하지만 기존의 테이프 백업 배열을 대체할 수는 없습니다.
rootvg를 미러할 수 있습니다. 하지만 rootvg를 미러할 경우에는 별도의 덤프 논리적 볼륨을 작성하십시오. 미러
된 논리적 볼륨에 덤프할 경우 일치하지 않는 덤프가 생성될 수 있습니다. 또한 디폴트 덤프 장치는 1차 페이징 논
리적 볼륨이므로, 페이징 논리적 볼륨을 미러할 경우에는 별도의 덤프 논리적 볼륨을 작성하십시오.
일반적으로 논리적 파티션의 데이터가 갱신될 때마다 해당 논리적 파티션이 포함된 모든 물리적 파티션이 자동
으로 갱신됩니다. 하지만 시스템 장애로 인해 또는 갱신 당시에 물리적 볼륨이 사용 불가능한 상태여서 물리적 파
티션이 효력이 상실될 수 있습니다(더 이상 최신 데이터를 포함하지 않는 상태). LVM은 최신 물리적 파티션의 현
재 데이터를 효력이 상실된 파티션에 복사하여 효력이 상실된 파티션을 일치하는 상태로 갱신할 수 있습니다. 이
러한 프로세스를 미러 동기화라고 합니다. 시스템이 재시작될 때, 물리적 볼륨이 다시 온라인 상태가 될 때 또는
사용자가 syncvg 명령을 실행할 때 갱신이 수행될 수 있습니다.
부트 논리적 볼륨의 물리적 파티션 구성에 영향을 주는 변경을 수행하려면 변경 후 bosboot 명령을 실행해야 합
니다. 즉, 부트 논리적 볼륨의 미러링 변경과 같은 조치를 수행하려면 bosboot 명령을 실행해야 합니다.
디스크에 미러 쓰기에 대한 스케줄링 정책

물리적 사본이 하나뿐인 데이터에 대해서는 LVDD(logical volume device driver)가 논리적 읽기 또는 쓰기 요청
주소를 실제 주소로 변환하고 해당되는 물리적 장치 드라이버를 호출하여 요청을 서비스합니다. 이와 같은 단일
사본 또는 비미러 정책은 쓰기 요청에 대해 사용 불가능 블록 재할당을 처리하고 모든 읽기 오류를 호출 프로세스
로 리턴합니다.
미러링된 논리적 볼륨을 사용할 경우 복수 사본이 있는 논리적 볼륨에 대해 다음과 같은 디스크에 쓰기 스케줄링
정책을 설정할 수 있습니다.
순차 스케줄링 정책
복수 사본 또는 미러에 대한 쓰기를 순서대로 수행합니다. 단일 논리적 파티션의 미러링된 사본을 나타내는
복수 물리적 파티션은 1차, 2차 및 3차로 지정됩니다. 순차 스케줄링에서 물리적 파티션은 순서대로 쓰여집
니다. 시스템은 다음 파티션에 대한 쓰기 조작을 시작하기 전에 하나의 물리적 파티션에 대한 쓰기 조작이 완
료될 때까지 대기합니다. 모든 미러에 대한 쓰기 조작이 모두 완료되면 쓰기 조작이 완료됩니다.
병렬 스케줄링 정책
논리적 파티션의 모든 물리적 파티션에 대한 쓰기 조작을 동시에 시작합니다. 완료하는 데 가장 오래 걸리는
물리적 파티션에 대한 쓰기 조작이 종료되면 쓰기 조작이 완료됩니다. 병렬 스케줄링 정책을 사용하여 미러
링된 논리적 볼륨을 지정하면 복수 사본을 통해 해당 논리적 볼륨에서 사용량이 가장 적은 디스크로 읽기 조
작이 보내지므로 입출력 읽기 조작 성능이 향상됩니다.
순차 읽기와 병렬로 쓰기 스케줄링 정책
논리적 파티션의 모든 물리적 파티션에 대한 쓰기 조작을 동시에 시작합니다. 항상 1차 읽기 사본이 먼저 읽
혀집니다. 읽기 조작에 실패하면 다음 사본을 읽습니다. 실패한 1차 사본은 다음 사본에서 읽기 재시도 조작
을 수행하는 동안 하드웨어 재할당을 통해 LVM에 의해 수정됩니다. 나중에 액세스할 수 있도록 사용 불가능
블록을 수정합니다.
반올림 읽기와 병렬로 쓰기 스케줄링 정책
논리적 파티션의 모든 물리적 파티션에 대한 쓰기 조작을 동시에 시작합니다. 미러링된 사본 앞/뒤에서 전환
하여 읽습니다.
사용 불가능 블록 정책
사용 불가능 블록 재할당에 볼륨 그룹을 사용할 수 있는지 여부를 나타냅니다. 기본값은 yes입니다.볼륨 그룹
의 값이 yes로 설정되면 사용 불가능 블록을 재할당할 수 있습니다. no로 설정되면 정책이 논리적 볼륨 설정
값을 재정의합니다. 값이 변경되면 모든 논리적 볼륨이 이전 설정으로 계속됩니다. 값은 요청된 입출력을 재
할당된 블록으로 보내야 하는지 여부를 나타냅니다. 값이 yes로 설정되면 볼륨 그룹에서 사용 불가능 블록
재할당이 허용되고, no로 설정되면 사용 불가능 블록 할당이 완료되지 않습니다. LVM은 하드웨어 재할당이
실패할 경우에만 소프트웨어 재할당을 수행합니다. 그렇지 않으면 LVM BBR(bad block relocation) 플래그
가 아무런 효과가 없습니다.
참고: 볼륨 그룹과 논리적 볼륨에 대한 사용 불가능 블록 정책 설정이 모두 yes로 설정되지 않으면 사용 불가
능 블록 재할당을 사용할 수 없습니다.
논리적 볼륨에 대한 미러 쓰기 일관성 정책

MWC(미러 쓰기 일관성)가 켜져 있으면, 시스템이나 볼륨 그룹이 적절하게 종료되지 않을 경우 일치하지 않은 상
태가 될 수도 있는 논리적 파티션이 식별됩니다. 볼륨 그룹이 다시 온라인으로 연결 변환되면 논리적 파티션이 일
치하도록 만들기 위해 이 정보가 사용됩니다. 이를 활성 MWC라고 합니다.
논리적 볼륨이 활성 MWC를 사용하고 있을 경우, 대상 물리적 볼륨에서 MWC 캐시 블록이 갱신될 수 있을 때까지
이 논리적 볼륨에 대한 요청이 스케줄링 계층 내에 보류됩니다. MWC 캐시 블록이 갱신되면 물리적 데이터 쓰기
작업으로 요청이 계속됩니다. 쓰기가 계속되기 전에, 데이터가 실제로 상주하는 디스크에만 이러한 MWC 캐시
블록이 쓰여야 합니다.
장치 관리 53
활성 MWC가 사용 중일 경우, 시스템 성능이 저하될 수 있습니다. 논리적 트랙 그룹(LTG)이 활성인 쓰기 요청의
로깅이나 저널링의 오버헤드에 의해 부작용이 초래됩니다. 볼륨 그룹에 허용되는 LTG 크기는 128K, 256K,
512K, 1024K, 2MB, 4MB, 8MB 및 16MB입니다.
참고: LTG 크기를 128K 이상으로 지정하려면 볼륨 그룹에 포함된 디스크가 해당 디스크의 전략 루틴에서 이러
한 크기의 입출력 요청을 지원해야 합니다. LTG는 논리적 볼륨 내에 포함된, 연속된 블록이며 LTG 크기를 기준으
로 정렬됩니다. 이 오버헤드는 미러된 쓰기에서만 발생합니다.
모든 미러에 대한 쓰기가 완료되기 전에 시스템 또는 볼륨 그룹이 고장난 경우에만 미러 간의 데이터 일관성을 보
장하면 됩니다. 볼륨 그룹의 모든 논리적 볼륨은 MWC 로그를 공유합니다. MWC 로그는 각 디스크의 외부 끝에
유지됩니다. 논리적 볼륨이 디스크의 MWC 로그와 가까이 있도록, 활성 MWC를 사용하는 논리적 볼륨을 디스크
의 외부 끝에 배치하십시오.
MWC가 수동으로 설정된 경우, 논리적 볼륨이 열렸음을 볼륨 그룹이 로그합니다. 고장 후 볼륨 그룹이 연결 변환
될 때, 논리적 볼륨의 자동 강제 동기화가 시작됩니다. 현재 읽고 있는 블록을 논리적 볼륨의 다른 미러로 전파하
는 읽기 복구 정책의 사본을 사용하여, 강제 동기화가 진행되는 동안 일관성이 유지됩니다. 이 정책은 BIG 볼륨
그룹 유형에만 지원됩니다.
MWC가 꺼져 있을 경우, 시스템 또는 볼륨 그룹에서 고장이 발생하면 미러 논리적 볼륨의 미러가 일치하지 않는
상태가 될 수 있습니다. 미러 일관성을 자동으로 보호하는 기능은 없습니다. 고장 발생 시 진행 중이었던 쓰기 작
업의 결과로, 다음에 볼륨 그룹이 연결 변환될 때 미러에 일치하지 않는 데이터가 남아 있을 수 있습니다. 고장 후,
MWC가 꺼진 상태로 미러된 논리적 볼륨에 대해서는 논리적 볼륨 내의 데이터가 사용되기 전에 강제 동기화를
수행해야 합니다. 예를 들면, 다음과 같습니다.
syncvg -f -l LTVname
단, 페이징 공간과 같이 논리적 볼륨이 열려 있는 동안에만 그 내용이 유효한 논리적 볼륨에 대해서는 강제 동기
화를 수행하지 않습니다.
쓰기의 관점에서 보면, 미러 논리적 볼륨은 미러되지 않은 논리적 볼륨과 동일합니다. 쓰기 요청으로 LVM이 완전
하게 종료되면, LVM 아래에 있는 모든 드라이브에 데이터가 쓰인 것입니다. LVM이 쓰기에 대해 iodone을 실행
할 때까지 쓰기의 결과가 알려지지 않습니다. 이 작업이 완료된 후에는 고장 후 복구가 필요하지 않습니다. 시스
템 고장 당시 완료되지 않은(iodone) 쓰기 진행 중이었던 모든 블록은 해당 MWC 설정 또는 블록이 미러되었는
지 여부에 관계없이 확인 및 다시 쓰기 작업이 수행되어야 합니다.
미러된 논리적 볼륨은 미러되지 않은 논리적 볼륨과 동일하므로 최신 데이터라는 개념이 없습니다. 데이터 유효
성을 고려하는 모든 애플리케이션은 논리적 볼륨이 미러되었는지 여부에 관계없이, 볼륨 그룹 또는 시스템이 고
장나기 전에 완료되지 않았으며 진행 중이었던 쓰기의 데이터가 유효한지를 결정해야 합니다.
활성 및 수동 MWC는 고장이 발생한 후 하나의 미러를 선택하여 해당 데이터를 다른 미러에 전파함으로써 볼륨
그룹이 다시 온라인 상태로 연결 변환될 경우에만 미러가 서로 일치하게 만듭니다. 이러한 MWC 정책은 최신 데
이터를 추적하지 않습니다. 활성 MWC는 현재 쓰고 있는 LTG만 추적하므로 최신 데이터가 모든 미러에 전파되지
않을 수도 있습니다. 수동 MWC는 고장 후 모드로 들어감으로써 미러가 서로 일치하게 만듭니다. 고장 후 데이터
의 유효성을 결정해야 하는 주체는 LVM 위에 있는 애플리케이션입니다. LVM의 관점에서 보면, 애플리케이션이
항상 고장이 발생한 시점부터 진행 중인 모든 쓰기를 재수행할 경우 이러한 쓰기가 종료되면 일치하지 않을 수도
있었던 미러가 일치하게 됩니다. 단, 고장 발생 시 진행 중이었던 것과 동일한 블록이 고장 발생 후 쓰여져야 합니
다.
참고: JFS 로그 또는 파일 시스템이 포함된 미러 논리적 볼륨은 고장 발생 후 강제 동기화를 통해 또는 MWC를 켜
거나 수동 MWC를 켬으로써 사용되기 전에 동기화되어야 합니다.
디스크 간 할당 정책
디스크 간 할당 정책은 논리적 볼륨의 물리적 파티션이 있는 디스크의 수를 지정합니다.
논리적 볼륨에 대한 물리적 파티션은 단일 디스크에 있거나 볼륨 그룹의 모든 디스크에 분산되어 있을 수 있습니
다. mklv 및 chlv 명령과 함께 다음 옵션을 사용하여 디스크 간 정책을 결정할 수 있습니다.
• 범위 옵션은 논리적 볼륨의 단일 물리적 사본에 사용되는 디스크 수를 결정합니다.
• 엄격성 옵션은 두 개 이상의 사본이 동일한 물리적 볼륨을 사용해야 할 경우, mklv 작업의 성공 여부를 결정합
니다.
• 초강력 엄격성 옵션은 한 미러의 할당된 파티션이 다른 미러의 파티션과 물리적 볼륨을 공유할 수 없도록 지정
합니다.
• 스트라이프된 논리적 볼륨에만 최대 범위와 초강력 엄격성 디스크 간 정책을 사용할 수 있습니다.
논리적 볼륨의 단일 사본에 대한 디스크 간 설정

최소 디스크 간 설정(Range = minimum)을 선택할 경우, 가용성을 높이기 위해, 논리적 볼륨에 지정된 물리적
파티션이 단일 디스크에 배치됩니다. 최대 디스크 간 설정(Range = maximum)을 선택할 경우, 성능을 개선하
기 위해, 물리적 파티션이 여러 개의 디스크에 배치됩니다.
미러되지 않은 논리적 볼륨에는 최소 설정을 사용하여 가용성(하드웨어 장애 발생 시 데이터에 대한 액세스)을
극대화하십시오. 최소 설정은 가능하면 이 논리적 볼륨의 모든 원래 물리적 파티션이 하나의 물리적 볼륨에 포함
되다는 것을 나타냅니다. 할당 프로그램에서 두 개 이상의 물리적 볼륨을 사용해야 할 경우, 다른 매개변수에 지
정된 사항은 그대로 유지하면서 최소한의 물리적 볼륨을 사용합니다.
물리적 볼륨을 최소한으로 사용하면 디스크 장애 발생 시 데이터가 손실될 위험을 줄일 수 있습니다. 단일 물리적
사본에 사용된 물리적 볼륨이 늘어날수록 이와 같은 위험도 높아집니다. 4개의 물리적 볼륨에 분산된 미러되지
않은 논리적 볼륨의 경우 하나의 물리적 볼륨에 포함된 논리적 볼륨에 비해 하나의 물리적 볼륨에서 장애가 발생
할 경우 데이터가 손실될 위험이 4배나 높습니다.
다음 그림은 최소 디스크 간 할당 정책을 보여 줍니다.
그림 4. 최소 디스크 간 할당 정책
이 그림에서는 세 개의 디스크를 보여 줍니다. 한 디스크에는 세 개의 물리적 파티션이 포함되어 있고 나머지 두

디스크에는 물리적 파티션이 포함되어 있지 않습니다.
최대 설정은 다른 제한조건을 고려하여 논리적 볼륨의 물리적 파티션을 가능한 한 많은 물리적 볼륨에 균등하게
분산시킵니다. 여러 개의 디스크로 물리적 파티션을 분산하면 논리적 볼륨에 대한 평균 액세스 시간이 줄어들므
로 이는 성능을 고려한 옵션이라고 할 수 있습니다. 가용성을 개선하기 위해, 최대 설정은 미러 논리적 볼륨에만
사용됩니다.
다음 그림은 최대 디스크 간 할당 정책을 보여 줍니다.
장치 관리 55
그림 5. 최대 디스크 간 할당 정책
다음 그림은 각각 물리적 파티션을 하나씩 포함하고 있는 세 개의 디스크를 보여 줍니다.

기존의 논리적 볼륨을 확장하거나 복사할 때도 이러한 정의를 적용할 수 있습니다. 새 물리적 파티션을 할당할지
여부는 현재의 할당 정책 및 기존에 사용된 물리적 파티션의 위치에 따라 결정됩니다.
관련 개념
논리적 볼륨 사본에 대한 디스크 간 설정
디스크에 논리적 볼륨의 사본을 하나만 할당하는 작업은 매우 단순합니다.
논리적 볼륨 사본에 대한 디스크 간 설정

디스크에 논리적 볼륨의 사본을 하나만 할당하는 작업은 매우 단순합니다.
미러 사본을 작성할 경우 할당 작업이 다소 복잡합니다. 다음 그림은 논리적 볼륨의 첫 번째 인스턴스에 대한 최
소, 최대 및 디스크 간(범위) 설정과 함께 미러 논리적 볼륨 사본에 사용할 수 있는 엄격성 설정을 보여 줍니다.
예를 들어, 논리적 볼륨의 미러 사본이 있을 경우, 최소 설정을 사용하면 논리적 볼륨의 첫 번째 인스턴스가 포함
된 물리적 파티션이 단일 물리적 볼륨에 할당됩니다(가능한 경우). 그런 다음 엄격성 옵션의 설정에 따라서 동일
한 또는 다른 물리적 볼륨에 추가 사본이 할당됩니다. 다시 말해, 이 알고리즘은 엄격성 옵션과 같은 다른 매개변
수에 따르는 제한조건 내에서, 가능한 한 최소 개수의 물리적 볼륨을 사용하여 모든 물리적 파티션을 보유합니다.
Strict = y 설정은 논리적 파티션의 각 사본이 서로 다른 물리적 볼륨에 배치된다는 것을 의미합니다.
Strict = n 설정은 이들 사본이 서로 다른 물리적 볼륨으로 제한되지 않는다는 것을 의미합니다. 이에 비해
Super Strict 옵션은 한 미러의 물리적 파티션이 동일한 논리적 볼륨에 대한 다른 미러의 물리적 파티션과 동
일한 디스크에 배치되는 것을 허용하지 않습니다.
참고: 볼륨 그룹의 물리적 볼륨의 수가 사용자가 선택한 논리적 파티션당 사본 수보다 적으면 Strict을 n으로 설
정하십시오. Strict이 y로 설정되어 있을 경우, 논리적 볼륨을 작성하려고 하면 오류 메시지가 리턴됩니다.
다음 그림은 엄격성 설정값이 각각 다른 최소 디스크 간 할당 정책을 보여 줍니다.
그림 6. 최소 디스크 간 정책/엄격성
다음 그림은 엄격성 설정값이 각각 다른 최대 디스크 간 할당 정책을 보여 줍니다.
장치 관리 57
그림 7. 최대 디스크 간 정책/엄격성
관련 개념
논리적 볼륨의 단일 사본에 대한 디스크 간 설정
최소 디스크 간 설정(Range = minimum)을 선택할 경우, 가용성을 높이기 위해, 논리적 볼륨에 지정된 물리적
파티션이 단일 디스크에 배치됩니다. 최대 디스크 간 설정(Range = maximum)을 선택할 경우, 성능을 개선하
기 위해, 물리적 파티션이 여러 개의 디스크에 배치됩니다.
각 논리적 볼륨에 대한 디스크 간 할당 정책

어떤 디스크 간 할당 정책을 선택하느냐는 물리적 파티션이 배치될 수 있는 디스크의 다섯 영역을 기준으로 결정
합니다.
물리적 파티션이 물리적 볼륨의 중심에 가까이 있을수록 평균 탐색 시간도 짧아집니다. 이는 볼륨의 중심이야말
로 디스크의 어떤 부분으로부터도 평균 탐색 거리가 가장 짧기 때문입니다.
파일 시스템 로그는 운영 체제에서 자주 사용되는 것이므로 물리적 볼륨의 중심에 할당하기에 적합합니다. 반대
로 부트 논리적 볼륨은 거의 사용되지 않으므로 물리적 볼륨의 중심이나 끝에 할당됩니다.
일반적인 규칙은 다음과 같습니다. 항상 또는 중요한 애플리케이션을 실행하는 동안 입출력이 많을수록 논리적
볼륨의 물리적 파티션이 물리적 볼륨의 중심에 가까이 할당되어야 합니다.
이 규칙에는 한 가지 예외가 있습니다. MWC(미러 쓰기 일관성)가 On으로 설정된, 미러 논리적 볼륨은 외부 끝에
배치되는데 이는 시스템에서 바로 이 외부 끝에 MWC 데이터를 쓰기 때문입니다. 미러링이 적용되지 않을 경우,
MWC가 적용되지 않으므로 성능에 영향을 주지 않습니다.
물리적 파티션이 배치될 수 있는 다섯 영역은 다음과 같습니다.
1. 외부 끝
2. 내부 끝
3. 외부 중앙
4. 내부 중앙
5. 중앙
끝 파티션은 평균 탐색 시간이 가장 느립니다. 이로 인해 이 파티션을 사용하는 애플리케이션의 응답 시간이 길어
집니다. 중앙 파티션은 평균 탐색 시간이 가장 빠릅니다. 이로 인해 이 파티션을 사용하는 애플리케이션의 응답
시간이 가장 짧습니다. 하지만 물리적 볼륨의 다른 영역보다 중앙에 배치되는 파티션 수가 적습니다.
할당 정책 결합
호환되지 않는 디스크 간(inter-disk) 및 디스크 내(intra-disk) 정책을 선택할 경우, 예기치 못한 결과가 발생할 수
도 있습니다.
시스템에서는 한 정책이 다른 정책보다 우선 적용되도록 함으로써 물리적 파티션을 지정합니다. 예를 들어, 디스
크 내(intra-disk) 정책으로 center를 선택하고, 디스크 간(inter-disk) 정책으로 minimum을 선택할 경우, 디스크
내(intra-disk) 정책이 우선 적용됩니다. 시스템에서는 가능하면 논리적 볼륨에 대한 모든 파티션을 한 디스크에
배치하며, 파티션이 모두 center 영역에 맞지 않더라도 이렇게 합니다. 따라서 정책을 구현하려면 먼저 특정 정책
을 선택할 경우 이들이 어떻게 상호작용 하는지를 정확하게 이해하고 있어야 합니다.
정확한 할당을 위해 맵 파일 사용
디스크 간 및 디스크 내 정책이 제공하는 디폴트 옵션이 사용자의 필요를 해결하기에 충분하지 않을 경우, 맵 파
일을 작성하여 논리적 볼륨의 물리적 파티션의 위치와 정확한 순서를 지정하는 방법을 고려해 보십시오.
SMIT 또는 mklv -m 명령을 사용하여 맵 파일을 작성할 수 있습니다.
예를 들어, rootvg의 hdisk1에서 파티션 1-3, 41-45, 50-60 파티션에 10개의 파티션으로 구성된 lv06이라는 논
리적 볼륨을 작성하려면 명령행에서 다음 절차를 수행하십시오.
1. 사용할 물리적 파티션을 할당에 사용할 수 있는지 확인하려면 다음을 입력하십시오.
lspv -p hdisk1
2. 다음 내용이 포함된 /tmp/mymap1과 같은 파일을 작성하십시오.
hdisk1:1-3
hdisk1:41-45
hdisk1:50-60
mklv 명령은 맵 파일에 물리적 파티션이 나오는 순서대로 물리적 파티션을 할당합니다. mklv 명령으로 지정
한 논리적 볼륨 전체를 할당하려면 맵 파일에 충분한 물리적 파티션이 있는지 확인하십시오. 필요한 것보다
많이 나열할 수 있습니다.
3. 명령을 입력하십시오.
mklv -t jfs -y lv06 -m /tmp/mymap1 rootvg 10
스트라이프된 논리적 볼륨 전략 개발
스트라이프된 논리적 볼륨은 액세스 빈도가 높고 성능에 많은 영향을 받는 대규모 순차 파일 시스템에 사용됩니
다. 스트라이핑은 성능을 개선하기 위한 기능입니다.
참고: 덤프 공간이나 부트 논리적 볼륨은 스트라이프할 수 없습니다. 부트 논리적 볼륨은 연속적인 물리적 파티션
이어야 합니다.
hdisk1, hdisk2 및 hdisk3에 걸쳐서 16KB의 스트라이프 크기(배열에서 스트라이프 크기에 디스크 수를 곱하면
스트라이프 크기와 같습니다)가 있는 VGName에서 lv07이라는 12-파티션 스트라이프된 논리적 볼륨을 작성하
려면 다음을 입력하십시오.
장치 관리 59
mklv -y lv07 -S 16K VGName 12 hdisk1 hdisk2 hdisk3
VGName 내의 세 개의 디스크에 걸쳐서 8KB의 스트라이프 크기가 있는 VGName에서 lv08이라는 12파티션 스

트라이프된 논리적 볼륨을 작성하려면 다음을 입력하십시오.
mklv -y lv08 -S 8K -u 3 VGName 12
디스크 스트라이핑을 사용하여 성능을 개선하는 방법에 대한 자세한 정보는 성능 관리의 내용을 참조하십시오.
기록 검증 정책
기록 검증 옵션을 사용하면 즉시 추적 읽기 조작이 모든 쓰기 조작을 검증하여 쓰기에 성공했는지 확인합니다.
쓰기 조작에 실패하면 오류 메시지를 받습니다. 이 정책은 가용성을 향상시키지만 읽기에 추가 시간이 필요하기
때문에 성능이 저하됩니다. mklv 명령을 사용하거나 나중에 chlv 명령으로 변경하여 작성할 때 논리적 볼륨에
기록 검증 정책의 사용을 지정할 수 있습니다.
핫 스패어 디스크 정책
디스크를 미러링된 논리적 볼륨이 있는 볼륨 그룹의 핫 스패어 디스크로서 지정할 수 있습니다.
핫 스패어 디스크로 사용할 디스크를 지정할 때, 디스크 장애가 발생하기 시작할 때 사용할 정책과 동기화 특성을
지정할 수 있습니다.
볼륨 그룹에 물리적 볼륨을 추가하여 핫 스패어 디스크로 표시할 경우, 이 디스크의 용량은 적어도 볼륨 그룹에
이미 있는 가장 작은 디스크의 용량만큼은 되어야 합니다. 이 기능이 구현된 경우, MWC(Mirror Write
Consistency) 쓰기 실패로 물리적 볼륨이 없는 것으로 나타나면 핫 스패어 디스크로 데이터가 이주됩니다.
핫 스패어 디스크 지원을 사용하기 위한 명령인, chvg 및 chpv는 다음 구문에 표시된 대로 사용자의 사이트에서
기능을 구현하는 데 있어 몇몇 옵션을 제공합니다.
chvg -hhotsparepolicy -ssyncpolicy VolumeGroup
여기서 hotsparepolicy는 다음 정책 중 디스크 장애가 발생할 경우 사용할 정책을 결정합니다.

y
장애가 발생한 디스크의 파티션을 자동으로 하나의 스패어 디스크로 이주합니다. 핫 스패어 디스크 풀에서,
장애가 발생한 디스크를 대체할 만한 디스크 중 가장 작은 디스크가 사용됩니다.
Y
장애가 발생한 디스크의 파티션을 자동으로 이주하지만, 핫 스패어 디스크 풀 전체를 사용할 수도 있습니다.
n
자동으로 이주하지 않습니다(디폴트).
r
이 볼륨 그룹의 핫 스패어 디스크 풀에서 모든 디스크를 제거합니다.
syncpolicy 인수는 효력이 상실된 파티션을 자동으로 동기화할지 여부를 결정합니다.
y
효력이 상실된 파티션을 자동으로 동기화하려고 시도합니다.
n
효력이 상실된 파티션을 자동으로 동기화하려고 시도하지 않습니다. 이 옵션이 디폴트입니다.
VolumeGroup 인수는 연관된, 미러된 볼륨 그룹의 이름을 지정합니다.
논리적 볼륨의 핫 스팟 관리
논리적 볼륨에서 핫 스팟 문제점을 식별하고 시스템을 중단하지 않고 이러한 문제점을 해결할 수 있습니다.
핫 스팟 문제는 디스크의 논리적 파티션 중 일부에 시스템 성능이 눈에 띄게 저하될 정도로 디스크 입출력이 많은
경우에 발생합니다.
이 문제를 해결하려면 무엇보다도 문제를 식별해야 합니다. 디폴트로, 시스템에서는 논리적 볼륨 사용에 대한 통
계를 수집하지 않습니다. 이러한 통계가 수집되도록 설정한 후, lvmstat 명령을 처음 입력하면 이전의 시스템
재부트 이후에 수집된 계수기 값이 표시됩니다. 이후부터는 lvmstat 명령을 입력할 때마다 이전에 lvmstat
명령이 실행된 이후 달라진 통계가 표시됩니다.
lvmstat 명령의 출력을 해석하면 트래픽이 가장 많은 논리적 파티션을 식별할 수 있습니다. 물리적 디스크를 많
이 사용하는 논리적 파티션이 여러 개 있는데 사용 가능한 디스크로 이들을 고르게 분산하려는 경우,
migratelp 명령을 사용하여 이러한 논리적 파티션을 다른 물리적 디스크로 이동할 수 있습니다.
다음 예제에서는 통계 수집 기능이 사용 가능하며 기준 통계를 수집하기 위해 lvmstat 명령이 반복해서 사용됩
니다.
# lvmstat -v rootvg -e
# lvmstat -v rootvg -C
# lvmstat -v rootvg
출력은 다음과 유사합니다.

Logical Volume iocnt Kb_read Kb_wrtn Kbps
hd8 4 0 16 0.00
paging01 0 0 0 0.00
lv01 0 0 0 0.00
hd1 0 0 0 0.00
hd3 0 0 0 0.00
hd9var 0 0 0 0.00
hd2 0 0 0 0.00
hd4 0 0 0 0.00
hd6 0 0 0 0.00
hd5 0 0 0 0.00
위의 출력은 모든 계수기가 0으로 재설정되었음을 보여 줍니다. 다음 예제에서는 /unix 디렉토리에서 /tmp 디

렉토리로 데이터가 처음 복사됩니다. lvmstat 명령 출력은 rootvg의 활동을 반영합니다.
# cp -p /unix /tmp
# lvmstat -v rootvg
Logical Volume iocnt Kb_read Kb_wrtn Kbps

hd3 296 0 6916 0.04
hd8 47 0 188 0.00
hd4 29 0 128 0.00
hd2 16 0 72 0.00
paging01 0 0 0 0.00
lv01 0 0 0 0.00
hd1 0 0 0 0.00
hd9var 0 0 0 0.00
hd6 0 0 0 0.00
hd5 0 0 0 0.00
이 출력은 /tmp 디렉토리에 마운트된 hd3 논리적 볼륨, JFS 로그 논리적 볼륨인 hd8, /(루트)인 hd4, /usr 디
렉토리인 hd2 및 /var 디렉토리인 hd9var에서 이루어지는 활동을 보여 줍니다. 다음 출력은 hd3 및 hd2에 대
한 세부사항을 제공합니다.
# lvmstat -l hd3
Log_part mirror# iocnt Kb_read Kb_wrtn Kbps

1 1 299 0 6896 0.04
3 1 4 0 52 0.00
2 1 0 0 0 0.00
4 1 0 0 0 0.00
# lvmstat -l hd2
Log_part mirror# iocnt Kb_read Kb_wrtn Kbps
2 1 9 0 52 0.00
3 1 9 0 36 0.00
7 1 9 0 36 0.00
4 1 4 0 16 0.00
9 1 1 0 4 0.00
14 1 1 0 4 0.00
1 1 0 0 0 0.00
볼륨 그룹에 대한 출력은 논리적 볼륨의 모든 입출력 활동에 대한 요약을 제공합니다. 이 정보는 입출력 요청 수
(iocnt), 읽고 쓴 킬로바이트 수(각각 Kb_read와 Kb_wrtn), KB/s 단위로 표시되는 전송된 데이터(Kbps)로
나뉩니다. 논리적 볼륨에 대한 정보를 요청할 경우, 이와 동일한 정보를 각 논리적 파티션별로 별도로 받게 됩니
장치 관리 61
다. 미러된 논리적 볼륨이 있는 경우, 각 미러 볼륨에 대한 통계를 받습니다. 앞의 샘플 출력에서는 활동이 없는 논
리적 파티션에 대한 몇 행이 생략되었습니다. 출력은 항상 iocnt 열에 내림차순으로 분류됩니다.
migratelp 명령은 논리적 볼륨의 이름, 논리적 파티션의 수(lvmstat 출력에 표시됨), 특정 미러 사본의 수(선
택적)를 매개변수로 사용합니다. 정보가 생략되면 첫 번째 미러 사본이 사용됩니다. 이동할 목표 물리적 볼륨은
반드시 지정해야 합니다. 목표 물리적 파티션 번호를 지정할 수 있습니다. 성공할 경우 출력은 다음과 유사합니
다.
# migratelp hd3/1 hdisk1/109

migratelp: Mirror copy 1 of logical partition 1 of logical volume
hd3 migrated to physical partition 109 of hdisk1.
핫 스팟 기능을 사용 가능하게 만든 후부터는 논리적 볼륨 또는 볼륨 그룹에 대해 보고 및 통계 정의, 통계 표시,

이주할 논리적 파티션 선택, 대상 물리적 파티션 지정, 변경사항 확정 전에 정보 확인 등의 작업을 수행할 수 있습
니다.
볼륨 그룹 정책 구현
사용할 볼륨 그룹 정책을 결정했으면 명령행에 lspv 명령을 입력하여 현재 구성을 분석하십시오.
표준 구성은 같은 디스크 어댑터 및 기타 지원되는 하드웨어에 연결된 복수 물리적 볼륨을 포함하는 단일 볼륨 그
룹을 제공합니다. 표준 구성에서 쿼럼 볼륨 그룹을 구성하는 디스크가 많을수록 디스크 장애 시 쿼럼이 남을 가능
성이 높습니다. 비쿼럼 그룹에서는 최소 두 개의 디스크가 볼륨 그룹으로 구성되어야 합니다. 볼륨 그룹 정책 변
경을 구현하려면 다음을 수행하십시오.
1. lspv 명령 출력을 사용하여 할당되고 사용 가능한 물리적 볼륨을 확인하십시오.
2. 하나 이상의 물리적 볼륨을 추가하여 쿼럼을 확인하십시오.
3. 볼륨 그룹을 비쿼럼 상태로 변경하십시오.
4. 필요한 경우에만 하드웨어를 재구성하여 가용성을 높이십시오. 지시사항은 시스템용 서비스 안내서를 참조
하십시오.
페이징 공간 및 가상 메모리
AIX 에서는 가상 메모리를 사용하여 시스템에서 물리적으로 사용 가능한 것보다 많은 메모리를 지정합니다.
RAM 또는 디스크의 메모리 페이지 관리는 VMM(Virtual Memory Manager)에 의해 처리됩니다. 가상 메모리 세
그먼트는 페이지라고 하는 단위로 분할됩니다. 페이징 공간은 가상 메모리에 상주하지만 현재 액세스된 상태가
아닌 정보를 저장하는 디스크 공간이 할당되어 있는 일종의 논리적 볼륨입니다. 논리적 볼륨에는 페이징과 같은
속성 유형이 있으며 일반적으로 페이징 공간 또는 스왑 공간이라고 합니다. 시스템에서 사용 가능한 RAM 양이
적은 경우 다른 활동을 위한 메모리 해제를 위해 최근 사용되지 않은 프로그램 또는 데이터가 메모리에서 페이징
공간으로 이동합니다.
페이징 공간 개념
페이징 공간은 가상 메모리에 위치지만 현재 액세스된 상태가 아닌 정보를 저장하는 디스크 공간이 할당되어 있
는 일종의 논리적 볼륨입니다.
논리적 볼륨에는 페이징과 같은 속성 유형이 있으며 일반적으로 페이징 공간 또는 스왑 공간이라고 합니다. 시스
템에서 사용 가능한 RAM 양이 적은 경우 다른 활동을 위한 메모리 해제를 위해 최근 사용되지 않은 프로그램 또
는 데이터가 메모리에서 페이징 공간으로 이동합니다.
페이징 공간 스토리지에 대해 NFS 서버를 사용하는 장치를 통해 액세스할 수 있는 다른 페이징 공간 유형을 사용
할 수 있습니다. NFS 클라이언트에서 이 페이징 공간에 액세스하려면 NFS 서버에는 작성되어 이 클라이언트로
반출되는 파일이 있어야 합니다. 파일 크기는 클라이언트에 대한 페이징 공간 크기를 나타냅니다.
필요한 페이징 공간은 시스템에서 수행되는 활동 유형에 따라 달라집니다. 페이징 공간이 부족한 경우 프로세스
는 유실되고, 페이징 공간이 모두 사용된 경우에 시스템은 패닉 상태가 될 수 있습니다. 페이징 공간 부족 조건이
발견되면 추가 페이징 공간을 정의하십시오.
논리적 볼륨 페이징 공간은 새 페이징 공간 논리적 볼륨을 만들거나 기존 페이징 공간 논리적 볼륨의 크기를 늘리
는 방법으로 정의합니다. NFS 페이징 공간의 크기를 늘리려면 서버에 대한 적절한 조치를 통해 서버에 상주하는
파일을 늘려야 합니다.
페이징을 위해 시스템에서 사용할 수 있는 총 공간은 모든 활성 페이징 공간 논리적 볼륨의 합계입니다.
페이징 공간 할당 정책
PSALLOC 환경 변수는 지연 또는 조기 중 어떤 페이징 공간 할당 알고리즘이 사용되는지를 판별합니다.
AIX 에서는 페이징 공간 할당에 두 가지 모드를 사용합니다. 기본값은 지연됩니다. PSALLOC 환경 변수 값을 변
경하여 초기 페이징 공간 할당 모드로 전환할 수 있지만 그러한 값을 변경하기 전에 고려해야 할 몇 가지 요소가
있습니다. 초기 할당 알고리즘을 사용하는 경우 사용 가능한 페이징 공간을 모두 사용함으로써 최악의 경우 시스
템 고장이 발생할 수 있습니다.
연기된 페이징 공간과 조기 페이징 공간 할당의 비교

운영 체제는 PSALLOC 환경 변수를 사용하여 메모리 및 페이징 공간 할당에 사용되는 메커니즘을 결정합니다.
PSALLOC 환경 변수가 설정되지 않았거나, null로 설정되었거나, early가 아닌 값으로 설정된 경우에는 시스
템은 디폴트 deferred 할당 알고리즘을 사용합니다.
deferred 할당 알고리즘은 디스크 자원을 효율적으로 사용하도록 돕고 자원 관리를 위해 스파스 할당 알고리
즘을 선호하는 애플리케이션을 지원합니다. 이 알고리즘은 메모리 요청이 생성될 때 페이징 공간을 예약하지 않
습니다. 페이징 공간의 디스크 블록 할당은 요청된 페이지를 페이징 아웃해야 할 때까지 지연됩니다. 일부 프로그
램은 대량의 가상 메모리를 할당한 다음 약간의 메모리만 사용합니다. 그러한 프로그램의 예로는 데이터 구조로
스파스 벡터 또는 행렬을 사용하는 기술 애플리케이션이 있습니다. 연기된 할당 알고리즘은 운영 체제에 있는 것
처럼 실시간의 손상된 팩 커널에 보다 효율적입니다.
이 페이징 공간은 특히 페이징이 드문 대량의 실제 메모리가 있는 시스템에서는 절대 사용되지 않을 수도 있습니
다. 지연된 알고리즘은 페이징 공간의 할당은 요청된 페이지를 페이징 아웃해야 할 때까지 지연합니다. 이로 인해
페이징 공간 할당이 낭비되지 않게 됩니다. 이 지연된 할당으로 인해 지연된 알고리즘이 시스템에서 사용 가능한
공간보다 많은 페이징 공간을 할당하려고 시도할 수 있는 경우가 결과로 나올 수 있습니다. 이 상황은 페이징 공
간의 과다 커미트라고 부릅니다.
페이징 공간이 소모되고 페이지를 페이징 아웃하기 위해 페이징 공간 디스크 블록을 할당하려고 시도하는 과다
커미트 시나리오에서는 실패가 발생합니다. 운영 체제는 페이징 공간 과다 커미트의 영향을 받은 프로세스를 종
료하여 전체 시스템 장애를 피하려고 시도합니다. 프로세스에 사용 가능한 페이징 공간이 적음을 알려주기 위해
SIGDANGER 신호가 전송됩니다. 페이징 공간 상황에서 더 심각한 상태에 도달하는 경우 SIGDANGER 신호를
수신하지 않은 선택된 프로세스에는 SIGKILL 신호가 전송됩니다.
PSALLOC 환경 변수를 사용하여 메모리를 요청한 시간에 실행 프로세스에 대한 페이징 공간을 할당하는 early
할당 알고리즘으로 전환할 수 있습니다. 요청 시 사용 가능한 페이징 공간이 충분하지 않은 경우 초기 할당 메커
니즘에서 메모리 요청이 실패합니다.
PSALLOC 환경 변수를 early로 설정하면 해당 지점의 환경에서 시작된 모든 프로그램(단, 현재 실행 중인 프로
세스는 제외)은 초기 할당 환경에서 실행됩니다. 초기 할당 환경에서 요청을 수행할 때 충분한 페이징 공간을 예
약할 수 없는 경우 malloc 서브루틴 및 brk 서브루틴과 같은 인터페이스는 실패합니다.
조기 할당 환경 모드에서 실행되는 프로세스는 낮은 페이징 공간 조건이 발생하는 경우에는 SIGKILL 신호를 보
내지 않습니다.
변경사항을 적용하려는 범위에 따라 다양한 방법으로 PSALLOC 환경 변수를 early로 변경할 수 있습니다
초기 할당 환경으로의 전환에 의해 영향을 받는 메모리 할당 인터페이스 서브루틴은 다음과 같습니다.
• malloc
• free
• calloc
• realloc
• brk
• sbrk
• shmget
• shmctl
장치 관리 63
관련 태스크
조기 할당 모드를 위해 PSALLOC 환경 변수 구성
조기 할당 모드
조기 할당 알고리즘은 메모리 할당 요청에서 요구한 만큼의 페이징 공간을 보장합니다. 그에 따라 효율적인 작업
을 위해서는 시스템 디스크에 적절한 페이징 공간을 할당해야 합니다.
사용 가능한 페이징 공간이 특정 임계치 아래로 떨어지면 새 프로세스는 시작되지 않으며 현재 실행 중인 프로세
스는 추가 메모리를 가져올 수 없습니다. 기본 지연 할당 모드에서 실행되는 모든 프로세스는 SIGKILL 신호 메커
니즘에 매우 취약하게 됩니다. 또한 운영 체제 커널에는 가끔씩 메모리 할당이 필요하므로 사용 가능한 모든 페이
징 공간을 사용하면 시스템이 고장날 수 있습니다.
전체 시스템에서 초기 할당 모드를 사용하기 전에 시스템에 대해 적절한 양의 페이징 공간을 정의하는 것이 중요
합니다. 조기 할당 모드에 필요한 페이징 공간은 거의 항상 기본 지연 할당 모드에 필요한 페이징 공간보다 큽니
다. 정의할 페이징 공간의 양은 시스템 사용 방식 및 실행하는 프로그램에 따라 다릅니다. 시스템에 대한 적절한
조화를 결정하는 유용한 시작점은 실제 메모리 양보다 4배 많게 페이징 공간을 정의하는 것입니다.
특정 애플리케이션을 조기 할당 모드에서 실행하는 경우 많은 양의 페이징 공간을 사용할 수 있습니다. 애플리케
이션이 조기 할당 모드에서 실행되는 경우 AIXwindows 서버는 현재 250MB 이상의 페이징 공간을 필요로 합니
다. 애플리케이션에 필요한 페이징 공간은 애플리케이션의 작성 방식 및 실행 방법에 따라 다릅니다.
페이징 공간 및 프로세스 메모리를 보여 주는 모든 명령 및 서브루틴은 초기 할당 모드에서 할당된 페이징 공간을
포함합니다. lsps 명령은 -s 플래그를 사용하여 초기 할당 모드에서 할당된 페이징 공간을 포함한 총 페이징 공
간 할당을 표시합니다.
페이징 공간 디폴트 크기
디폴트 페이징 공간 크기는 다음 표준에 따라 AIX 설치의 시스템 조정 단계 중에 결정됩니다.
• 페이징 공간은 64MB 미만을 사용할 수 없는 hd6를 제외하고는 16MB미만을 사용할 수 없습니다.
• 사용되는 페이징 공간은 총 디스크 공간의 20%를 넘을 수 없습니다.
• 실제 메모리가 256MB 미만인 경우 페이징 공간은 실제 메모리의 두 배입니다.
• 실제 메모리가 256MB보다 크거나 같은 경우 페이징 공간은 512MB입니다.
페이징 공간 파일, 명령 및 옵션
/etc/swapspaces 파일은 페이징 공간 및 페이징 공간의 속성을 지정합니다.
페이징 공간은 mkps 명령에 의해 작성될 때 /etc/swapspaces 파일에 추가되고, 페이징 공간은 rmps 명령에
의해 삭제될 때 /etc/swapspaces 파일에서 제거됩니다. 파일의 페이징 공간 속성은 chps -a 명령 또는
chps -c 명령에 의해 수정됩니다. 이전 형식을 사용하는 파일은 계속 지원됩니다(체크섬 크기의 속성과 스탠자
에 자동 스왑 온이 없는 경우). 페이징 공간 크기가 너무 크면 chps -d 명령을 사용하여 재부팅하지 않고 페이징
공간에서 논리적 파티션을 뺄 수 있습니다.
다음 명령이 페이징 공간을 관리하는 데 사용됩니다.
항목 설명
chps 페이징 공간의 속성을 변경합니다.
lsps 페이징 공간의 특성을 표시합니다.
mkps 추가 페이징 공간을 추가합니다. 페이징 공간 논리적 볼륨을 작성할 때 mkps 명령은 mklv 명령을
특정 옵션 세트와 함께 사용합니다. NFS 페이징 공간을 작성하기 위해 mkps 명령은 여러 옵션 세
트와 함께 mkdev 명령을 사용합니다. NFS 페이징 공간의 경우 mkps 명령에는 NFS 서버의 호스
트 이름 및 서버에서 반출되는 파일의 경로 이름이 필요합니다.
rmps 비활성 페이징 공간을 제거합니다.
swapoff 시스템을 재부트하지 않고도 하나 이상의 페이징 공간을 비활성화합니다. 페이징 공간의 정보는
다른 활성 페이징 공간 영역으로 이동합니다. 그런 다음 rmps 명령을 사용하여 비활성화된 페이징
공간을 제거할 수 있습니다.
항목 설명
swapon 페이징 공간을 활성화합니다. swapon 명령은 조기 시스템 초기화 중에 처음의 페이징 공간 장치
를 활성화하는 데 사용됩니다. 차후 초기화 단계에서 다른 장치를 사용할 수 있으면 여러 장치에서
페이징 활동이 발생하도록 swapon 명령을 사용하여 추가 페이징 공간을 활성화합니다.
모든 논리적 볼륨 페이징 공간에는 paging type 옵션이 필요합니다.

다음 옵션을 사용하여 논리적 볼륨의 페이징 성능을 최대화할 수 있습니다.
• 디스크 암 이동을 줄일 수 있도록 디스크 중간에 할당
• 각각 별도의 물리적 볼륨에서 할당된 여러 페이징 공간 사용
페이징 공간 구성
대부분의 구성 태스크는 SMIT로 수행할 수 있습니다. 페이징 공간 및 메모리 할당은 PSALLOC 환경 변수에 의해
제어됩니다.
페이징 공간 추가 및 활성화
시스템에서 페이징 공간을 사용 가능하게 만들려면 페이징 공간을 추가하여 활성화해야 합니다.
총 페이징 공간은 주로 시도 및 오류에 의해 결정됩니다. 일반적으로 사용되는 한 가지 지침은 RAM 크기를 두 배
로 하여 이 값을 페이징 공간 목표로 사용하는 것입니다.
SMIT 인터페이스를 사용하여 명령행에서 다음 단축 경로 중 하나를 입력하십시오.
• 현재 페이징 공간을 나열하려면 smit lsps를 입력하십시오.
• 페이징 공간을 추가하려면 smit mkps를 입력하십시오.
• 페이징 공간을 활성화하려면 smit swapon을 입력하십시오.
페이징 성능 개선
페이징 성능을 향상시키려면 여러 페이징 공간을 사용하고 가능하면 이러한 공간을 별도의 물리적 볼륨에 배치
하십시오.
그러나 둘 이상의 페이징 공간도 하나의 물리적 볼륨에 배치할 수 있습니다. 여러 물리적 볼륨을 사용할 수 있지
만 시스템을 완전히 숙지한 경우가 아니면 rootvg 볼륨 그룹 내에 있는 디스크만 선택하는 것이 좋습니다.
조기 할당 모드를 위해 PSALLOC 환경 변수 구성
디폴트 설정은 late입니다. 다음 예제에서는 PSALLOC 환경 변수를 early로 변경하는 다양한 방법을 보여 줍
니다. 선택하는 방법은 변경을 적용하려는 범위에 따라 다릅니다.
• 쉘 명령행에 다음 명령을 입력하십시오.
PSALLOC=early;export PSALLOC
이 명령은 조기 할당 모드에서 실행되도록 해당 쉘 세션에서 모든 후속 명령이 실행되게 합니다.

• 쉘 자원 파일(.shrc 또는 .kshrc)에 다음 명령을 추가하십시오.
PSALLOC=early;export PSALLOC
이 항목은 로그인 쉘을 제외하고 로그인 세션의 모든 프로세스가 조기 할당 모드에서 실행되도록 합니다. 이 방

법은 또한 SIGKILL 신호 메커니즘으로부터 프로세스를 보호합니다.
• 프로그램 내부에 putenv 서브루틴을 삽입하여 PSALLOC 환경 변수를 early로 설정하십시오. 이 방법을 사
용하여 조기 할당 작동이 exec 서브루틴에 대한 다음 호출에 적용됩니다.
관련 개념
연기된 페이징 공간과 조기 페이징 공간 할당의 비교
장치 관리 65
페이징 공간 변경 또는 제거
페이징 공간 변경은 SMIT로 쉽게 수행되지만 페이징 공간 제거는 보다 위험합니다.
페이징 공간의 특성 변경은 명령행에서 다음 SMIT 단축 경로를 사용하여 수행할 수 있습니다. smit chps.
페이징 공간을 제거하는 절차는 특히 제거하려는 페이징 공간이 hd6과 같이 디폴트 페이징 공간인 경우에는 좀
더 위험합니다. 디폴트 페이징 공간은 부트 시간에 시스템을 구성하는 쉘 스크립트에 의해 활성화되므로 이를 제
거하려면 특수 절차가 필요합니다. 디폴트 페이징 공간을 제거하려면 이러한 스크립트를 변경하고 새 부트 이미
지를 작성해야 합니다.
주의: 디폴트 페이징 공간을 잘못 제거하면 시스템이 재시작되지 않을 수 있습니다. 경험이 풍부한 시스
템 관리자만이 다음 절차를 수행해야 합니다.
기존 페이징 공간을 제거하려면 다음 절차를 수행하십시오.
1. 루트 권한으로 명령행에 다음 SMIT 단축 경로를 입력하여 페이징 공간을 비활성화하십시오.
smit swapoff
2. 제거할 페이징 공간이 디폴트 덤프 장치인 경우 페이징 공간을 제거하기 전에 먼저 디폴트 덤프 장치를 다른
페이징 공간 또는 논리적 볼륨으로 변경해야 합니다.
디폴트 덤프 장치를 변경하려면 다음 명령을 입력하십시오.
sysdumpdev -P -p /dev/new_dump_device
3. 명령행에 다음 단축 경로를 입력하여 페이징 공간을 제거하십시오.

smit rmps
페이징 공간 할당 모드 프로그래밍 인터페이스 사용

페이징 공간 할당 모드를 제어하는 프로그래밍 인터페이스는 PSALLOC 환경 변수를 사용합니다.
애플리케이션을 항상 원하는 모드로 실행하려면(초기 페이징 공간 할당을 사용하거나 사용하지 않음) 다음을 수
행하십시오.
1. getenv 서브루틴을 사용하여 PSALLOC 환경 변수의 현재 상태를 점검합니다.
2. PSALLOC 환경 변수 값이 애플리케이션에 필요한 값이 아닌 경우에는 setenv 서브루틴을 사용하여 환경 변
수 값을 변경하십시오.
execve 서브루틴만 PSALLOC 환경 변수의 상태를 점검하므로 애플리케이션에서 수신한 동일 매개변수 및
환경 세트를 사용하여 execve 서브루틴을 호출하십시오. 애플리케이션에서 PSALLOC 환경 변수를 다시 점
검하여 올바른 값을 발견하면 애플리케이션은 정상적으로 계속됩니다.
3. getenv 서브루틴에서 PSALLOC 환경 변수의 현재 상태가 올바른 것으로 나타나는 경우 수정할 필요가 없습
니다.
애플리케이션은 정상적으로 계속됩니다.
hd6 페이징 공간 재배치 및 감소

다른 저장 시스템 성능을 향상시키려면 사용량이 적은 다른 디스크로의 강제 페이징 및 스와핑을 수행하여 디폴
트 페이징 공간을 줄이거나 이동해야 할 수 있습니다. 디폴트 페이징을 줄이거나 이동해도 hdisk0의 디스크 공간
은 유지됩니다.
페이징 공간을 이동하거나 해당 크기를 줄이는 근본적 이유는 모두 사용량이 적은 디스크로 페이징 공간 활동을
이동하기 위함입니다. 설치 디폴트는 사용량이 많은 /(루트) 및 /usr 파일 시스템 모두 또는 일부가 포함되어 있
는 드라이브 hdisk0에 페이징 논리적 볼륨(hd6)을 작성하는 것입니다. 최소 내부 디스크 할당 정책을 선택하는
경우 모든 / 및 대량의 /usr가 hdisk0에 있음을 의미하며 페이징 공간을 사용량이 적은 디스크로 이동하면 성능
이 크게 개선될 수 있습니다. 최대 내부 디스크 할당 정책이 구현되고 / 및 /usr가 모두 여러 물리적 볼륨에 분배
된 경우에도 hdisk2(세 개의 디스크가 있음)에는 사용량이 가장 많은 파일 시스템에 속한 몇몇 논리적 파티션이
포함되어 있을 수 있습니다.
다음 절차에서는 hd6 페이징 공간을 작게 만들고, 동일한 볼륨 그룹 내에서 hd6 페이징 공간을 이동하는 방법에
대해 설명합니다.
hd6 페이징 공간을 작게 만들기
다음 프로시저에서는 chps 명령을 사용하여 기존 페이징 공간(1차 페이징 공간, 1차 및 2차 덤프 장치 포함)을
축소합니다.
chps 명령은 shrinkps 스크립트를 호출합니다. 이 스크립트는 시스템을 재부트할 수 없는 상태로 두지 않고도
페이징 공간을 안전하게 축소할 수 있습니다. 특히 이 스크립트로 다음을 수행할 수 있습니다.
1. 동일한 볼륨에 임시 페이징 공간 작성
2. 정보를 해당 임시 공간으로 이동
3. 동일 볼륨에 소형의 새 페이징 공간 작성
4. 이전 페이징 공간 제거
chps 명령을 완료하려면 임시 페이징 공간을 작성하기 위한 충분한 디스크 여유 공간(다른 논리적 볼륨으로 할
당되지 않은 공간)이 있어야 합니다. 임시 페이징 공간의 크기는 이전 페이징 공간에서 페이지 아웃된 모든 페이
지를 보유하는 데 필요한 공간과 동일합니다. 1차 페이징 공간의 최소 크기는 32MB입니다. 다른 페이징 공간의
최소 크기는 16MB입니다.
참고: 다음 프로시저에서 입출력 오류가 발생하는 경우 시스템을 즉시 종료한 다음 재부트해야 합니다.
1. 다음 명령을 입력하여 물리적 볼륨에서의 논리적 볼륨 및 파일 시스템 분배를 확인하십시오.
lspv -l hdiskX
여기서 hdiskX는 물리적 볼륨의 이름입니다.

2. 페이징 공간 크기를 축소하려면 명령행에 다음을 입력하십시오.
smit chps
참고: 1차 페이징 공간은 부트 레코드에 하드코드화됩니다. 그러므로 1차 페이징 공간은 시스템을 재시작할 경우
에 항상 활성화됩니다. chps 명령은 1차 페이징 공간을 비활성화할 수 없습니다.
작업 구성을 유지하기 위한 우선순위가 부여됩니다. 시스템 확인으로 인해 페이징 공간 축소가 즉시 거부될 수 있
습니다. 임시 페이징 공간을 작성하는 중에 오류가 발생하면 해당 프로시저가 종료되고 시스템은 원래 설정값으
로 되돌아갑니다. 다른 문제점이 발생하면 시스템 관리자의 개입이 요구되거나 즉시 재부트해야 하는 상황이 생
길 수 있습니다. 일부 오류의 경우 임시 페이징 공간이 제거되지 않을 수 있습니다. 이런 경우에는 일반적으로 시
스템 관리자의 즉각적인 주의가 요구되지 않습니다.
주의: shrinkps 스크립트 내의 swapoff 명령으로 시스템 지원 페이지 또는 사용자 지원 페이지에서
입출력 오류를 발견하는 경우 시스템 고장을 방지하려면 즉시 시스템을 종료하는 것이 좋습니다. 재부트
할 때 임시 페이징 공간이 활성화되고, 입출력 오류가 발생한 애플리케이션을 정지했다가 재시작하기 위
한 시도를 수행할 수 있습니다. 이런 시도에 성공하여 swapoff 명령으로 비활성화를 완료할 수 있으면
필요한 크기로 페이징 공간을 작성하고 임시 페이징 공간을 제거할 수 있도록 mkps, swapoff 및 rmps
명령을 사용하여 축소 절차를 수동으로 완료할 수 있습니다.
시스템을 재시작하기 전에 입출력 오류 상태에 있던 비활성화된 페이징 공간을 제거(rmps 사용)하거나
다시 활성화(chps 사용)하지 마십시오. 디스크 공간이 재사용되어 추가 문제점이 발생할 수 있습니다.
동일한 볼륨 그룹 내에서 hd6 페이징 공간 이동

hdisk0의 디폴트 페이징 공간을 동일한 볼륨 그룹 내의 다른 디스크로 이동할 때 시스템을 종료하고 재부트할 필
요가 없습니다.
루트 권한을 사용하여 다음 명령을 입력하여 디폴트(hd6) 페이징 공간을 hdisk0에서 hdisk2로 이동하십시오.
migratepv -l hd6 hdisk0 hdisk2
주의: 제거 가능한 미디어에서 부트할 때 부트 프로세스 및 루트 볼륨 그룹에 액세스하는 프로세스의 두

번째 단계를 포함하여 이름이 여러 위치에서 하드코드화되기 때문에 이름이 hd6인 페이징 공간을 rootvg
에서 다른 볼륨 그룹으로 이동하는 것은 권장되지 않습니다. 부트 프로세스의 두 번째 단계에서는 rootvg
의 페이징 공간만 활성화되므로 rootvg에 페이징 공간이 없으면 시스템 부트 성능에 심각한 영향을 줄 수
있습니다. 다른 볼륨 그룹에서 대다수의 페이징 공간을 원하는 경우에는, hd6을 가능한 작게 만든 다음
(물리적 메모리와 같은 크기) 다른 볼륨 그룹에 더 큰 페이징 공간을 만드는 것이 좋습니다.
장치 관리 67
페이징 공간 문제점 해결
페이징 공간에 대한 가장 일반적인 문제점은 할당된 공간이 부족하여 발생합니다.
총 페이징 공간은 주로 시도 및 오류에 의해 결정됩니다. 일반적으로 사용되는 한 가지 지침은 RAM 크기를 두 배
로 하여 이 값을 페이징 공간 목표로 사용하는 것입니다. 페이징 공간이 부족한 경우 프로세스는 유실되고, 페이
징 공간이 모두 사용된 경우에 시스템은 패닉 상태가 될 수 있습니다. 다음 신호 및 오류 정보를 사용하여 페이징
공간 문제점을 모니터하고 해결하거나 이러한 문제점을 방지할 수 있습니다.
운영 체제는 사용 가능한 페이징 공간 블록 수를 모니터하고 페이징 공간이 부족한 시기를 발견합니다. 사용 가능
한 페이징 공간 블록 수가 페이징 공간 경고 레벨이라고 하는 임계치 아래로 떨어지면 시스템은 모든 프로세스
(kprocs 제외)에 SIGDANGER 신호를 전송하여 이러한 상태를 알립니다. 부족 상태가 계속되고 페이징 공간 종
료 레벨이라고 하는 두 번째 임계치 아래로 떨어지면 시스템은 페이징 공간의 주 사용자지만 SIGDANGER 신호
에 대한 신호 처리기가 없는 프로세스에 SIGKILL 신호를 전송합니다. (SIGDANGER 신호에 대한 디폴트 조치는
신호를 무시하는 것입니다.) 시스템은 사용 가능한 페이징 공간 블록 수가 페이징 공간 종료 레벨 위로 올라갈 때
까지 계속해서 SIGKILL 신호를 전송합니다.
참고: low_ps_handling 매개변수가 2(vmo 명령)로 설정되고 종료할 프로세스를 찾을 수 없는 경우
(SIGDANGER 처리기 없음) 시스템은 SIGDANGER 신호에 대한 신호 처리기가 있는 최신 프로세스에 SIGKILL
프로세스를 전송합니다.
메모리를 동적으로 할당하는 프로세스는 psdanger 서브루틴으로 페이징 공간 레벨을 모니터하거나 특수 할당
루틴을 사용하여 충분한 페이징 공간을 확보할 수 있습니다. disclaim 서브루틴을 사용하여 페이징 공간 종료
레벨에 도달할 때 프로세스가 종료되지 않도록 할 수 있습니다. 이를 수행하려면 SIGDANGER 신호에 대한 신호
처리기를 정의하고 데이터 및 스택 영역과 공유 메모리 세그먼트에 할당된 메모리 및 페이징 공간 자원을 해제하
십시오.
다음과 같은 오류 메시지가 나타나면 페이징 공간을 늘리십시오.
INIT: Paging space is low!
또는
You are close to running out of paging space.
You may want to save your documents because
this program (and possibly the operating system)
could terminate without future warning when the
paging space fills up.
가상 메모리 관리자
가상 메모리 관리자(VMM)는 시스템과 해당 애플리케이션에 의해 만들어진 메모리 요청을 관리합니다.
가상 메모리 세그먼트는 페이지라는 단위로 분할되며 각 페이지는 필요할 때까지 실제 메모리(RAM)에 있거나 디
스크에 저장됩니다. AIX 에서는 가상 메모리를 사용하여 시스템에서 물리적으로 사용 가능한 것보다 많은 메모
리를 지정합니다. RAM 또는 디스크에 있는 메모리 페이지의 관리는 VMM에 의해 처리됩니다.
가상 메모리 관리자에서 실제 메모리 관리

AIX 에서 가상 메모리 세그먼트는 페이지라고 하는 4096바이트 단위로 분할됩니다. 실제 메모리는 4096바이트
페이지 프레임으로 나뉩니다.
VMM에는 다음 두 가지 주요 기능이 있습니다.
• 페이지 프레임의 할당 관리
• 현재 RAM에 없거나(페이징 공간에 저장됨) 아직 존재하지 않는 가상 메모리 페이지에 대한 참조 해석
이러한 기능을 수행하기 위해 VMM은 사용 가능한 페이지 프레임의 사용 가능 리스트를 유지관리합니다. VMM
에서는 또한 페이지 교체 알고리즘을 사용하여 해당 페이지 프레임을 사용 가능 리스트로 다시 지정할 현재 RAM
에 있는 가상 메모리를 판별합니다. 페이지 교체 알고리즘에서는 영구적 세그먼트와 작업 세그먼트, 리페이징 및
VMM 임계치의 존재 여부를 고려합니다.
가상 메모리 관리자 사용 가능 리스트

VMM은 페이지 부재를 만족시키기 위해 VMM이 사용하는 사용 가능(할당되지 않은) 페이지 프레임의 리스트를
유지합니다.
AIX 에서는 VMM이 사용 가능 리스트에 유지하는 소량의 공간을 제외하고는 항상 모든 RAM을 사용하려고 합니
다. 이러한 소량의 할당되지 않은 페이지를 유지하기 위해 VMM은 페이지 아웃과 페이지 스틸을 통해 공간을 비
워서 비워진 페이지 프레임을 사용 가능 리스트에 다시 할당합니다. 페이지 프레임이 다시 할당될 가상 메모리 페
이지는 VMM의 페이지 대체 알고리즘을 통해 선택됩니다.
가상 메모리 관리자의 영구적 메모리 세그먼트 또는 작업 메모리 세그먼트

AIX 에서는 여러 메모리 세그먼트 유형을 구분합니다. VMM을 이해하려면 작업 세그먼트와 영구적 세그먼트의
차이를 이해해야 합니다.
영구적 세그먼트는 디스크에 영구 스토리지 위치를 갖습니다. 데이터 또는 실행 가능 프로그램이 포함된 파일은
영구적 세그먼트에 맵핑됩니다. JFS 또는 JFS2 파일이 열린 상태에서 액세스되는 경우 파일 데이터는 RAM으로
복사됩니다. VMM 매개변수는 영구적 페이지에 할당된 실제 메모리 프레임이 겹쳐써지고 다른 데이터를 저장하
는 데 사용되는 시기를 제어합니다.
작업 세그먼트는 임시 세그먼트이며 프로세스에 사용되는 동안만 존재합니다. 작업 세그먼트에는 영구 디스크
스토리지 위치가 없습니다. 프로세스 스택 및 데이터 영역은 작업 세그먼트 및 공유 라이브러리 텍스트 세그먼트
에 맵핑됩니다. 작업 세그먼트 페이지를 실제 메모리에 보관할 수 없는 경우 이 페이지는 디스크 스토리지 위치를
차지해야 합니다. 이런 용도로 디스크 페이징 공간이 사용됩니다. 프로그램을 종료하면 모든 작업 페이지는 즉시
사용 가능 리스트에 다시 배치됩니다.
가상 메모리 관리자의 작업 세그먼트 및 페이징 공간

수정하고 페이징 아웃할 수 있는 RAM의 작업 페이지에 페이징 공간의 해당 슬롯이 지정됩니다.
할당된 페이징 공간은 페이지를 페이징 아웃해야 될 경우에만 사용됩니다. 그러나 페이징 공간의 할당된 페이지
는 다른 페이지에 사용할 수 없습니다. 해당 페이지가 가상 메모리에 있는 한, 특정 페이지를 위해 예약됩니다. 영
구적 페이지가 원래 있던 디스크의 같은 위치에 페이징 아웃되므로 RAM에 상주하는 영구적 페이지에 대해 페이
징 공간을 할당할 필요가 없습니다.
VMM에는 페이징 공간 할당을 위한 초기와 후기의 두 모드가 있습니다. 초기 할당 정책은 작업 페이지에 대한 메
모리 요청이 있을 때마다 페이징 공간을 예약합니다. 후기 할당 정책은 작업 페이지가 실제로 메모리 부족으로 페
이징되어 시스템의 페이징 공간 요구사항을 크게 줄일 때만 페이징 공간을 지정합니다.
가상 메모리 관리자 메모리 로드 제어 기능

프로세스에서 디스크에 있는 가상 메모리 페이지를 참조하면 페이지가 페이지 아웃되었거나 페이지가 읽혀지지
않았으므로 참조된 페이지는 페이지 인되어야 하는데 이로 인해 사용 가능한 페이지 프레임 수가 적으면 하나 이
상의 페이지가 페이지 아웃될 수 있습니다. VMM은 최근에 참조하지 않은 페이지 프레임을 제거하므로 페이지 대
체 알고리즘을 통해 나중에 참조될 가능성은 희박합니다.
페이지 대체에 성공하면 현재 모든 활성 프로세스의 메모리 페이지가 RAM에 보관되고 비활성 프로세스의 메모
리 페이지는 페이지 아웃됩니다. 그러나 RAM이 오버커밋되면 현재 실행 중인 프로세스에서 나중에 페이지를 참
조할 수 있으므로 페이지 아웃할 페이지를 선택하기 어려워집니다. 그러면 곧 참조될 페이지가 페이지 아웃되었
다가 실제로 참조될 때 다시 페이지 인될 수 있습니다. RAM이 오버커밋되면 스래싱이라는 연속 페이징 인과 페
이징 아웃이 발생할 수 있습니다. 시스템이 스래싱되면 유용한 지시사항을 실행하는 대신, 페이징 인과 페이징 아
웃에 대부분의 시간을 소비하며 활성 프로세스가 많이 진행되지 않습니다. VMM에는 시스템 스래싱을 감지하여
스래싱 조건을 정정하는 메모리 로드 제어 알고리즘이 있습니다.
파일 시스템
파일 시스템은 파일 및 디렉토리의 계층 구조(파일 트리)입니다.
이 구조 유형은 맨 위에 뿌리가 있고 밑에 가지가 있는 거꾸로 된 나무 모양입니다. 이 파일 트리는 디렉토리를 사
용하여 데이터와 프로그램을 그룹으로 구성하므로 많은 디렉토리와 파일을 한 번에 관리할 수 있습니다.
파일 시스템은 단일 논리적 볼륨에 상주합니다. 모든 파일과 디렉토리는 논리적 볼륨 내의 파일 시스템에 속합니
다. 구조가 이런 식이므로 일부 태스크는 파일 시스템 내의 각 디렉토리에서 수행하는 것보다 파일 시스템에서 수
행하는 것이 보다 효율적입니다. 예를 들어, 전체 파일 시스템을 백업, 이동 또는 보안할 수 있습니다. 스냅샷이라
는 JFS 파일 시스템 또는 JFS2 파일 시스템의 특정 시점 이미지를 만들 수 있습니다.
참고: 논리적 볼륨 하나당 최대 논리적 파티션 수는 32,512개입니다. 파일 시스템 논리적 볼륨의 특성에 대한 자
세한 정보는 chlv 명령을 참조하십시오.
장치 관리 69
mkfs(파일 시스템 작성) 명령 또는 SMIT(System Management Interface Tool)(smit 명령)로 논리적 볼륨에
파일 시스템을 작성할 수 있습니다.
파일 시스템에 액세스할 수 있으려면 디렉토리 마운트 위치에 파일 시스템이 마운트되어 있어야 합니다. 파일 시
스템이 여러 개 마운트된 경우에는 단일 파일 시스템 이미지를 나타내는 디렉토리 구조가 생성됩니다. 이 구조는
루트가 하나인 계층 구조입니다. 이 구조에는 시스템의 기본 파일 시스템과 사용자가 작성한 파일 시스템이 포함
됩니다. mount 명령을 사용하여 로컬 및 원격 파일 시스템 모두에 액세스할 수 있습니다. 그러면 사용자 시스템
에서 이 파일 시스템에 읽고 쓸 수 있게 됩니다. 대개, 파일 시스템을 마운트 하거나 마운트 해제하려면 시스템 그
룹 멤버십이 있어야 합니다. 파일 시스템이 /etc/filesystems 파일에 정의되어 있으면 자동으로 마운트할
수 있습니다. 사용자나 프로세스에서 로컬 또는 원격 파일 시스템에 액세스하고 있지 않으면, umount 명령으로
로컬 또는 원격 파일 시스템을 마운트 해제할 수 있습니다. 파일 시스템 마운트에 대한 자세한 정보는 96 페이지
의 『마운트』의 내용을 참조하십시오.
AIX 에 사용되는 파일 시스템의 기본 유형을 저널 파일 시스템(JFS)이라고 합니다. 이 파일 시스템은 데이터베이
스 저널링 기술을 사용하여 구조적 일관성을 유지보수합니다. 이 저널링 기술 사용으로 파일 시스템이 비정상적
으로 정지될 때 파일 시스템이 손상되는 것을 막아줍니다.
AIX 운영 체제는 저널 파일 시스템(JFS)과 확장 저널 파일 시스템(JFS2)을 포함하여 여러 파일 시스템 유형을 지
원합니다. 파일 시스템 유형 및 각 유형의 특성에 대한 자세한 정보는 100 페이지의 『파일 시스템 유형』의 내
용을 참조하십시오.
다음과 같은 매우 중요한 일부 시스템 태스크는 특별히 파일 시스템으로 작업해야 합니다.
• 논리적 볼륨에 파일 시스템 영역 할당
• 파일 시스템 작성
• 시스템 사용자에게 사용 가능 파일 시스템 영역 작성
• 파일 시스템 영역 사용법 모니터
• 시스템 장애 시 데이터 유실에 대비한 파일 시스템 백업
• 지속적인 상태로 파일 시스템 유지
이러한 태스크는 시스템 관리자가 실행해야 합니다.
파일 시스템 개념
파일 시스템을 관리하고 구성하기 전에 먼저 파일 트리의 기본 조직과 컨텐츠를 이해해야 합니다.
파일 트리 구성 및 컨텐츠
파일 트리는 유사한 정보가 포함된 디렉토리로 파일을 구성합니다. 이러한 구성은 디렉토리와 파일의 원격 마운
트를 가능하게 해 줍니다.
시스템 관리자는 이들 디렉토리를 빌드 블록으로 사용하여 하나 이상의 서버에서 개별 디렉토리를 마운트하는
각 클라이언트에 대해 고유한 파일 트리를 구축할 수 있습니다. 모든 정보를 로컬 위치에 보관하는 대신 원격에서
마운트함으로써 얻을 수 있는 이점은 다음과 같습니다.
• 디스크 공간 절약
• 중앙 집중화된 간편한 시스템 관리
• 보다 안전한 환경 제공
파일 트리의 특성은 다음과 같습니다.
• 동일한 하드웨어 구조의 시스템에서 공유할 수 있는 파일은 /usr 파일 시스템에 있습니다.
• 스풀 및 메일 파일과 같은 클라이언트 전용 변수 파일은 /var 파일 시스템에 있습니다.
• man 페이지와 같이 구조 독립적이며 공유 가능한 텍스트 파일은 /usr/share 디렉토리에 있습니다.
• /(루트) 파일 시스템에는 시스템 운영에 반드시 필요한 파일과 디렉토리가 있습니다. 예를 들어, 루트 파일 시
스템에는 장치 디렉토리, 시스템 시작 시 사용되는 프로그램, 파일 시스템을 루트 파일 시스템에 마운트할 수
있는 마운트 위치가 포함됩니다.
• /home 파일 시스템은 사용자의 홈 디렉토리를 위한 마운트 위치입니다.
파일 시스템 구조
파일 시스템과 디렉토리의 차이를 이해하고 있어야 합니다. 파일 시스템은 파일을 포함하도록 할당된 하드 디스
크의 한 구역입니다. 디렉토리에 파일 시스템을 마운트하여 이 구역에 액세스합니다. 파일 시스템이 마운트된 후
에는 이 구역이 일반 디렉토리와 똑같습니다.
하지만 파일 시스템과 디렉토리는 그 구조가 다르므로 각각에 포함된 데이터를 별도로 관리할 수 있습니다.
다음 그림에서 볼 수 있듯이 파일 시스템과 디렉토리는 운영 체제이 처음 설치될 때 디렉토리 구조에 로드됩니다.
그림 8. /(루트) 파일 시스템 트리
오른쪽 디렉토리(/usr, /tmp, /var 및 /home)는 모두 파일 시스템이므로 자신이 사용할 수 있는 별도의 하드

디스크 구역이 할당되어 있습니다. 이러한 파일 시스템은 시스템이 시작될 때 자동으로 마운트되므로, 일반 사용
자는 이 파일 시스템과 왼쪽에 있는 디렉토리(/bin, /dev, /etc 및 /lib)가 다르다는 것을 알 수 없습니다.
독립형 머신에서 다음 파일 시스템은 기본적으로 연관된 장치에 상주합니다.
/장치 /파일 시스템

/dev/hd1 /home
/dev/hd2 /usr
/dev/hd3 /tmp
/dev/hd4 /(root)
/dev/hd9var /var
/proc /proc
/dev/hd10opt /opt
파일 트리의 특성은 다음과 같습니다.

• 동일한 하드웨어 구조의 시스템에서 공유할 수 있는 파일은 /usr 파일 시스템에 있습니다.
• 스풀 및 메일 파일과 같이 클라이언트 전용 변수 파일은 /var 파일 시스템에 있습니다.
• /(root) 파일 시스템에는 시스템 운영에 중요한 파일과 디렉토리가 있습니다. 예를 들어, 다음이 들어 있습니
다.
– 장치 디렉토리(/dev)
– /mnt와 같이, 파일 시스템을 루트 파일 시스템에 마운트할 수 있는 마운트 위치
• /home 파일 시스템은 사용자의 홈 디렉토리를 위한 마운트 위치입니다.
• 서버의 경우, /export 디렉토리에는 페이징 공간 파일, 클라이언트 전용(공유되지 않는) 루트 파일 시스템, 덤
프, 홈 및 디스크 없는 클라이언트용 /usr/share 디렉토리뿐만 아니라 반출된 /usr 디렉토리도 있습니다.
장치 관리 71
• /proc 파일 시스템은 시스템의 프로세스 및 스레드의 상태에 관한 정보를 포함합니다.
• /opt 파일 시스템은 애플리케이션과 같은 선택적 소프트웨어를 포함합니다.
다음 리스트에서는 /(root) 파일 시스템의 서브디렉토리의 일부 내용에 대한 정보를 제공합니다.
항목 설명
/bin /usr/bin 디렉토리에 대한 기호 링크
/dev 로컬 장치를 위한 특수 파일용 장치 노드를 포함합니다. /dev 디렉토리는 테이프 장치, 프린터, 디
스크 파티션 및 터미널에 대한 특수 파일을 포함합니다.
/etc 각 장치에 대한 다양한 구성 파일을 포함합니다. 예를 들면, 다음과 같습니다.
• /etc/hosts
• /etc/passwd
/export 원격 클라이언트에 대한 서버의 디렉토리 및 파일을 포함합니다.

/home 사용자 홈 디렉토리를 포함하는 파일 시스템에 대한 마운트 위치 역할을 합니다. /home 파일 시스
템은 각각의 사용자의 파일 및 디렉토리를 포함합니다.
독립형 시스템에서 별도의 로컬 파일 시스템은 /home 디렉토리 위에 마운트됩니다. 네트워크에
서, 서버는 몇 개의 시스템에서 액세스되어야 하는 사용자 파일을 포함할 수도 있습니다. 이런 경
우, 서버의 /home 디렉토리 사본은 /home 파일 시스템에 원격적으로 마운트됩니다.
/lib 이름의 형식이 lib*.a인 구조 독립형 라이브러리가 있는 /usr/lib 디렉토리에 대한 기호 링크.

/sbin 시스템을 부트하고 /usr 파일 시스템을 마운트할 때 필요한 파일이 있습니다. 부팅 중에 사용되는
대부분의 명령은 부트 이미지 RAM 디스크 파일 시스템이기 때문에 /sbin 디렉토리에 상주하는
명령은 극소수입니다.
/tmp 시스템 작성 임시 파일을 포함하는 파일 시스템에 대한 마운트 위치 역할을 합니다.
/u /home 디렉토리에 대한 기호 링크.
/usr 변경되지 않고 시스템에서 공유될 수 있는 파일(실행 가능한 프로그램 및 ASCII 문서)을 포함하는
파일 시스템을 위한 마운트 위치의 역할을 실행합니다.
독립형 시스템은 별도의 로컬 파일 시스템을 /usr 디렉토리 위에 마운트시킵니다. 디스크가 없거
나 디스크가 적은 시스템은 원격 서버의 디렉토리를 /usr 파일 시스템 위에 마운트합니다.
/var 각각의 기계를 연결 변환하는 다양한 파일에 대한 마운트 위치 역할을 합니다. 이 파일은 포함하고
있는 파일이 커지기 쉬운 파일이므로, /var 파일 시스템은 하나의 파일 시스템으로 구성됩니다.
예를 들어, 임시 작업 파일을 포함하는 /usr/tmp 디렉토리에 대한 기호 링크입니다.
루트 파일 시스템
루트 파일 시스템은 계층적 파일 트리의 맨 위에 있습니다. 루트 파일 시스템에는 시스템 부트를 위한 장치 디렉
토리와 프로그램을 포함하여 시스템 운영에 반드시 필요한 파일과 디렉토리가 포함됩니다. 루트 파일 시스템에
는 파일 시스템을 루트 파일 시스템 계층에 연결하기 위해 파일 시스템을 마운트할 수 있는 마운트 위치도 포함됩
니다.
다음 다이어그램은 루트 파일 시스템에 포함된 다양한 서브디렉토리를 보여 줍니다.
그림 9. 루트 파일 시스템
다음 리스트에서는 /(루트) 파일 시스템의 일부 서브디렉토리에 포함된 내용에 대한 정보를 제공합니다.
항목 설명
/etc 각 장치에 대한 다양한 구성 파일을 포함합니다. 예를 들면, 다음과 같습니다.
• /etc/hosts
• /etc/passwd
/etc 디렉토리는 일반적으로 시스템 관리에 사용되는 파일을 포함합니다. 이전에 /etc 디렉
토리에 상주하던 대부분의 명령이 지금은 /usr/sbin 디렉토리에 상주합니다. 하지만 호환성
을 위해 /usr/sbin 디렉토리에는 몇몇 실행 파일의 위치에 대한 기호 링크가 포함되어 있습
니다. 예를 들면, 다음과 같습니다.
• /etc/chown. /usr/bin/chown에 대한 기호 링크입니다.
• /etc/exportvg. /usr/sbin/exportvg에 대한 기호 링크입니다.
/bin /usr/bin 디렉토리에 대한 기호 링크입니다. 이전의 UNIX 파일 시스템에서는 /bin 디렉토

리에 사용자 명령이 포함되었습니다. 지금은 이러한 명령이 /usr/bin 디렉토리에 상주합니
다.
/sbin 시스템을 부트하고 /usr 파일 시스템을 마운트할 때 필요한 파일이 있습니다. 부팅 중에 사용
되는 대부분의 명령은 부트 이미지 RAM 디스크 파일 시스템이기 때문에 /sbin 디렉토리에
상주하는 명령은 극소수입니다.
/dev 로컬 장치를 위한 특수 파일용 장치 노드를 포함합니다. /dev 디렉토리는 테이프 장치, 프린
터, 디스크 파티션 및 터미널에 대한 특수 파일을 포함합니다.
/tmp 시스템 작성 임시 파일을 포함하는 파일 시스템에 대한 마운트 위치 역할을 합니다./tmp 파일
시스템은 빈 디렉토리입니다.
/var 각각의 기계를 연결 변환하는 다양한 파일에 대한 마운트 위치 역할을 합니다. /var 파일 시스
템은 시스템에 포함된 파일이 커지기 쉬운 파일이므로, 하나의 파일 시스템으로 구성됩니다.
자세한 정보는 77 페이지의 『/var 파일 시스템』의 내용을 참조하십시오.
/u /home 디렉토리에 대한 기호 링크.
장치 관리 73
항목 설명
/usr 변경되지 않고 시스템에서 공유될 수 있는 파일(실행 파일 및 ASCII 문서)을 포함합니다.
독립형 시스템은 별도의 로컬 파일 시스템의 루트를 /usr 디렉토리 위에 마운트합니다. 디스
크가 없거나 디스크 자원이 제한된 시스템은 원격 서버의 디렉토리를 /usr 파일 시스템 위에
마운트합니다./usr 위에 마운트되는 파일 트리에 대한 자세한 정보는 74 페이지의 『/usr
파일 시스템』의 내용을 참조하십시오.
/home 사용자 홈 디렉토리를 포함하는 파일 시스템에 대한 마운트 위치 역할을 합니다. /home 파일

시스템은 각각의 사용자의 파일 및 디렉토리를 포함합니다.
독립형 시스템에서 /home 디렉토리는 루트가 /home 디렉토리 위에 마운트되는 별도의 파일
시스템에 포함됩니다. 네트워크에서, 서버는 몇 개의 시스템에서 액세스되어야 하는 사용자 파
일을 포함할 수도 있습니다. 이런 경우, 서버의 /home 디렉토리 사본은 로컬 /home 파일 시스
템에 원격으로 마운트됩니다.
/export 원격 클라이언트에 대한 서버의 디렉토리 및 파일을 포함합니다.

/export 디렉토리에 아래에 있는 파일 트리에 대한 자세한 정보는 78 페이지의 『/export
디렉토리』의 내용을 참조하십시오.
/lib /usr/lib 디렉토리에 대한 기호 링크입니다. 자세한 정보는 74 페이지의 『/usr 파일 시스

템』의 내용을 참조하십시오.
/tftpboot 디스크 없는 클라이언트의 부트 이미지와 부트 정보를 포함합니다.
/usr 파일 시스템
/usr 파일 시스템에는 여러 시스템에서 공유할 수 있는 실행 파일이 포함됩니다.
다음 다이어그램은 /usr 디렉토리의 주요 서브디렉토리를 보여 줍니다.
그림 10. /usr 파일 시스템
독립형 시스템에서는 /usr 파일 시스템이 /dev/hd2 논리적 볼륨에 있는 별도의 파일 시스템입니다. 디스크가
없거나 디스크 자원이 제한된 시스템에서는 원격 서버의 디렉토리가 로컬 /usr 파일 시스템에 읽기 전용 권한으
로 마운트됩니다. /usr 파일 시스템에는 읽기 전용 명령, 라이브러리 및 데이터가 포함됩니다.
/usr/share 디렉토리의 컨텐츠만 제외하고, /usr 파일 시스템의 파일과 디렉토리는 하드웨어 구조가 동일한
모든 시스템에서 공유할 수 있습니다.
/usr 파일 시스템에 포함되는 디렉토리는 다음과 같습니다.
항목 설명
/usr/bin 일반 명령 및 쉘 스크립트를 포함합니다. 예를 들어, /usr/bin 디렉토리에는 ls, cat
및 mkdir 명령이 포함됩니다.
장치 관리 75
항목 설명
/usr/ccs 개별화된 개발 패키지 2진을 포함합니다.
/usr/include 내포 또는 헤더, 파일을 포함합니다.
/usr/lbin 명령의 백엔드인 실행 파일을 포함합니다.
/usr/lib lib*.a 양식의 이름을 가진 구조 독립 라이브러리를 포함합니다. /(루트)의 /lib 디렉
토리는 /usr/lib 디렉토리에 대한 기호 링크이므로 이전에 /lib 디렉토리에 있었던
파일이 지금은 모두 /usr/lib 디렉토리에 있습니다. 호환성을 위해 이 디렉토리에는
몇 개의 비라이브러리 파일이 포함되어 있습니다.
/usr/lpp 선택적으로 설치된 제품을 포함합니다.
/usr/sbin SMIT(System Management Interface Tool) 명령을 포함하여 시스템 관리에 사용되는
유틸리티를 포함합니다. 이전에 /etc 디렉토리에 상주하던 대부분의 명령이 지금
은 /usr/sbin 디렉토리에 상주합니다.
/usr/share 구조가 다른 여러 시스템에서 공유할 수 있는 파일을 포함합니다. 자세한 정보는 76 페
이지의 『/usr/share 디렉토리 』의 내용을 참조하십시오.
다음은 /var 디렉토리에 대한 기호 링크입니다.
항목 설명
/usr/adm /var/adm 디렉토리에 대한 기호 링크입니다.
/usr/mail /var/spool/mail 디렉토리에 대한 기호 링크입니다.
/usr/news /var/news 디렉토리에 대한 기호 링크입니다.
/usr/preserve /var/preserve 디렉토리에 대한 기호 링크입니다.
/usr/spool /var/spool 디렉토리에 대한 기호 링크입니다.
/usr/tmp /var/tmp 디렉토리에 대한 기호 링크입니다. /usr 디렉토리는 여러 노드에서 공유
할 수 있으며 읽기 전용이기 때문입니다.
다음은 /usr/share 및 /usr/lib 디렉토리에 대한 기호 링크입니다.
항목 설명
/usr/dict /usr/share/dict 디렉토리에 대한 기호 링크입니다.
/usr/man /usr/share/man 디렉토리에 대한 기호 링크입니다.
/usr/lpd /usr/lib/lpd 디렉토리에 대한 기호 링크입니다.
/usr/share 디렉토리
/usr/share 디렉토리에는 구조의 영향을 받지 않는 공유 가능 텍스트 파일이 들어 있습니다. 이 디렉토리의 내
용은 하드웨어 구조와 관계없이 모든 시스템이 공유할 수 있습니다.
혼합 구조 환경에서 일반 디스크 없는 클라이언트는 하나의 서버 디렉토리를 자체의 /usr 디렉토리에 마운트한
후 다른 디렉토리를 /usr/share 디렉토리에 마운트합니다. /usr/share 디렉토리 아래의 파일은 하나 이상
의 별도로 설치할 수 있는 패키지에 포함됩니다. 그러므로 노드에는 /usr/share 디렉토리를 제공하기 위해 서
버를 사용하는 동안 로컬에 설치된 /usr 디렉토리의 다른 부분이 포함될 수 있습니다.
/usr/share 디렉토리의 일부 파일에는 다음 다이어그램에 표시된 디렉토리와 파일이 포함됩니다.
그림 11. /usr/share 디렉토리
이 다이어그램은 /lib, /lpp, /dict 및 /man을 포함하여 /usr/share 디렉토리 아래의 일부 디렉토리를 표
시합니다.
/usr/share 디렉토리에 포함된 디렉토리는 다음과 같습니다.
항목 설명
/usr/share/man 로드된 경우 매뉴얼 페이지를 포함합니다.
/usr/share/dict 철자 사전과 색인을 포함합니다.
/usr/share/lib terminfo, learn, tmac, me 및 macros를 포함하여 구조 독립 데이터 파일을 포
함합니다.
/usr/share/lpp 시스템에 설치할 수 있는 제품(선택적)에 대한 데이터와 정보를 포함합니다.
/var 파일 시스템
/var 파일 시스템에는 사용통계, 메일 및 인쇄 스풀러와 같이 사용량이 많은 애플리케이션에 사용되는 파일과
서브디렉토리가 포함되므로 그 크기가 지속적으로 증가합니다.
주의: 시스템의 애플리케이션들이 /var 파일 시스템을 광범위하게 사용할 경우, 정기적으로 skulker
명령을 실행하거나 파일 시스템 크기를 /var의 디폴트 크기인 4MB 이상으로 늘리십시오.
정기적으로 모니터링이 수행되는 /var 파일은 /var/adm/wtmp와 /var/adm/ras/errlog입니다.
이외에 모니터할 /var 파일은 다음과 같습니다.
항목 설명
/var/adm/ras/trcfile 추적 기능이 켜져 있는지 여부
/var/tmp/snmpd.log 시스템에서 snmpd 명령이 실행 중인지 여부
/var 디렉토리 다이어그램은 /var 파일 시스템에 있는 몇몇 디렉토리를 보여 줍니다.
그림 12. /var 디렉토리
장치 관리 77
항목 설명
/var/adm 시스템 로깅 및 사용통계 파일을 포함합니다.
/var/news 시스템 뉴스를 포함합니다.
/var/preserve 인터럽트된 편집 세션에서 보존된 데이터를 포함하며 이전 릴리스의 /usr/
preserve 디렉토리와 유사합니다.
/var/spool 전자 메일과 같은 프로그램에서 처리 중인 파일을 포함하며 이전 릴리스의 /usr/
spool 디렉토리와 유사합니다.
/var/tmp 임시 파일을 포함하며 이전 릴리스의 /usr/tmp 디렉토리와 유사합니다. 지금
은 /usr/tmp 디렉토리가 /var/tmp에 대한 기호 링크입니다.
/export 디렉토리
/export 디렉토리에는 디스크가 없거나 적은 시스템 또는 데이터가 없는 시스템과 같은 클라이언트로 반출된
서버 파일이 포함됩니다.
서버에서는 실행 가능 프로그램, 디스크가 없는 클라이언트용 페이징 공간, 디스크가 없거나 디스크 자원이 적은
클라이언트용 루트 파일 시스템을 포함하여 다양한 유형의 디스크 공간을 반출할 수 있습니다. 파일 트리에서 이
러한 디스크 공간이 일반적으로 배치되는 위치는 /export 디렉토리입니다. 다음 리스트는 /export 디렉토리
의 서브디렉토리를 보여 줍니다.
/exec
디스크 없는 클라이언트가 해당 /usr 파일 시스템에 마운트하는 디렉토리를 포함합니다.
/swap
디스크 없는 클라이언트의 원격 페이징용 파일을 포함합니다.
/share
디스크 없는 클라이언트가 해당 /usr/share 디렉토리에 마운트하는 디렉토리를 포함합니다.
/root
디스크 없는 클라이언트가 해당 / (root) 파일 시스템에 마운트하는 디렉토리를 포함합니다.
/home
디스크 없는 클라이언트가 해당 /home 파일 시스템에 마운트하는 디렉토리를 포함합니다.
/export 디렉토리는 디스크 없는 명령에 사용되는 클라이언트 자원이 보관되는 디폴트 위치입니다. /export
디렉토리는 클라이언트 자원이 있는 서버의 유일한 위치입니다. 클라이언트는 이러한 자원을 자신의 파일 트리
에 마운트하므로 클라이언트측에서는 이러한 자원이 파일 트리의 일반적인 위치에 나타납니다. 클라이언트 파일
트리에서 /export 디렉토리에 포함된 주요 서브디렉토리와 해당 마운트 위치는 다음과 같습니다.
/export/root
이 디렉토리는 클라이언트 루트(/) 파일 시스템에 마운트됩니다. 클라이언트 루트 디렉토리의 디폴트 위치
는 /export/root 디렉토리이고 클라이언트의 호스트 이름이 붙여집니다.
/export/exec
SPOT(Shared Product Object Tree) 디렉토리라고도 합니다. 이 디렉토리는 클라이언트 /usr 파일 시스템
에 마운트됩니다. SPOT는 /export/exec 디렉토리에 저장된 /usr 파일 시스템 버전이며, 해당 릴리스 레
벨을 나타내는 이름이 지정됩니다. 기본적으로, 이 이름은 RISCAIX입니다.
/export/share
이 디렉토리는 클라이언트 /usr/share 파일 시스템에 마운트됩니다. 이 디렉토리에는 다양한 구조가 공유
할 수 있는 데이터가 포함됩니다. 디폴트 위치는 /export/share/AIX/usr/share입니다.
/export/home
이 디렉토리는 클라이언트 /home 파일 시스템에 마운트됩니다. 이 디렉토리에는 클라이언트 호스트 이름별
로 그룹화된 사용자 디렉토리가 포함됩니다. 클라이언트 홈 디렉토리의 디폴트 위치는 /export/home입니
다.
/export/swap
페이징 디렉토리라고도 합니다. 독립형 또는 데이터 없는 시스템에서는 로컬 디스크에서 페이징을 제공합니
다. 디스크 없는 클라이언트에서는 서버의 파일이 이 서비스를 제공합니다. 이 파일의 이름은 클라이언트 호
스트 이름을 따르고 디폴트로 /export/swap 디렉토리에 있습니다.
/export/dump
독립형 시스템에서는 덤프 장치로 로컬 디스크를 사용하고, 디스크 없는 클라이언트에서는 파일의 서버를 사
용합니다. 이 파일은 클라이언트 호스트 이름을 따라 이름이 붙여져 디렉토리에 상주하며 디폴트로 /
export/dump 디렉토리에 있습니다.
microcode
이 디렉토리에는 물리적 장치용 마이크로 코드가 포함됩니다. 디폴트 위치는 /export/exec/
RISCAIX/usr/lib/microcode입니다.
JFS2 파일 시스템 암호화

AIX 버전 6.1부터는 암호화된 파일 시스템(EFS)이 JFS2 파일 시스템에서 지원됩니다. EFS는 데이터를 암호화하
고 키 보호를 통해 데이터에 대한 액세스를 제어할 수 있습니다.
키는 각 사용자와 연관되고 암호로 보호된 키 저장소에 저장됩니다. 로그인에 성공하면, 사용자의 키는 커널에 로
드되고 프로세스 신임 정보와 연관됩니다. EFS-보호 파일을 열기 위해 프로세스 신임 정보가 테스트됩니다. 프로
세스가 파일 보호와 일치하는 키를 찾으면 프로세스는 파일 키와 파일 컨텐츠를 복호화합니다.
기본적으로, JFS2 파일 시스템은 EFS 사용 가능하지 않습니다. 데이터를 암호화하려면 JFS2 파일 시스템이 EFS
가능해야 합니다.
파일 시스템 구성
파일 시스템을 추가하거나 구성할 때 SMIT 단축 경로의 파일 시스템 컨테이너에서 옵션을 선택할 수 있습니다.
다음 표에서는 SMIT 단축 경로를 보여 줍니다.
표 4. 논리적 볼륨 및 파일 시스템 관리 태스크

태스크 SMIT 단축 경로
JFS 또는 JFS2 추가 smit crfs
기존 논리적 볼륨에 JFS2 추가 smit crjfs2lvstd
이전에 정의된 논리적 볼륨 메뉴에 JFS 추가 논리적 볼륨 작성 후 smit crjfslv 실행
JFS 또는 JFS2 속성 변경 주 1 smit chfs
파일 시스템 크기 확인 smit fs
파일 시스템 크기 늘리기 JFS: smit chjfs JFS2: smit chjfs2
파일 시스템 크기 줄이기 JFS2: smit chjfs2
참고: 파일 시스템 크기 줄이기용 SMIT 단축 경로는 JFS2에만 사용할 수 있습니다.
파일 시스템 관리
파일 시스템은 루트 디렉토리와 그 아래에 서브디렉토리 및 파일을 포함하는 완전한 디렉토리 구조입니다.
파일 시스템은 단일 논리적 볼륨에서만 상주합니다. 다음과 같은 매우 중요한 일부 시스템 태스크는 특별히 파일
시스템으로 작업해야 합니다.
• 논리적 볼륨에 파일 시스템 영역 할당
• 파일 시스템 작성
• 시스템 사용자에게 사용 가능 파일 시스템 영역 작성
• 파일 시스템 영역 사용법 모니터
• 시스템 장애 시 데이터 유실에 대비한 파일 시스템 백업
• 스냅샷을 만들어 특정 시점의 파일 시스템에 대한 일관된 블록 레벨 이미지 캡처
장치 관리 79
• 일관된 상태로 파일 시스템 유지
다음은 파일 시스템을 관리하는 데 도움이 되는 시스템 관리 명령 리스트입니다.
항목 설명
backup 파일 시스템을 전체 백업 또는 변경분 백업합니다.
chfs -a 마운트된 JFS 파일 시스템의 온라인 백업을 작성합니다.
splitcopy
dd 파일 시스템 백업을 작성하기 위해 한 장치에서 다른 장치로 직접 데이터를 복사합니다.
df 파일 시스템의 사용된 공간 및 사용 가능 공간을 보고합니다.
fsck 파일 시스템을 점검하고 불일치를 수정합니다.
mkfs 지정된 논리적 볼륨에 지정된 크기의 파일 시스템을 작성합니다.
mount 파일 시스템의 파일과 디렉토리에 액세스할 수 있도록 시스템 차원 이름 붙이기 구조에 파일
시스템을 연결합니다.
restore 백업에서 파일을 복원합니다.
snapshot JFS2 파일 시스템의 스냅샷을 작성합니다.
umount 파일 시스템의 파일과 디렉토리에 액세스할 수 있도록 시스템 차원 이름 붙이기 구조에서 파일
시스템을 제거합니다.
파일 시스템의 사용 가능 공간 표시(df 명령)

df 명령을 사용하면 파일 시스템의 총 공간 및 사용 가능한 공간에 대한 정보를 표시할 수 있습니다.
FileSystem 매개변수는 파일 시스템이 상주하는 장치 이름, 파일 시스템이 마운트된 디렉토리 또는 파일 시스
템의 상대 경로 이름을 지정합니다.
FileSystem 매개변수를 지정하지 않을 경우, df 명령은 현재 마운트된 모든 파일 시스템에 대한 정보를 표시
합니다. 파일 또는 디렉토리가 지정될 경우, df 명령은 해당 파일이나 디렉토리가 상주하고 있는 파일 시스템에
대한 정보를 표시합니다.
일반적으로, df 명령은 수퍼 블록에 포함된 사용 가능 개수를 사용합니다. 특정 예외 조건 아래에서는, 이런 개수
에 오류가 발생할 수 있습니다. 예를 들어, df 명령이 실행되는 동안 파일 시스템이 수정되는 중이라면, 사용 가능
개수가 정확하지 않을 수 있습니다.
참고: NFS(Network File System)와 같은 원격 파일 시스템은 서버가 정보를 제공하지 않으면 표시장치에서 사
용 가능한 공간을 나타내는 열이 공백으로 남아있습니다.
다음은 df 명령을 사용하는 방법에 대한 예제입니다.
• 마운트된 모든 파일 시스템에 대한 정보를 표시하려면 다음을 입력하십시오.
df
/, /usr, /site 및 /usr/venus 디렉토리가 별도의 파일 시스템에 상주하도록 시스템이 구성된 경우 df 명

령의 출력은 다음과 유사합니다.
Filesystem 512-blocks free %used Iused %Iused Mounted on

/dev/hd4 20480 13780 32% 805 13% /
/dev/hd2 385024 15772 95% 27715 28% /usr
/dev/hd9var 40960 38988 4% 115 1% /var
/dev/hd3 20480 18972 7% 81 1% /tmp
/dev/hd1 4096 3724 9% 44 4% /home
• 현재 디렉토리가 상주하는 파일 시스템의 사용 가능 공간을 표시하려면 다음을 입력하십시오.

df .
파일 시스템 명령
파일 시스템의 유형에 관계없이 파일 시스템에서 사용할 수 있도록 설계된 다양한 명령이 있습니다.
/etc/filesystems 파일은 다음 명령으로 조작할 수 있는 파일 시스템 리스트를 제어합니다.
항목 설명
chfs 파일 시스템 특성을 변경합니다.
crfs 파일 시스템을 추가합니다.
lsfs 파일 시스템의 특성을 표시합니다.
rmfs 파일 시스템을 제거합니다.
mount 파일 시스템을 사용 가능하게 만듭니다.
가상 파일 시스템 유형에서는 4개의 명령을 사용할 수 있습니다. /etc/vfs 파일에는 다음 명령으로 조작할 수
있는 파일 시스템 유형에 대한 정보가 있습니다.
항목 설명
chvfs 파일 시스템 유형의 특성을 변경합니다.
crvfs 파일 시스템 유형을 추가합니다.
lsvfs 파일 시스템 유형의 특성을 나열합니다.
rmvfs 파일 시스템 유형을 제거합니다.
다른 시스템의 파일 시스템 비교
다른 시스템에 있는 파일 시스템이 동일해야 하는데 그 중 하나가 손상되었다고 의심되면 파일 시스템을 비교할
수 있습니다.
다음 프로시저에서는 현재 호스트(이 시나리오에서는 orig_host)에 상주하는 파일 시스템의 속성을 원격 호스트
에 있는 동일한 파일 시스템의 속성과 비교합니다.
1. 원격 호스트에 루트 사용자로서 로그인하십시오.
tn juniper.mycompany.com
AIX Version 6.1

(C) Copyrights by IBM and by others 1982, 2002.
login: root
root's Password:
2. 즐겨찾기 편집기를 사용하여 원격 호스트의 .rhosts 파일을 편집하여, 루트 사용자가 보안 원격 명령을 실

행하도록 허용하는 스탠자를 추가하십시오. 새 스탠자에 다음 형식을 사용하십시오.
orig_host root
결과로 나오는 .rhosts 파일은 다음과 유사합니다.
NIM.mycompany.com root
nim.mycompany.com root
host.othernetwork.com root
orig_host.mycompany.com root
3. 변경사항을 저장하고 원격 연결을 종료하십시오.

4. 루트 권한으로 orig_host에서 즐겨찾기 편집기를 사용하여 다른 파일을 작성하십시오.
이 시나리오에서는 새 파일의 이름이 compareFS입니다. 예를 들어 다음과 같습니다.
vi compareFS
5. 이 파일에 다음 텍스트를 삽입하십시오. 여기서, FSname은 비교할 파일 시스템의 이름이고, remote_host는

비교 파일 시스템이 상주하는 호스트의 이름입니다.
장치 관리 81
FSname -> remote_host
install -v ;
참고: 이 파일의 install 명령행에서 -v 매개변수와 세미콜론(;) 사이에는 반드시 공백이 있어야 합니다.
/home/jane/* -> juniper.mycompany.com
install -v ;
6. 파일을 저장하고 편집기를 종료하십시오. compareFS 파일은 다음 단계에서 rdist 명령에 대한 distfile로
사용됩니다.
7. 명령 프롬프트에 다음을 입력하십시오.
/usr/bin/rdist -f compareFS
또는 비교 결과 많은 양의 출력이 예상되는 경우, 출력을 파일 이름에 전송하십시오. 예를 들어 다음과 같습니

다.
/usr/bin/rdist -f compareFS > compareFS_output
출력은 파일 시스템간의 차이점을 나열합니다.
파일 시스템을 유지보수하기
다음 표에서는 파일 시스템을 유지보수할 때 필요한 가장 간단한 태스크를 보여 줍니다.
표 5. 파일 시스템 유지보수 태스크

파일 또는 디렉토리 이름별 백업 smit backfile backup 주 1
JFS2 스냅샷 이미지 작성 및 백업 smit backsnap backsnap 주 1
디스크의 모든 파일 시스템 나열 smit lsmntdsk
이동식 디스크의 파일 시스템 나열 smit lsmntdsk
마운트된 파일 시스템 나열 smit fs
파일 시스템 그룹 마운트주 5 smit mountg mount -t GroupName
JFS 또는 JFS2 마운트주 3 smit mountfs mount

JFS2 스냅샷 마운트 smit mntsnap mount -v jfs2 -o snapshot
Device MountPoint
JFS 또는 JFS2 제거 smit rmfs
JFS2 스냅샷 제거 smit rmsnap snapshot -d SnapshotDevice
JFS2 파일 시스템을 특정 시점 스냅 smit rollbacksnap rollback [-s] [-v] [-c]

샷으로 되돌리기 snappedFS snapshotObject
파일 시스템 마운트 해제주 4 smit umountfs
이동식 디스크의 파일 시스템 마운 smit umntdsk

트 해제주 4
파일 시스템 그룹 마운트 해제주 5 smit umountg umount -t GroupName
확장 저널 파일 시스템 할당량 관리 smit j2fsquotas
할당량 관리를 사용 가능 또는 사용 smit j2enablequotas

불가능하게 만들기
표 5. 파일 시스템 유지보수 태스크 (계속)
할당량 한계 적용 정지/재시작 smit j2enforcequotas quotaon|off -v
할당량 사용량 나열 smit j2repquota repquota -v
현재 디스크 블록 및 파일 사용량 통 smit j2quotacheck quotacheck -v

계 다시 계산
한계 클래스 추가 smit j2addlimit j2edlimit -e
한계 클래스 특성 변경/표시 smit j2changelimit
한계 클래스를 파일 시스템의 디폴 smit j2defaultlimit

트 한계로 만들기
한계 클래스에 사용자 또는 그룹 지 smit j2assignlimit
정
파일 시스템의 한계 클래스 나열 smit j2listlimits j2edlimit -l '-u'
한계 클래스 제거 smit j2removelimit
참고:
1. 사용할 수 있는 옵션은 개별 명령을 참조하십시오.
2. 논리적 볼륨 4(hd4)의 /(루트), hd2의 /usr, hd9var의 /var, hd3의 /tmp 및 hd5의 /blv와 같이 시스템에
반드시 필요한 파일 시스템의 이름은 변경하지 마십시오. hdn 규칙을 사용할 경우, hd10에서 시작하십시오.
3. 마운트하기 전에 86 페이지의 『파일 시스템 검증』 프로시저를 사용하거나 fsck 명령을 실행하여 파일 시
스템을 확인하십시오.
4. 마운트 해제에 실패할 경우, 마운트 해제 중인 파일 시스템에 있는 파일을 사용자나 프로세스에서 열었을 수
있습니다. fuser 명령을 사용하면 실패를 야기한 사용자나 프로세스를 알아낼 수 있습니다.
5. 파일 시스템 그룹은 /etc/filesystems 파일에서 type= ID 값이 동일한 파일 시스템들의 집합입니다.
온라인 외부 JFS2 스냅샷으로부터 하나 이상의 파일 복구

온라인 외부 JFS2 스냅샷에 정확한 사본이 있는 경우 손상된 파일을 대체할 수 있습니다.
다음 프로시저를 사용하여 온라인 외부 JFS2 스냅샷 이미지에서 하나 이상의 파일을 복구할 수 있습니다.
이 예에서는 /home/aaa/myfile이 /home 파일 시스템에서 손상된 파일이라고 가정하십시오.
1. 다음과 유사한 명령으로 스냅샷을 마운트하십시오.
mount -v jfs2 -o snapshot /dev/mysnaplv /tmp/mysnap
2. 다음과 유사한 명령으로 스냅샷을 포함하는 디렉토리로 변경하십시오.

cd /tmp/mysnap
3. 다음과 유사한 명령으로 손상된 파일을 겹쳐쓰기 위해 스냅샷에서 정확한 파일을 복사하십시오.
cp aaa/myfile /home/aaa/myfile
이전 예는 이름이 myfile인 파일만을 복사합니다. 모든 파일을 스냅샷에서 aaa 디렉토리로 복사하려면 다

음과 유사한 명령을 사용하십시오.
cp -R aaa /home/aaa
온라인 내부 JFS2 스냅샷으로부터 하나 이상의 파일 복구

온라인 내부 JFS2 스냅샷에 정확한 사본이 있는 경우 손상된 파일을 대체할 수 있습니다.
다음 프로시저를 사용하여 온라인 내부 JFS2 스냅샷 이미지에서 하나 이상의 파일을 복구할 수 있습니다.
장치 관리 83
이 예에서는 /home/aaa/myfile이 /home 파일 시스템에서 손상된 파일이라고 가정하십시오.
1. 다음과 유사한 명령으로 스냅샷을 포함하는 디렉토리로 변경하십시오.
cd /home/.snapshot/mysnap
2. 다음과 유사한 명령으로 손상된 파일을 겹쳐쓰기 위해 스냅샷에서 정확한 파일을 복사하십시오.
cp aaa/myfile /home/aaa/myfile
이전 예는 이름이 myfile인 파일만을 복사합니다. 모든 파일을 스냅샷에서 aaa 디렉토리로 복사하려면 다

음과 유사한 명령을 사용하십시오.
cp -R aaa /home/aaa
CD-ROM 및 DVD 디스크의 파일 시스템

CD와 DVD는 자동으로 마운트되지 않지만 자동 마운트 기능을 사용 가능으로 설정할 수 있습니다.
이 기능을 사용 가능하게 만들려면 cdmount 명령을 사용하여 CDRFS 또는 UDFS 파일 시스템을 마운트하십시
오. 예를 들면, 다음과 같습니다.
cdmount cd0
다음 명령을 사용하여 읽기/쓰기 UDFS를 수동으로 마운트할 수 있습니다:

mount -V udfs DevName MtPt
여기서 DevName은 DVD 드라이브의 이름이고 MtPt는 파일 시스템의 마운트 위치입니다.
읽기/쓰기 광학 미디어에서 파일 시스템 사용

읽기/쓰기 광학 미디어에서 CDRFS과 JFS 파일 시스템을 사용할 수 있습니다.
광학 미디어가 쓰기 방지로 설정되어 있기만 하면 CD-ROM은 물론 읽기/쓰기 광학 미디어에도 CD-ROM 파일 시
스템(CDRFS)을 저장할 수 있습니다. 다음 표에서는 읽기/쓰기 광학 미디어에 CDRFS를 추가하거나 마운트 및 마
운트 해제하는 방법을 보여 줍니다. 파일 시스템을 마운트할 때는 다음 정보를 지정해야 합니다.
항목 설명
장치 이름 미디어가 포함된 장치의 이름을 정의합니다.
마운트 위치 파일 시스템이 마운트될 디렉토리를 지정합니다.
자동 마운트 시스템이 재시작될 때 파일 시스템을 자동 마운트할지 여부를 지정합니다.
광학 미디어에서 수행할 CDRFS 태스크

CDRFS 추가 1 smit crcdrfs 1. 파일 시스템을 추가하십시오.
crfs -v cdrfs -p ro -
dDeviceName -m MountPoint -
A AutomaticMount
mount MountPoint
CDRFS 제거2 1. 파일 시스템을 마운트 해제하십 1. 파일 시스템을 마운트 해제하십

시오. smit umountfs 시오. umount FileSystem
2. 파일 시스템을 제거하십시오. 2. 파일 시스템을 제거하십시오.
smit rmcdrfs rmfs MountPoint
참고:
• 읽기/쓰기 광학 미디어가 쓰기 방지로 설정되어 있는지 확인하십시오.
• 읽기/쓰기 광학 미디어를 제거하려면 먼저 CDRFS 파일 시스템을 마운트 해제해야 합니다.
JFS는 광학 미디어에서도 하드 디스크에서와 유사한 읽기/쓰기 파일 시스템을 제공합니다. 읽기/쓰기 광학 미디
어에 읽기/쓰기 파일 시스템을 작성하거나 반입하려면 시스템 권한을 가지고 있어야 합니다. 즉, 사용자 로그인
이 시스템 그룹에 속해야 합니다. 또한 다음 정보를 알고 있어야 합니다.
볼륨 그룹 이름
볼륨 그룹 이름을 지정합니다.
장치 이름
읽기/쓰기 광학 드라이브의 논리적 이름을 지정합니다.
마운트 위치
파일 시스템이 마운트될 디렉토리를 지정합니다.
자동 마운트
시스템이 재시작될 때 파일 시스템을 자동 마운트할지 여부를 지정합니다.
참고:
• 읽기/쓰기 광학 미디어에 작성된 모든 볼륨 그룹은 이 미디어 자체에 포함되어야 합니다. 볼륨 그룹은 하나의
읽기/쓰기 광학 미디어에만 포함될 수 있습니다.
• 이전에 작성된 저널 파일 시스템에 액세스할 때는 볼륨 그룹 이름이, 해당 볼륨 그룹 작성 시 사용된 이름과 일
치하지 않아도 됩니다.
광학 미디어에서 수행할 JFS 태스크

JFS 추가 1. 드라이브에 광 디스크를 삽입하 1. 드라이브에 광 디스크를 삽입하
십시오. 십시오.
2. 볼륨 그룹을 작성하십시오(필요 2. 볼륨 그룹을 작성하십시오(필요
한 경우). smit mkvg 한 경우). mkvg -f -y
3. 저널 파일 시스템을 작성하십시 VGName -d 1 DeviceName
오. smit crfs 3. 저널 파일 시스템을 작성하십시
오. crfs -v jfs -g
VGName -a
size=SizeFileSystem -m
MountPoint -A
AutomaticMount -p rw
mount MountPoint
이전에 작성된 JFS 액세스주 1 1. 드라이브에 광 디스크를 삽입하 1. 드라이브에 광 디스크를 삽입하
십시오. 십시오.
2. 볼륨 그룹을 반입하십시오. 2. 볼륨 그룹을 반입하십시오.
smit importvg importvg -y VGName
DeviceName
mount MountPoint
JFS 제거주 2 1. 파일 시스템을 마운트 해제하십 1. 파일 시스템을 마운트 해제하십

시오. smit umountfs 시오. umount FileSystem
2. 파일 시스템을 제거하십시오. 2. 파일 시스템을 제거하십시오.
smit rmjfs rmfs MountPoint
참고:
장치 관리 85
• 저널 파일 시스템이 포함된 미디어를 삽입할 때마다 이 절차를 수행해야 합니다.
• 저널 파일 시스템을 제거하면 이 파일 시스템에 포함된 데이터와 읽기/쓰기 광학 미디어의 데이터가 모두 제거
됩니다.
파일 시스템 검증
파일 시스템이 마운트된 상태에 있는 동안 또는 디스크가 손상되었을 때 시스템이 정지되면 파일 시스템에서 불
일치가 발생할 수 있습니다. 이러한 경우에는 파일 시스템을 마운트하기 전에 반드시 검증해야 합니다.
다음과 같은 경우에도 파일 시스템을 검증하십시오.
• 고장이 발생한 후. 예를 들어, 사용자의 사용 권한(uid)이 있는 디렉토리로 디렉토리를 변경할 수 없는 경우
• 오류 및 가능한 복원 문제를 방지하기 위해 파일 시스템을 백업하기 전
• 운영 체제 파일 오류가 없는지 확인하기 위해 설치할 때 또는 시스템을 부트할 때
사용자 정의 파일 시스템 확인
사용자 정의 파일 시스템을 확인하려면 다음 단계를 수행하십시오.
1. 확인할 사용자 정의 파일 시스템을 마운트 해제하십시오.
2. 파일 시스템의 파일에 대해 쓰기 권한을 가지고 있는지 확인하십시오. 이 권한을 가지고 있지 않을 경우, 복구
프롬프트에서 예라고 응답하더라도 fsck로 손상된 파일을 복구할 수 없습니다.
3. smit fsck 단축 경로를 사용하여 파일 시스템 확인 메뉴에 액세스하십시오.
4. 다음 중 하나를 수행하십시오.
• 파일 시스템 이름 필드에, 확인할 개별 파일 시스템의 이름을 지정하십시오.
• 파일 시스템 유형 필드에서, 확인할 일반 파일 시스템 유형(예: 저널 파일 시스템(JFS))을 선택하십시오.
5. 불일치가 생겼을 가능성이 가장 높은 파일만 확인하려면 빠른 확인 필드에서 예를 지정하십시오.
빠른 확인 옵션은 과거의 특정 시점에서 시스템이 정지되었을 때 마운트된 파일 시스템과 같이 불일치가 생겼
을 가능성이 있는 파일 시스템만 확인합니다.
6. 스크래치 파일 필드에, 확인하지 않을 파일 시스템에 있는 임시 파일의 이름을 지정하십시오.
7. 파일 시스템 확인을 시작하십시오.
루트 및 /usr 파일 시스템 확인
/ 또는 /usr 파일 시스템에서 fsck 명령을 실행하려면 시스템을 종료한 후 이동식 미디어에서 재부트해야 합니
다. 이는 실행 중인 시스템에서는 /(루트) 및 /usr 파일 시스템을 마운트 해제할 수 없기 때문입니다.
다음 절차는 / 및 /usr 파일 시스템에 유지보수 쉘의 fsck를 실행하는 방법을 설명합니다.
1. 시스템을 종료하십시오.
(루트 액세스가 필요함)
2. 설치 미디어에서 부트하십시오.
3. 시작 메뉴에서 Maintenance 옵션을 선택하십시오.
4. 유지보수 메뉴에서, 볼륨 그룹에 액세스하는 옵션을 선택하십시오.
5. rootvg 볼륨 그룹을 선택하십시오. 선택한 볼륨 그룹에 속한 논리적 볼륨의 리스트가 표시됩니다.
6. 2를 선택하여 볼륨 그룹에 액세스한 후 파일 시스템을 마운트하기 전에 쉘을 시작하십시오.
다음 단계에서는 적절한 옵션 및 파일 시스템 장치 이름을 사용하여 fsck 명령을 실행하게 됩니다. fsck 명
령은 파일 시스템 일관성을 확인하고 파일 시스템을 대화식으로 복구합니다. /(루트) 파일 시스템 장치
는 /dev/hd4이고 /usr 파일 시스템 장치는 /dev/hd2입니다.
7. / 파일 시스템을 확인하려면 다음을 입력하십시오.
$ fsck -y /dev/hd4
-y 플래그는 명령 사용에 익숙하지 않은 사용자에게 권장됩니다(fsck 명령 참조).

8. /usr 파일 시스템을 확인하려면 다음을 입력하십시오.
$ fsck -y /dev/hd2
9. rootvg의 다른 파일 시스템을 확인하려면 적절한 장치 이름과 함께 fsck 명령을 입력하십시오. /tmp의 장
치는 /dev/hd3이고 /var의 장치는 /dev/hd9var입니다.
10. 파일 시스템 확인을 완료했으면 시스템을 재부트하십시오.
루트 볼륨 그룹에서 파일 시스템의 크기 줄이기

옵션을 예로 설정하는 것입니다.
옵션을 예로 설정하는 것입니다. SHRINK 옵션과 다음 시나리오는 나란히 사용할 수 없습니다. 다음 프로시저를
수행한 후에 SHRINK 옵션을 yes로 설정하면 설치는 /image.data 파일의 변경사항을 재정의합니다.
이 시나리오는 선택된 rootvg 파일 시스템의 크기를 줄이는 수동 프로세스를 안내합니다. 먼저 할당된 공간을
모두 사용하지 않는 파일 시스템을 식별한 다음, 파일 시스템이 실제로 사용하는 공간을 기준으로 공간을 다시 할
당하여 루트 볼륨 그룹에 더 많은 공간을 사용할 수 있도록 공간을 해제합니다. 이 프로시저의 일부로서 수정된
할당을 사용하여 볼륨 그룹을 백업하고 운영 체제를 다시 설치할 것입니다.
주의: 이 프로시저에서는 기본 운영 체제를 시스템 종료한 다음 다시 설치해야 합니다. 어떠한 운영 체제
이든지 다시 설치할 때마다 데이터나 기능을 잃어버릴 가능성을 막기 위해 워크로드에 영향이 적은 때로
작동 중지 시간을 스케줄하십시오. 운영 체제를 다시 설치하기 전에 데이터, 모든 조정된 애플리케이션 또
는 볼륨 그룹을 안전하게 백업했는지 확인하십시오.
1. rootvg에 포함되지 않은 모든 파일 시스템을 별도로 백업하십시오. 이 백업을 통해 모든 파일 시스템의 무
결성을 보장할 수 있습니다.
2. 루트 권한으로 다음 명령을 입력하여 루트 볼륨 그룹 내에서 할당된 디스크 공간을 사용하지 않는 파일 시스
템을 확인하십시오.
df -k
-k 플래그는 파일 시스템 크기를 KB단위로 표시합니다. 결과는 다음과 유사합니다.
Filesystem 1024-blocks Free %Used Iused %Iused Mounted on

/dev/hd4 196608 4976 98% 1944 2% /
/dev/hd2 1769472 623988 65% 36984 9% /usr
/dev/hd9var 163840 65116 61% 676 2% /var
/dev/hd3 65536 63024 4% 115 1% /tmp
/dev/hd1 49152 8536 83% 832 7% /home
/proc - - - - - /proc
/dev/hd10opt 32768 26340 20% 293 4% /opt
이 결과를 보면 많은 사용 가능 블록이 있고 /usr에 마운트된 파일 시스템과 연관된 사용률이 매우 낮은 것

을 알 수 있습니다. /usr 파일 시스템에 할당된 파티션의 수를 줄여서 상당한 수의 블록을 해제하기로 결정
할 수 있습니다.
3. /etc/filesystems 파일의 컨텐츠를 확인하여 rootvg 내의 모든 파일 시스템이 마운트되었는지 확인하
십시오. 그렇지 않으면, 다시 설치된 시스템에 포함되지 않을 것입니다.
4. 다음 명령을 입력하여 설치 프로시저에 포함되어 있는 rootvg의 모든 활성 파일 시스템을 나열하는 /
image.data 파일을 작성하십시오.
mkszfile
5. 즐겨찾기 편집기에서 /image.data 파일을 여십시오.

6. usr 텍스트 문자열을 검색하여 /usr 파일 시스템에 속하는 lv_data 스탠자를 찾으십시오.
이 스탠자의 수치를 기준으로 /usr 파일 시스템에서 줄일 수 있는 논리적 파티션의 수를 결정하십시오. 각
추가 논리적 파티션의 디폴트 크기는 /image.data 파일의 PP_SIZE 항목에서 정의됩니다. /
image.data 파일은 다음과 비슷합니다.
lv_data:
VOLUME_GROUP= rootvg
LV_SOURCE_DISK_LIST= hdisk0
장치 관리 87
LV_IDENTIFIER= 00042345d300bf15.5
LOGICAL_VOLUME= hd2
VG_STAT= active/complete
TYPE= jfs
MAX_LPS= 32512
COPIES= 1
LPs= 108
STALE_PPs= 0
INTER_POLICY= minimum
INTRA_POLICY= center
MOUNT_POINT= /usr
MIRROR_WRITE_CONSISTENCY= on/ACTIVE
LV_SEPARATE_PV= yes
PERMISSION= read/write
LV_STATE= opened/syncd
WRITE_VERIFY= off
PP_SIZE= 16
SCHED_POLICY= parallel
PP= 108
BB_POLICY= relocatable
RELOCATABLE= yes
UPPER_BOUND= 32
LABEL= /usr
MAPFILE=
LV_MIN_LPS= 70
STRIPE_WIDTH=
STRIP_SIZE=
이 논리적 볼륨 전용의 논리적 파티션 개수는 108(LPs=108)입니다.

7. 2단계의 결과를 사용하여 /usr 파일 시스템의 기존 데이터에 의해 필요한 논리적 파티션의 수를 결정하십
시오.
다음 명령을 사용하여, /usr 파일 시스템의 기존 파일 크기만 표시할 수 있습니다.
df -k /usr
결과는 2단계의 /usr 파일 시스템에 대해 수신한 수(KB 단위)를 반복합니다. 예를 들어, 다음과 같습니다.
Filesystem 1024-blocks Free %Used Iused %Iused Mounted on

/dev/hd2 1769472 623988 65% 36984 9% /usr
a) 할당된 1024 블록의 총 수에서 사용 가능 공간의 양을 빼십시오.

1769472 - 623988 = 1145484
b) 이 파일 시스템에서 예상하는 증가량을 수용할 수 있는 공간의 예상치를 추가하십시오.

이 예제에서는 결과에 200000을 더하십시오.
1145484 + 200000 = 1345484
c) 결과를 바이트 단위의(16*1024) 논리적 파티션 크기로 나누어서 필요로 하는 논리적 파티션의 최소한
의 수를 판별하십시오.
1345484 / 16384 = 82.121826171875
결과를 반올림한 후 이 값을 토대로 필요한 논리적 파티션 수를 다시 정의하십시오(LPs=83).

8. image.data 파일에서 LPs 필드를 108에서 83으로 변경하십시오.
9. /usr 파일 시스템에 관련된 fs_data 스탠자를 찾으십시오.
fs_data 스탠자는 다음과 비슷합니다.
fs_data:
FS_NAME= /usr
FS_SIZE= 3538944
FS_MIN_SIZE= 2290968
FS_LV= /dev/hd2
FS_FS= 4096
FS_NBPI= 4096
FS_COMPRESS= no
FS_BF= false
FS_AGSIZE= 8
10. 물리적 파티션 크기(PP_SIZE)에 2(물리적 파티션에 사용되는 512-바이트 블록의 수)를 곱하고 논리적 파
티션의 수(LPs)를 곱하여 파일 시스템 크기(FS_SIZE)를 계산하십시오.
이 예에서 사용된 값으로 계산하면 다음과 같습니다.
PP_SIZE * 512 blocks * LPs = FS_SIZE
16384 * 2 * 83 = 2719744
11. image.data 파일에서 FS_SIZE 필드 값을 3538944에서 2719744로 변경하십시오.

12. 다음과 같이 /usr 파일 시스템에 의해 사용되는 현재 데이터의 실제 크기를 기반으로 하여 최소한의 파일
시스템 크기(FS_MIN_SIZE)를 계산하십시오.
a) 필요한 최소 파티션 수를 계산하십시오.
이 예에서 사용된 값으로 계산하면 다음과 같습니다.
size_in_use (see step 7a) / PP_SIZE = partitions

1145484 / 16384 = 69.914794921875
b) 이 파티션 수에 필요한 최소 크기를 계산하십시오.
이전 계산 결과를 70으로 반올림하면 계산은 다음과 같습니다.
PP_SIZE * 512 blocks * partitions = FS_MIN_SIZE
16384 * 2 * 70 = 2293760
13. image.data 파일에서 FS_MIN_SIZE 필드를 2290968에서 2293760으로 변경하십시오.

14. 편집사항을 저장하고 편집기를 종료하십시오.
15. rootvg 볼륨 그룹에 없는 모든 파일 시스템이 마운트 해제됩니다.
16. 사용자 정의 볼륨 그룹이 있는 경우에는 다음 명령을 입력하여 연결 변환 해제 및 반출을 수행하십시오.
varyoffvg VGName
exportvg VGName
17. 테이프 드라이브에 테이프가 있으면 다음 명령을 입력하여 전체 시스템 백업을 시작하십시오.
mksysb /dev/rmt0
이러한 유형의 백업에는 /image.data 파일에서 지정한 파일 시스템 크기 정보가 포함되며 이 정보는 나중
에 새 파일 시스템 크기를 사용하여 시스템을 다시 설치할 때 사용됩니다.
참고: 이 백업을 시작하려면 명령행에서 mksysb 명령을 실행해야 합니다. SMIT와 같은 시스템 관리 도구를
사용할 경우, 백업 중 image.data 파일이 새로 작성되고 사용자가 변경한 변경사항을 겹쳐씁니다.
18. 이 백업을 사용하여 현재 시스템 설정값으로 설치 옵션을 설정하고 운영 체제를 다시 설치하십시오.
설치하는 동안 다음 옵션이 제대로 설정되었는지 확인하십시오.
• 맵 사용이 아니오로 설정되어야 합니다.
• 파일 시스템 축소가 아니오로 설정되어야 합니다.
설치 프로시저에 대한 자세한 정보는 시스템 백업 설치를 참조하십시오.
19. 운영 체제가 설치된 후, 시스템을 정규 모드로 재부트하십시오.
이 때 /usr 파일 시스템 크기가 조정됩니다. 하지만 사용자 정의 파일 시스템은 사용할 수 없습니다.
20. 다음 명령을 입력하여 모든 파일 시스템을 마운트하십시오.
mount all
이미 마운트된 파일 시스템에 대해 Device Busy 메시지가 표시될 경우 무시해도 됩니다.

이 때 /usr 파일 시스템 크기가 조정되고, 루트 볼륨 그룹의 사용 가능 공간이 늘어나며, 사용자 파일 시스템을
사용할 수 있습니다.
관련 개념
장치 관리 89
관련 정보
테이프 또는 파일에 루트 볼륨 그룹 백업 작성
/image.data 파일 설명
mkszfile 명령
mksysb 명령
파일 시스템 문제점 해결
파일 시스템에 발생할 수 있는 몇몇 기본 문제점을 다루기 위해 이러한 문제점 해결 메소드를 사용하십시오. 문제
점 해결 정보에 사용자의 문제점이 없는 경우 서비스 담당자에게 문의하십시오.
사용자 정의 파일 시스템 오버플로우 수정

다음 프로시저를 사용하여 오버플로우가 발생하는 사용자 정의 파일 시스템을 수정할 수 있습니다.
1. 이전 백업 파일 및 코어 파일을 제거하십시오. 다음 예제는 *.bak, .*.bak, a.out, core, * 또는 ed.hup
파일을 모두 제거합니다.
find / $ -name "*.bak" -o -name core -o -name a.out -o \
-name "...*" -o -name ".*.bak" -o -name ed.hup $ \
-atime +1 -mtime +1 -type f -print | xargs -e rm -f
2. 파일로 인해 디스크에서 정기적으로 오버플로우가 발생하는 것을 방지하려면 cron 프로세스의 일부로

skulker 명령을 실행하여 필요하지 않은 파일이나 임시 파일을 제거하십시오.
skulker 명령은 /tmp 디렉토리의 파일, 지정된 연한보다 오래된 파일, a.out 파일, 코어 파일 및 ed.hup
파일을 제거합니다. 이 명령은 대개 시스템 사용량이 적은 시간대에 cron 명령에 의해 실행되는 사용통계 절
차의 일부로 매일 실행됩니다.
cron 디먼은 지정된 날짜와 시간에 쉘 명령을 실행합니다. crontab 파일에 있는 지시사항에 따라
skulker와 같은 정기적으로 계획된 명령을 지정할 수 있습니다. crontab 명령을 사용하여 crontab 파일
을 제출하십시오. crontab 파일을 편집하려면 루트 사용자 권한을 가지고 있어야 합니다.
손상된 파일 시스템 수정
파일 시스템 디렉토리 구조에 대한 i-노드 또는 수퍼 블록 정보가 손상될 경우 파일 시스템이 손상될 수 있습니다.
하드웨어와 관련된 문제나 i-노드 또는 수퍼 블록을 직접 액세스하는 프로그램의 손상이 이 문제를 야기하는 원
인일 수 있습니다. 어셈블러 및 C로 작성된 프로그램은 운영 체제를 생략하고 하드웨어에 직접 쓸 수 있습니다.
특정 파일 시스템에 있는 데이터를 찾거나 읽을 수 없으며 데이터에 쓸 수 없을 경우 파일 시스템이 손상되었음을
나타낼 수 있습니다.
손상된 파일 시스템을 수정하려면 문제점을 진단한 후 복구해야 합니다. fsck 명령으로 낮은 레벨의 진단 및 복
구를 수행할 수 있습니다.
손상된 파일 시스템을 수정하는 프로시저는 다음과 같습니다.
1. 루트 권한으로, SMIT 단축 경로 smit unmountfs(하드 디스크 드라이브의 파일 시스템일 경우) 또는 smit
unmntdsk(이동식 디스크의 파일 시스템일 경우) 중 하나를 사용하여 손상된 파일 시스템을 마운트 해제하십
시오.
2. fsck 명령을 실행하여 손상된 파일 시스템에 액세스하십시오. 다음 예제에서는 fsck 명령이 /dev/
myfilelv 장치에 있는 마운트 해제된 파일 시스템을 확인합니다.
fsck /dev/myfilelv
fsck 명령은 일치하지 않는 파일 시스템을 확인하여 대화식으로 복구합니다. 일반적으로 파일 시스템은 일

관성이 있고, fsck 명령은 단순히 파일의 수, 사용된 블록 및 파일 시스템에서 사용 가능 블록에 대해 보고만
합니다. 파일 시스템이 불일치하는 경우에는, fsck 명령은 발견된 불일치에 대한 정보를 표시하고 이를 수리
하기 위한 권한을 요청하는 프롬프트를 표시합니다. fsck 명령은 수리할 때 조심스럽게 하고 유효한 데이터
의 유실을 초래할 수도 있는 조치는 피하려고 합니다. 그러나, 특정 경우에는, fsck 명령은 손상된 파일의 파
괴를 권장합니다.
3. 파일 시스템을 복구할 수 없으면 백업에서 복원하십시오.
주의: 백업에서 파일 시스템을 복원하면 이전에 디스크에 저장되어 있던 파일 시스템이 모두 삭제되고
대체됩니다.
백업에서 파일 시스템을 복원하려면 SMIT 단축 경로 smit restfilesys를 사용하거나 다음 예제와 같이
일련의 명령을 사용하십시오.
mkfs /dev/myfilelv
mount /dev/myfilelv /myfilesys
cd /myfilesys
restore -r
이 예제에서, mkfs 명령은 /dev/myfilelv라는 장치에 새 파일 시스템을 작성한 후 볼륨 레이블, 파일 시스

템 레이블 및 시작 블록을 초기화합니다. mount 명령은 /dev/myfilelv를 myfilesys의 마운트 위치로 설
정하고, restore 명령은 백업에서 파일 시스템을 발췌합니다.
증분식 파일 시스템 백업으로 백업이 작성된 경우, 증분식 백업 레벨 순서로, 예를 들어, 0, 1, 2의 순서로 백업
을 복원해야 합니다. 전체 파일 시스템을 복원하기 위해 smit restfilesys를 사용할 경우, 목표 디렉토
리, 복원 장치(/dev/rfd0 이외의 장치) 및 단일 입력 작업에서 읽을 블록 수를 입력하십시오.
파일 시스템 수퍼 블록에서 손상된 파일 종류 설명자(magic number) 수정

파일 시스템의 수퍼 블록이 손상되면 파일 시스템에 액세스할 수 없습니다. 파일 시스템 수퍼 블록의 손상된 파일
종류 설명자(magic number)를 수정할 수 있습니다.
수퍼 블록의 손상은 대부분 복구할 수 없습니다. 다음 프로시저에서는 손상된 파일 종류 설명자로 인해 문제점이
발생했을 때 JFS 파일 시스템에서 수퍼 블록을 복구하는 방법에 대해 설명합니다. JFS2 파일 시스템에서 1차 수
퍼 블록이 손상된 경우, fsck 명령을 사용하여 2차 수퍼 블록을 자동으로 복사하고 1차 수퍼 블록을 복구하십시
오.
다음 시나리오에서는 /home/myfs가 물리적 볼륨 /dev/lv02에서 JFS 파일 시스템이라고 가정합니다.
1. 다음 명령을 사용하여, 손상되었다고 의심되는 /home/myfs 파일 시스템을 마운트 해제하십시오.
umount /home/myfs
2. 파일 시스템이 손상되었는지를 확인하려면, 파일 시스템에 대해 fsck 명령을 실행하십시오. 예를 들어 다음

과 같습니다.
fsck -p /dev/lv02
수퍼 블록에 손상이 있는 경우 fsck 명령이 다음 메시지 중 하나를 리턴합니다.
fsck: Not an AIXV5 file system
또는
Not a recognized filesystem type
3. 루트 권한으로 od 명령을 사용하여 다음 예제에 표시된 대로 파일 시스템에 대한 수퍼 블록을 표시하십시오.
od -x -N 64 /dev/lv02 +0x1000
여기서 -x 플래그는 16진 형식으로 출력을 표시하고 -N 플래그는 파일에서 출력이 시작되는 위치를 지정하
는 오프셋 매개변수(+)에서 64바이트의 입력 바이트만 형식화하도록 시스템에 지시합니다. 다음은 예제 출력
입니다.
0001000 1234 0234 0000 0000 0000 4000 0000 000a
0001010 0001 8000 1000 0000 2f6c 7633 0000 6c76
0001020 3300 0000 000a 0003 0100 0000 2f28 0383
0001030 0000 0001 0000 0200 0000 2000 0000 0000
0001040
장치 관리 91
위의 출력에서 0x1000(1234 0234)에 있는 손상된 파일 종류 설명자 값(magic value)에 유의하십시오. 파
일 시스템이 작성될 때 모든 디폴트 값이 사용되었다면 파일 종류 설명자(magic number)가 0x43218765가
되어야 합니다. 디폴트값이 재정의되었으면, 파일 종류 설명자(magic number)는 0x65872143이어야합니
다.
4. od 명령을 사용하여 2차 수퍼 블록의 파일 종류 설명자(magic number)가 올바른지 확인하십시오. 예제 명령
및 해당 출력은 다음과 같습니다.
$ od -x -N 64 /dev/lv02 +0x1f000
001f000 6587 2143 0000 0000 0000 4000 0000 000a
001f010 0001 8000 1000 0000 2f6c 7633 0000 6c76
001f020 3300 0000 000a 0003 0100 0000 2f28 0383
001f030 0000 0001 0000 0200 0000 2000 0000 0000
001f040
0x1f000에서 올바른 파일 종류 설명자 값에 주의하십시오.

5. 2차 수퍼 블록을 1차 수퍼 블록으로 복사하십시오. 예제 명령과 출력은 다음과 같습니다.
$ dd count=1 bs=4k skip=31 seek=1 if=/dev/lv02 of=/dev/lv02
dd: 1+0 records in.
dd: 1+0 records out.
6. fsck 명령을 사용하여, 2차 수퍼 블록을 사용함으로써 발생한 일치하지 않는 파일을 정리하십시오. 예를 들

어 다음과 같습니다.
fsck /dev/lv02 2>&1 | tee /tmp/fsck.errs
관련 정보
fsck 명령
od 명령
디스크 오버플로우
디스크 오버플로우는 할당된 공간에 너무 많은 파일이 찰 때 발생합니다. 필요하지 않은 파일을 다수 작성하는 악
성 프로세스가 디스크 오버플로우를 야기하는 원인일 수 있습니다.
다음 프로시저를 수행하여 이 문제점을 정정할 수 있습니다.
참고: 자신의 것이 아닌 프로세스를 제거하려면 루트 사용자 권한을 가지고 있어야 합니다.
문제가 있는 프로세스 식별
다음 프로시저를 사용하여 수동으로 문제가 있는 프로세스를 식별할 수 있습니다.
1. 프로세스 상태를 확인하고 문제를 야기할 수 있는 프로세스를 식별하려면 다음을 입력하십시오.
ps -ef | pg
ps 명령은 프로세스 상태를 표시합니다. -e 플래그는 커널 프로세스를 제외한 모든 프로세스에 대한 정보를

기록하고, f 플래그는 프로세스가 작성될 때 사용된 명령 이름과 매개변수를 포함하여 모든 프로세스를 나열
합니다. pg 명령은 한 번에 한 페이지만 출력하므로 화면의 정보가 너무 빠르게 스크롤되지 않습니다.
CPU 시간과 같은 시스템 자원을 지나치게 많이 사용하는 시스템 프로세스나 사용자 프로세스를 확인하십시
오. 주로 sendmail, routed 및 lpd와 같은 시스템 프로세스가 시스템 자원을 많이 사용하는 악성 프로세스가
됩니다.
2. 예상보다 많은 CPU를 사용하는 사용자 프로세스를 확인하려면 다음을 입력하십시오.
ps -u
3. 문제가 있는 각 프로세스의 프로세스 ID(PID)를 기록하십시오.
프로세스 종료
문제가 있는 프로세스를 종료할 수 있습니다.
다음 절차를 사용하여 문제가 있는 프로세스를 종료하십시오.
1. 다음을 입력하여, 문제를 일으키는 프로세스를 종료하십시오.
kill -9 PID
여기서 PID는 문제가 있는 프로세스의 ID입니다.

2. 다음을 입력하여, 이 프로세스에서 작성 중이었던 파일을 제거하십시오.
rm file1 file2 file3
여기서 file1 file2 file3은 프로세스와 관련된 파일의 이름을 나타냅니다.
프로세스를 종료하지 않고 파일 공간 다시 확보
활성 파일에 할당된 블록을 프로세스를 종료하지 않고 다시 확보하려면 다른 명령의 출력을 이 파일로 방향 재지
정하십시오. 데이터 방향 재지정으로 인해 파일이 절단되고 메모리 블록이 다시 확보됩니다.
활성 파일이 파일 시스템에서 제거될 경우, 파일 닫기 프로세스의 결과로 또는 파일을 연 프로세스가 종료되어 마
지막 열기 참조가 제거될 때까지는 이 파일에 할당된 블록이 할당된 상태로 남아 있습니다. 악성 프로세스가 파일
에 쓰고 있는데 이 파일이 제거되면, 이 프로세스가 종료될 때까지 파일에 할당된 블록이 해제되지 않습니다.
$ ls -l
total 1248
-rwxrwxr-x 1 web staff 1274770 Jul 20 11:19 datafile
$ date > datafile
$ ls -l
total 4
-rwxrwxr-x 1 web staff 29 Jul 20 11:20 datafile
date 명령의 출력이 datafile 파일의 이전 컨텐츠를 대체했습니다. 절단된 파일에 대해 보고된 블록은 1248>
에서 4까지의 크기 차이를 반영합니다. 악성 프로세스가 계속해서 새로 절단된 이 파일에 정보를 추가할 경우 다
음 ls 명령이 다음과 같은 결과를 생성합니다.
$ ls -l
total 8
-rxrwxr-x 1 web staff 1278866 Jul 20 11:21 datefile
datafile 파일의 크기는 악성 프로세스가 추가한 크기를 반영하지만 할당된 블록 수는 적습니다. 지금은
datafile 파일 안에 공간이 있습니다. 파일 공간은 파일에서 디스크 블록이 할당되지 않은 영역입니다.
/(루트) 오버플로우
루트 파일 시스템(/)이 꽉 차면 다음을 확인하십시오.
• 다음 명령을 사용하여 /etc/security/failedlogin 파일의 내용을 읽으십시오.
who /etc/security/failedlogin
TTY를 너무 빠르게 재작성해서 실패한 로그인 항목이 생길 수 있습니다. 출력을 읽거나 저장한 후 파일을 지우
려면 다음 명령을 실행하십시오.
cp /dev/null /etc/security/failedlogin
• /dev 디렉토리에서 잘못 입력된 장치 이름이 있는지 확인하십시오. 장치 이름이 잘못 입력된 경우, 예를 들어,
rmt0 대신 rmto가 입력된 경우, rmto라는 /dev에 파일이 작성됩니다. 일반적으로 전체 루트 파일 시스템이
실패하기 전에 채워질 때까지 명령이 계속 진행됩니다. /dev는 루트(/) 파일 시스템의 일부입니다. 장치가 아
닌 항목, 즉, 주 번호나 부 번호가 없는 항목을 찾으십시오. 이러한 상황이 발생했는지 확인하려면 다음 명령을
사용하십시오.
cd /dev
ls -l | pg
원래 파일의 파일 크기가 표시되는 위치에 장치 파일이 쉼표로 구분된 두 개의 번호와 함께 나타납니다. 예를

들어 다음과 같습니다.
crw-rw-rw- 1 root system 12,0 Oct 25 10:19 rmt0
장치 관리 93
다음 예제와 같이 파일 이름이나 크기 위치에 유효하지 않은 장치가 표시될 경우, 연관된 파일을 제거하십시오.
crw-rw-rw- 1 root system 9375473 Oct 25 10:19 rmto
참고:
– /dev 디렉토리의 유효한 장치 이름은 제거하지 마십시오. 연관된 파일의 크기가 500바이트보다 크면 장치
가 유효하지 않음을 나타냅니다.
– 시스템 감사 기능이 실행 중일 경우, 디폴트 /audit 디렉토리가 매우 빠르게 차므로 주의를 기울여야 합니
다.
• find 명령으로 제거할 수 있는 대형 파일이 있는지 확인하십시오. 예를 들어, 루트(/) 디렉토리에서 1MB보다
큰 파일을 모두 찾으려면 다음 명령을 사용하십시오.
find / -xdev -size +2048 -ls |sort -r -n +6
이 명령은 1MB보다 큰 파일을 모두 찾은 다음 크기가 가장 큰 파일부터 역순으로 파일을 분류합니다. find 명령

에 사용할 수 있는 -newer와 같은 다른 플래그를 이와 같은 검색에서 사용하면 도움이 될 수도 있습니다. 자세
한 정보는 find 명령에 대한 설명을 참조하십시오.
참고: 루트 디렉토리를 확인할 때 /dev 디렉토리에 있는 장치의 주 번호와 부 번호가 실제 파일 및 파일 크기와
교대로 배치됩니다. 쉼표로 구분된 주 번호와 부 번호는 무시할 수 있습니다.
어떤 파일이든 제거하기 전에 다음 명령을 사용하여 현재 사용자 프로세스에서 파일을 사용하고 있지 않은지
확인하십시오.
fuser filename
여기서 filename은 의심이 가는 대형 파일의 이름입니다. 파일 제거 시 파일이 열려 있으면 디렉토리 목록에서

만 파일이 제거됩니다. 이 파일에 할당된 블록은 해당 파일을 사용 중인 프로세스가 종료될 때까지 해제되지 않
습니다.
/var 파일 시스템의 오버플로우 해결

/var 파일 시스템이 꽉 차면 다음을 확인하십시오.
• find 명령을 사용하여 /var 디렉토리에서 대형 파일을 찾을 수 있습니다. 예를 들어 다음과 같습니다.
find /var -xdev -size +2048 -ls| sort -r +6
자세한 정보는 find 명령에 대한 설명을 참조하십시오.

• /var/tmp에서 오래되거나 쓸모 없는 파일이 있는지 확인하십시오.
• 모든 로그인, rlogin 및 Telnet 세션이 기록되는 /var/adm/wtmp 파일의 크기를 확인하십시오. 시스템 사용통
계가 실행되고 있지 않으면 로그 크기가 무한정 커집니다. 시스템 사용통계는 매일 밤 로그를 지웁니
다. /var/adm/wtmp 파일을 지우거나 편집하여 오래되어서 더 이상 필요하지 않은 파일을 제거할 수 있습니
다. 파일을 지우려면 다음 명령을 사용하십시오.
cp /dev/null /var/adm/wtmp
/var/adm/wtmp 파일을 편집하려면 먼저 다음 명령을 사용하여 파일을 임시로 복사하십시오.
/usr/sbin/acct/fwtmp < /var/adm/wtmp >/tmp/out
/tmp/out 파일을 편집하여 원하지 않는 항목을 제거한 후, 다음 명령을 사용하여 원래 파일을 대체하십시오.
/usr/sbin/acct/fwtmp -ic < /tmp/out > /var/adm/wtmp
• 다음 절차를 사용하여 /var/adm/ras 디렉토리의 오류 로그를 지우십시오. 수동으로 지우지 않으면 오류 로

그가 지워지지 않습니다.
참고: cp /dev/null 명령을 사용하여 오류 로그를 지우지 마십시오. errlog 파일의 길이가 0이 되면 운영
체제의 오류 로깅 기능이 사용 불가능하게 되어 백업에서 파일을 대체해야 합니다.
1. 다음 명령을 사용하여 오류 디먼을 정지하십시오.
/usr/lib/errstop
2. 다음 명령 중 하나를 사용하여, 오류 로그 파일을 제거하거나 다른 파일 시스템으로 이동하십시오.

rm /var/adm/ras/errlog
또는
mv /var/adm/ras/errlog filename
여기서 filename은 이동할 오류 로그 파일의 이름입니다.

참고: 오류 로그 파일을 제거하면 내역 오류 데이터가 삭제됩니다.
3. 다음 명령을 사용하여 오류 디먼을 재시작하십시오.
/usr/lib/errdemon
참고: cron의 다음 항목을 실행하여 오류 로그를 제한하는 것을 고려해 보십시오.
0 11 * * * /usr/bin/errclear -d S,O 30
0 12 * * * /usr/bin/errclear -d H 90
• 이 디렉토리에 있는 trcfile 파일의 크기가 큰지 확인하십시오. 이 파일의 크기가 크고 현재 추적이 실행되고

있지 않을 경우, 다음 명령을 사용하여 이 파일을 제거할 수 있습니다.
rm /var/adm/ras/trcfile
• 덤프 장치가 hd6(디폴트)으로 설정된 경우, /var/adm/ras 디렉토리에 여러 개의 vmcore* 파일이 있을 수

있습니다. 이들 파일의 날짜가 오래되었거나 파일을 유지하고 싶지 않은 경우, rm 명령을 사용하여 파일을 제
거할 수 있습니다.
• 큐 서브시스템 파일이 포함된 /var/spool 디렉토리를 확인하십시오. 다음 명령을 사용하여 큐 서브시스템을
지우십시오.
stopsrc -s qdaemon
rm /var/spool/lpd/qdir/*
rm /var/spool/lpd/stat/*
rm /var/spool/qdaemon/*
startsrc -s qdaemon
• 사용통계 레코드가 포함된 /var/adm/acct 디렉토리를 확인하십시오. 사용통계가 실행되고 있으면 이 디렉

토리에 여러 개의 대형 파일이 포함될 수도 있습니다.
• /var/preserve 디렉토리에서 종료된 vi 세션이 있는지 확인하십시오. 일반적으로 이러한 파일은 제거하는
것이 안전합니다. 세션을 복구하려는 경우 vi -r 명령을 사용하여 복구 가능한 모든 세션을 나열할 수 있습니
다. 특정 세션을 복구하려면 vi -r filename을 사용하십시오.
• su 명령의 사용 시도 횟수와 각 시도가 성공했는지 여부가 기록되는 /var/adm/sulog 파일을 수정하십시오.
이 파일은 플랫 파일이며 즐겨찾기 편집기로 보고 수정할 수 있습니다. 이 파일이 제거되면 다음에 시도되는
su 명령에 의해 다시 작성됩니다. snmpd 디먼의 이벤트가 기록되는 /var/tmp/snmpd.log를 수정하십시
오. 이 파일이 제거되면 snmpd 디먼에 의해 다시 작성됩니다.
참고: 무한정 커지지 않도록 /var/tmp/snmpd.log 파일의 크기를 제한할 수 있습니다. /etc/
snmpd.conf 파일을 편집하여 크기와 관련된 섹션에서 숫자(바이트 단위)를 변경하십시오.
기타 파일 시스템 수정 및 일반 검색 기술
-size 플래그와 함께 find 명령을 사용하여 대형 파일을 찾을 수 있습니다. 또한 파일 시스템이 최근에 오버플로
우된 경우 -newer 플래그를 사용하여 최근에 수정된 파일을 찾을 수 있습니다.
-newer 플래그로 찾을 파일을 작성하려면 다음과 같이 touch 명령을 사용하십시오.
touch mmddhhmm filename
장치 관리 95
여기서 mm은 월, dd는 날짜, hh는 시간(24시간 형식), mm은 분, 그리고 filename은 touch 명령으로 작성할 파
일의 이름입니다.
touch 명령으로 찾은 파일을 작성한 후에는 다음 명령을 사용하여 새 대형 파일을 찾을 수 있습니다.
find /filesystem_name -xdev -newer touch_filename -ls
다음 예제와 같이 find 명령을 사용하여 지난 24시간 동안 변경된 파일을 찾을 수도 있습니다.
find /filesystem_name -xdev -mtime 0 -ls
마운트
마운팅은 특정 위치에서 파일 시스템, 파일, 디렉토리, 장치 및 특수 파일을 사용 가능하게 만듭니다. 파일 시스템
은 마운팅을 통해서만 액세스할 수 있게 만들 수 있습니다.
mount 명령은 지정된 디렉토리에 파일 시스템을 연결하도록 운영 체제에 지시합니다.
마운트할 파일 또는 디렉토리에 대한 액세스 권한이 있고 해당 마운트 위치에 대한 쓰기 권한이 있으면 파일이나
디렉토리를 마운트할 수 있습니다. 시스템 그룹의 멤버도 장치 마운트(장치 또는 파일 시스템이 디렉토리에 마운
트됨) 또는 /etc/filesystems 파일에 설명된 마운트를 수행할 수 있습니다. 루트 사용자 권한을 가진 사용자
는 명령행에 장치와 디렉토리를 지정하여 원하는 대로 파일 시스템을 마운트할 수 있습니다. /etc/
filesystems 파일을 사용하면 시스템 초기화 시 마운트가 자동 수행되도록 정의할 수 있습니다. mount 명령
은 시스템 시작 후 마운트할 경우 사용합니다.
마운트 위치
마운트 위치는 새 파일 시스템, 디렉토리 또는 파일에 액세스하는 데 사용할 수 있는 디렉토리나 파일입니다. 파
일 시스템이나 디렉토리를 마운트하려면 마운트 위치가 디렉토리여야 하고, 파일을 마운트하려면 마운트 위치가
파일이어야 합니다.
일반적으로, 파일 시스템, 디렉토리 또는 파일은 빈 마운트 위치에 마운트되지만 반드시 그래야 하는 것은 아닙니
다. 마운트 위치로 사용되는 파일이나 디렉토리에 데이터가 포함되어 있을 경우, 여기에 다른 파일이나 디렉토리
가 마운트되는 동안에는 데이터에 액세스할 수 없습니다. 결국 마운트된 파일이나 디렉토리는 이 디렉토리에 이
전에 있었던 데이터를 겹쳐씁니다. 마운트된 원래 디렉토리나 파일은 마운트가 취소되면 다시 액세스할 수 있습
니다.
파일 시스템이 디렉토리에 마운트된 경우, 마운트된 파일 시스템의 루트 디렉토리 권한이 해당 마운트 위치의 권
한보다 우선 적용됩니다. 하나의 예외는 마운트된 디렉토리에서 ..(이중점) 상위 디렉토리 항목과 관련됩니다. 운
영 체제가 새 파일 시스템에 액세스할 수 있으려면 마운트 위치 상위 디렉토리의 정보가 사용 가능해야 합니다.
예를 들어, 현재 작업 디렉토리가 /home/frank이면, cd .. 명령은 작업 디렉토리를 /home으로 변경합니
다. /home/frank 디렉토리가 마운트된 파일 시스템의 루트이면, 운영 체제는 cd .. 명령이 성공하기 위해서
는 /home/frank 디렉토리에서 상위 디렉토리 정보를 찾아야 합니다.
상위 디렉토리 정보를 필요로 하는 명령이 성공하려면 사용자가 마운트된 디렉토리에 대한 검색 권한을 가지고
있어야 합니다. 마운트된 디렉토리에 대한 검색 권한을 부여하는 데 실패하면 예측할 수 없는 결과가 발생할 수
있습니다. 이는 특히 마운트된 디렉토리에 대한 권한이 가시적이지 않기 때문입니다. 일반적으로 발생할 수 있는
문제는 pwd 명령이 실패하는 것입니다. 마운트된 디렉토리에 대한 검색 권한이 없으면 pwd 명령이 다음 메시지
를 리턴합니다.
pwd: Permission denied
항상 마운트된 디렉토리에 대한 권한을 적어도 111 이상으로 설정하면 이 문제를 방지할 수 있습니다.
파일 시스템, 디렉토리 및 파일 마운트

마운트 유형에는 원격 마운트와 로컬 마운트 두 가지가 있습니다. 원격 마운트는 전화통신 회선을 통해 데이터가
전송되는 원격 시스템에서 수행됩니다. NFS(Network File System)와 같은 원격 파일 시스템의 경우, 파일 시스
템을 마운트하려면 먼저 파일을 반출해야 합니다. 로컬 마운트는 로컬 시스템에서 수행되는 마운트입니다.
각 파일 시스템은 서로 다른 장치(논리적 볼륨)와 연관됩니다. 파일 시스템을 사용할 수 있으려면 파일 시스템이
기존 디렉토리 구조(루트 파일 시스템 또는 이미 연결되어 있는 다른 파일 시스템)에 연결되어 있어야 합니다.
mount 명령을 사용하여 연결할 수 있습니다.
여러 경로에서 동일한 파일 시스템, 디렉토리 또는 파일에 액세스할 수 있습니다. 예를 들어, 데이터베이스는 하
나인데 이 데이터베이스를 사용하는 사용자가 여러 명일 경우 동일한 데이터베이스를 여러 곳에 마운트하면 유
용합니다. 추적 및 작업 구분을 위해 각 마운트는 고유한 이름과 비밀번호를 가져야 합니다. 동일한 파일 시스템
을 다양한 마운트 위치에 마운트하면 됩니다. 예를 들어, /home/server/database에서 /home/user1, /
home/user2 및 /home/user3로 지정된 마운트 위치로 마운트할 수 있습니다.
/home/server/database /home/user1
기호 링크를 사용하면 다양한 사용자가 동일한 파일 시스템, 디렉토리 또는 파일을 사용하도록 만들 수 있습니다.
기호 링크는 ln -s 명령을 사용하여 작성할 수 있습니다. 여러 사용자를 중앙의 파일에 링크하면 사용자가 파일
에 액세스할 때마다 파일의 모든 변경사항이 반영됩니다.
자동 마운트 제어
마운트는 시스템 초기화 중 자동으로 수행되도록 설정할 수 있습니다.
자동 마운트에는 두 가지 유형이 있습니다. 첫 번째 유형은 시스템을 부트하고 실행하는 데 필요한 마운트로 구성
됩니다. 이러한 파일 시스템은 부트 프로세스에 의해 명시적으로 마운트됩니다. /etc/filesystems 파일에서
이러한 파일 시스템의 스탠자는 mount = automatic로 설정됩니다. 두 번째 자동 마운트 유형은 사용자 제어
자동 마운트입니다. 이러한 파일 시스템은 /etc/rc 스크립트가 mount all 명령을 실행할 때 이 스크립트에
의해 마운트됩니다. /etc/filesystems에서 사용자 제어 자동 마운트의 스탠자는 mount = true로 설정됩
니다.
/etc/filesystems 파일은 자동 마운트를 제어합니다. 자동 마운트는 한 번에 한 마운트 지점씩 계층적으로
수행됩니다. 변경 및 재배열이 가능한 특정 순서로 마운트를 배치할 수도 있습니다. /etc/filesystems 파일
에 대한 자세한 정보는 /etc/filesystems의 내용을 참조하십시오.
/etc/filesystems 파일은 마운트당 하나씩 있는 스탠자들로 구성됩니다. 스탠자는 스탠자에 해당하는 파일
시스템의 속성 및 파일 시스템이 마운트되는 방식을 설명합니다. 시스템에서는 파일 시스템을 /etc/
filesystems 파일에 표시되는 순서대로 마운트합니다. 다음은 /etc/filesystems file의 스탠자 예제
입니다.
/:
dev=/dev/hd4
vol="root"
mount=automatic
check=false
free=true
vfs=jfs
log=/dev/hd8
type-bootfs
/home:
dev=/dev/hd1
vfs=jfs
log=/dev/hd8
mount=true
check=true
vol="/home"
free=false
/usr:
/dev=/dev/hd2
vfs=jfs
log=/dev/hd8
mount=automatic
check=false
type=bootfs
vol="/usr"
free=false
마운트가 발생하는 순서를 제어하도록 /etc/filesystems 파일을 편집할 수 있습니다. 마운트에 실패하
면 /etc/filesystems 파일에 정의된 다음 마운트 중 하나가 계속해서 마운트됩니다. 예를 들어, /home 파일
시스템의 마운트에 실패하면 /usr 파일 시스템의 마운트가 계속해서 마운트됩니다. 입력 오류, 종속성 또는 시
스템 문제 등의 이유로 마운트에 실패할 수 있습니다.
장치 관리 97
디스크 없는 워크스테이션을 위한 마운트 보안
디스크 없는 워크스테이션이 서버에서 해당 /dev 디렉토리를 마운트하려면 원격 시스템에 장치 특수 파일을 작
성하고 이 파일에 액세스할 수 있어야 합니다. 서버는 클라이언트용 장치 특수 파일과 서버용 장치 특수 파일을
구별할 수 없으므로, 서버의 사용자가 클라이언트의 장치 특수 파일을 사용하여 서버의 물리적 장치에 액세스할
수도 있습니다.
예를 들어, tty의 소유권은 tty를 사용하는 사용자로 자동 설정됩니다. 클라이언트와 서버에서 사용자 ID가 동일
하지 않을 경우, 서버의 권한이 없는 한 사용자가 서버의 다른 사용자가 사용하고 있는 tty에 액세스할 수 있게 됩
니다.
클라이언트의 권한이 있는 사용자는 장치 특수 파일을 작성하여 서버의 물리적 장치에 대응시킴으로써 장치에
액세스하는 데 별도의 권한이 필요하지 않도록 만들 수 있습니다. 그런 다음 이 사용자가 서버의 권한 없는 계정
을 사용하고 새로 작성된 장치 특수 파일을 사용하여, 보호된 장치에 액세스할 수 있습니다.
클라이언트와 서버에서 setuid와 setgid 프로그램을 사용할 경우에도 이와 비슷한 보안 문제가 발생할 수 있
습니다. 정상적으로 작동하려면 디스크 없는 클라이언트가 서버에서 setuid 및 setgid 프로그램을 작성하고
실행할 수 있어야 합니다. 앞에서도 설명했듯이 서버는 서버용 프로그램과 클라이언트용 프로그램을 구별할 수
없습니다.
뿐만 아니라, 서버와 클라이언트 간에 사용자 ID와 그룹 ID가 일치하지 않으므로 서버의 사용자가 서버 사용자용
이 아닌 기능을 사용하여 프로그램을 실행하게 될 수도 있습니다.
setuid와 setgid 프로그램 및 장치 특수 파일은 이들이 작성된 시스템에서만 사용할 수 있어야 하는데 바로
이 때문에 문제가 발생합니다.
이 문제를 해결하려면 mount 명령에 보안 옵션을 사용하여 이들 오브젝트를 사용해야 합니다. 이러한 옵션
은 /etc/filesystems 파일의 스탠자에도 사용될 수 있습니다.
mount 명령의 nosuid 옵션은 결과적으로 마운트된 파일 시스템을 통해 액세스된 setuid 및 setgid 프로그
램이 실행되지 않도록 방지합니다. 이 옵션은 다른 호스트(예: 디스크 없는 클라이언트용으로 반출된 호스트)에
서만 사용되도록 특정 호스트에 마운트될 모든 파일 시스템에 사용됩니다.
mount 명령의 nodev 옵션은 결과적으로 마운트된 파일 시스템을 통해 액세스된 장치 특수 파일을 사용하여 장
치를 열 수 없도록 방지합니다. 이 옵션은 다른 호스트(예: 디스크 없는 클라이언트용으로 반출된 호스트)에서만
사용되도록 마운트될 모든 파일 시스템에 사용됩니다.
일반적으로, 서버의 사용자는 /export 디렉토리에 대한 액세스 권한을 가지고 있지 않습니다.
/export/root 디렉토리 반출
/export/root 디렉토리는 읽기/쓰기 권한과 함께 반출되어야 하며 서버의 루트 사용자는 이 디렉토리에
대한 액세스 권한을 가지고 있어야 합니다. 하지만 mount 명령의 다음 옵션과 함께 이 디렉토리를 마운트할
항목 설명
nosuid 서버의 사용자가 클라이언트의 setuid 프로그램을 실행할 수 없게 합니다.
nodev 사용자가 클라이언트의 장치 특수 파일을 사용하여 서버 장치에 액세스할 수 없게 합니다.
이러한 옵션을 사용하여 /export/root 디렉토리를 마운트하는 방법 대신, 서버에서 실행 중인 사용자에

게 /export/root 디렉토리에 대한 어떠한 권한도 부여하지 않는 방법을 이용할 수도 있습니다.
/export/exec 디렉토리 반출
/export/exec 디렉토리는 읽기 전용 권한과 함께 반출되며 루트 액세스를 제공해야 합니다. 하지만
mount 명령의 다음 옵션과 함께 이 디렉토리를 마운트할 수도 있습니다.
항목 설명
nosuid 서버의 사용자가 클라이언트의 setuid 프로그램을 실행할 수 없게 합니다. 서버 /usr 디렉토
리를 반출할 경우, nousid 옵션을 사용할 수 없습니다.
/export/share 디렉토리 반출
/export/share 디렉토리는 읽기 전용 권한과 함께 반출되며 루트 액세스를 제공해야 합니다. 이 디렉토리
에는 데이터만 포함되고 실행 파일이나 장치는 포함되지 않으므로 마운트 보안 옵션을 사용할 필요가 없습니
다.
/export/home 디렉토리 반출
다음과 같은 여러 가지 방법으로 사용자 /home 디렉토리를 마운트할 수 있습니다.
• 클라이언트 /home 디렉토리에 /export/home/Clienthostname 디렉토리를 마운트할 수 있습니다. 이
경우, 클라이언트는 읽기/쓰기 권한을 가지고 루트 사용자는 액세스 권한을 가집니다. 시스템 보안을 위해,
mount 명령에 다음 옵션을 지정하여 /export/home 디렉토리를 마운트하십시오.
항목 설명
• 클라이언트 /home 디렉토리에 서버 /home 디렉토리를 마운트할 수 있습니다. 이 경우, /home 디렉토리
가 읽기/쓰기 권한과 함께, 루트 액세스 없이 반출됩니다. 시스템 보안을 위해, mount 명령에 nosuid 및
nodev 옵션을 지정하여 서버와 클라이언트 모두의 /home 디렉토리를 마운트하십시오.
• 또는 클라이언트에서, 클라이언트 /home/Username 디렉토리에 서버의 각 /home/UserName 디렉토리
를 마운트하여 사용자가 여러 시스템에 로그인하면서 동시에 자신의 홈 디렉토리에 액세스할 수 있게 만들
수 있습니다. 이 경우, mount 명령에 nousid 및 nodev 옵션이 지정된 채 서버와 클라이언트의 /home/
Username 디렉토리가 마운트됩니다.
/export/swap 디렉토리 반출
읽기/쓰기 권한 및 루트 액세스 권한과 함께 /export/swap/Clienthostname 파일을 반출합니다. 보안 수
단이 필요하지 않습니다. 서버의 사용자는 /export/swap/Clienthostname 파일에 대해 어떠한 액세스 권
한도 가지지 않습니다.
디스크 없는 마운트
디스크 없는 워크스테이션의 파일 시스템은 서버 /exports 디렉토리에서 마운트되지만, 디스크 없는 시스템에
는 이 파일 시스템이 독립형 시스템의 파일 시스템과 동일하게 인식됩니다.
다음은 서버 반출과 디스크 없는 워크스테이션 마운트 위치 간의 관계를 보여 줍니다.
서버 반출 디스크 없는 반입
/export/root/HostName / (root)
/export/exec/SPOTName /usr
/export/home/HostName /home
/export/share /usr/share
/export/dump 디스크 없는 클라이언트가 덤프 공간으로 사용함
/export/swap 디스크 없는 클라이언트가 원격 페이징 공간으로 사용함
/export 디렉토리에 대한 자세한 정보는 78 페이지의 『/export 디렉토리』의 내용을 참조하십시오.

일반적으로, 서버의 사용자는 /export 디렉토리에 대한 액세스 권한을 가지고 있지 않습니다.
/export/root 디렉토리 반출
/export/root 디렉토리는 읽기/쓰기 권한과 함께 반출되어야 하며 서버의 루트 사용자는 이 디렉토리에
대한 액세스 권한을 가지고 있어야 합니다. 하지만 mount 명령의 다음 옵션과 함께 이 디렉토리를 마운트할
장치 관리 99
항목 설명
이러한 옵션을 사용하여 /export/root 디렉토리를 마운트하는 방법 대신, 서버에서 실행 중인 사용자에

게 /export/root 디렉토리에 대한 어떠한 권한도 부여하지 않는 방법을 이용할 수도 있습니다.
/export/exec 디렉토리 반출
/export/exec 디렉토리는 읽기 전용 권한과 함께 반출되며 루트 액세스를 제공해야 합니다. 하지만
mount 명령의 다음 옵션과 함께 이 디렉토리를 마운트할 수도 있습니다.
항목 설명
nosuid 서버의 사용자가 클라이언트의 setuid 프로그램을 실행할 수 없게 합니다. 서버 /usr 디렉토
리를 반출할 경우, nousid 옵션을 사용할 수 없습니다.
/export/share 디렉토리 반출
/export/share 디렉토리는 읽기 전용 권한과 함께 반출되며 루트 액세스를 제공해야 합니다. 이 디렉토리
에는 데이터만 포함되고 실행 파일이나 장치는 포함되지 않으므로 마운트 보안 옵션을 사용할 필요가 없습니
다.
/export/home 디렉토리 반출
다음과 같은 여러 가지 방법으로 사용자 /home 디렉토리를 마운트할 수 있습니다.
• 클라이언트 /home 디렉토리에 /export/home/Clienthostname 디렉토리를 마운트할 수 있습니다. 이
경우, 클라이언트는 읽기/쓰기 권한을 가지고 루트 사용자는 액세스 권한을 가집니다. 시스템 보안을 위해,
mount 명령에 다음 옵션을 지정하여 /export/home 디렉토리를 마운트하십시오.
항목 설명
• 클라이언트 /home 디렉토리에 서버 /home 디렉토리를 마운트할 수 있습니다. 이 경우, /home 디렉토리
가 읽기/쓰기 권한과 함께, 루트 액세스 없이 반출됩니다. 시스템 보안을 위해, mount 명령에 nosuid 및
nodev 옵션을 지정하여 서버와 클라이언트 모두의 /home 디렉토리를 마운트하십시오.
• 또는 클라이언트에서, 클라이언트 /home/Username 디렉토리에 서버의 각 /home/UserName 디렉토리
를 마운트하여 사용자가 여러 시스템에 로그인하면서 동시에 자신의 홈 디렉토리에 액세스할 수 있게 만들
수 있습니다. 이 경우, mount 명령에 nousid 및 nodev 옵션이 지정된 채 서버와 클라이언트의 /home/
Username 디렉토리가 마운트됩니다.
/export/dump 디렉토리 반출
읽기/쓰기 권한 및 루트 액세스 권한과 함께 /export/dump/Clienthostname 디렉토리를 반출합니다. 서
버의 사용자는 /export/dump/Clienthostname 파일에 대해 어떠한 액세스 권한도 가지지 않습니다.
/export/swap 디렉토리 반출
읽기/쓰기 권한 및 루트 액세스 권한과 함께 /export/swap/Clienthostname 파일을 반출합니다. 보안 수
단이 필요하지 않습니다. 서버의 사용자는 /export/swap/Clienthostname 파일에 대해 어떠한 액세스 권
한도 가지지 않습니다.
파일 시스템 유형
AIX 에서는 다양한 파일 시스템 유형을 지원합니다.
여기에는 다음이 포함됩니다.

저널 파일 시스템(JFS) 또는 확장 저널 파일 시스템(JFS2)
파일 시스템 의미 전체를 지원합니다. 이런 파일 시스템은 구조적 일관성을 유지하기 위해 데이터베이스 저
널링 기술을 사용합니다. 이 저널링 기술 사용으로 파일 시스템이 비정상적으로 정지될 때 파일 시스템이 손
상되는 것을 막아줍니다.
각 JFS 또는 JFS2는 별도의 논리적 볼륨에 상주합니다. 운영 체제는 초기화 중 파일 시스템을 마운트합니다.
이러한 다양한 파일 시스템 구성은 백업, 복원 및 복구와 같은 시스템 관리 기능에 유용한데, 파일 트리의 특
정 부분에 대해서만 작업을 수행할 수 있도록 해당 부분을 격리시키기 때문입니다.
JFS는 파일 시스템 명령 전체를 지원하는 기본 파일 시스템 유형입니다.
JFS2는 파일 시스템 명령 전체를 지원하는 기본 파일 시스템 유형입니다.
JFS2는 대형 파일 및 대형 파일 시스템을 지원하도록 설계되었다는 점에서 JFS와는 다릅니다.
NFS(Network File System)
사용자가 원격 컴퓨터에 있는 파일과 디렉토리에 액세스하여 이들이 로컬 위치에 있는 것처럼 사용할 수 있
게 해 주는 분산 파일 시스템입니다. 예를 들어, 사용자는 운영 체제 명령을 사용하여 원격 파일 및 디렉토리
의 파일 속성을 작성, 제거, 읽기, 쓰기 및 설정할 수 있습니다.
CD-ROM 파일 시스템(CDRFS)
정상 파일 시스템 인터페이스(열기, 읽기 및 닫기)를 통한 CD-ROM 내용 액세스를 허용합니다.
DVD-ROM 파일 시스템(UDFS)
정상 파일 시스템 인터페이스를 통한 DVD 내용 액세스를 허용합니다.
JFS 및 JFS2
저널 파일 시스템(JFS)과 확장 저널 파일 시스템(JFS2)은 기본 운영 체제(BOS)에 빌드되어 있습니다. 두 파일 시
스템 유형은 모두 저장과 검색을 위해 AIX 논리적 볼륨 관리자가 사용하는 구조에 해당 파일 시스템의 파일과 디
렉토리 데이터를 링크합니다.
JFS2는 64-비트 커널 및 대형 파일을 수용할 수 있도록 설계되었다는 점이 다릅니다.
다음 절에서는 이 두 파일 시스템에 대해 설명합니다. 별도로 명시되어 있지 않으면, 다음 절의 내용은 JFS와
JFS2에 동일하게 적용됩니다.
JFS 및 JFS2 기능
확장 저널 파일 시스템(JFS2)은 기존 저널 파일 시스템(JFS)보다 훨씬 큰 파일을 저장하기 위한 기능을 제공하는
파일 시스템입니다.
JFS 또는 JFS2를 구현하도록 선택할 수 있습니다. JFS2는 AIX 6.1에서 기본 파일 시스템입니다.
참고: JFS2 파일 시스템과는 달리 JFS 파일 시스템에서는 여러 유형의 파일로 구성된 디렉토리에 link() API를
사용할 수 없습니다. 이러한 제한으로 인해 JFS 파일 시스템에서는 올바르게 작동하는 애플리케이션이 JFS2 파
일 시스템에서는 실패할 수도 있습니다.
다음 표는 JFS 및 JFS2 기능의 요약을 제공합니다.
기능 JFS2 JFS
프래그먼트 및 블록 크기 블록 크기(바이트): 512, 1024, 프래그먼트 크기(바이트): 512,
2048, 4096 1024, 2048, 4096
최대 파일 시스템 크기(테라바이 최대 파일 시스템 크기(기가바이
트): 4, 8, 16, 32 트): 128, 256, 512, 1024
최대 파일 시스템 크기 32TB 1TB

최소 파일 시스템 크기 16MB 적용할 수 없음
최대 파일 크기 16TB 대략 63.876GB
i-node 수 동적, 디스크 공간의 제한을 받음 고정, 파일 시스템 작성 시 설정됨
디렉토리 조직 B 트리 선형(L)
장치 관리 101
기능 JFS2 JFS
압축 아니오 예
할당량 예 예
오류 로깅 예 예
참고:
1. 32-비트 커널과 함께 사용할 경우, 최대 파일 크기와 최대 파일 시스템 크기가 1TB에서 물리적 파티션 크기를
뺀 크기로 제한됩니다. 예를 들어, 볼륨 그룹의 물리적 파티션 크기가 64MB일 경우, 최대 파일 시스템 크기는
1TB에서 64MB를 뺀, 즉, 1048576MB에서 64MB를 뺀 1048512MB입니다. 이는 32-비트 커널을 사용할 경
우 논리적 볼륨의 최대 크기에 따르는 기본적인 제한 때문입니다.
2. JFS2는 표준 AIX 오류 로그 스키마를 지원합니다. AIX 오류 로깅에 대한 자세한 정보는 일반 프로그래밍 개
념: 프로그램 작성 및 디버깅에서 Error-Logging Overview를 참조하십시오.
JFS 및 JFS2 디스크 공간 단편화

대부분의 UNIX 파일 시스템은 파일 및 디렉토리의 논리적 분할에 사용된 논리적 블록과 크기가 동일한 단위로
연속 디스크 공간을 할당합니다. 일반적으로 이러한 할당 단위를 디스크 블록이라고 하며, 파일 또는 디렉토리의
단일 논리적 블록 내에 포함된 데이터를 저장하는 데 단 하나의 디스크 블록만 독점적으로 사용됩니다.
비교적 큰 논리적 블록 크기(예: 4096바이트)를 사용하고, 논리적 블록과 크기가 동일하게 디스크 블록을 할당을
유지하면 단일 파일 시스템 작업으로 수행되어야 하는 디스크 입출력 작업의 수를 줄이는 데 도움이 됩니다. 이
경우, 파일이나 디렉토리의 데이터가 다수의 작은 디스크 블록이 아닌 소수의 크기가 큰 디스크 블록에 있는 디스
크에 저장됩니다. 예를 들어, 크기가 4096바이트이거나 이보다 작은 파일에는 4096바이트 크기의 단일 디스크
블록이 할당됩니다(논리적 블록 크기가 4096바이트일 경우). 따라서 읽기 또는 쓰기 작업은 디스크의 데이터에
액세스하기 위해 단 한 번의 디스크 입출력 작업만 수행하면 됩니다. 논리적 블록 크기가 이보다 작아서 동일한
크기의 데이터에 대해 두 개 이상의 할당이 필요할 경우, 이 데이터를 액세스하는 데 두 개 이상의 디스크 입출력
작업이 필요합니다. 디스크 블록의 크기가 클수록 더 많은 데이터를 보관할 수 있으므로, 논리적 블록의 크기가
크고 디스크 블록 크기가 같으면 파일과 디렉토리에 새로운 데이터가 추가될 때 수행되어야 하는 디스크 공간 할
당 작업의 양이 줄어듭니다.
하지만 디스크 공간 할당 단위를 논리적 블록 크기로 제한할 경우, 크기가 작은 수많은 파일 및 디렉토리가 포함
된 파일 시스템에서는 디스크 공간이 낭비될 수 있습니다. 한 개의 논리적 블록에 해당하는 디스크 공간이 파일
또는 디렉토리로 이루어진 부분 논리적 블록에 할당될 경우 디스크 공간이 낭비됩니다. 부분 논리적 블록에는 항
상 한 개의 논리적 블록 크기 미만의 데이터가 포함되므로, 부분 논리적 블록은 할당된 디스크 공간의 일부만 사
용합니다. 이미 할당된 디스크 공간에는 다른 파일이나 디렉토리가 내용을 쓸 수 없으므로 나머지 부분은 사용되
지 않게 됩니다. 크기가 작은 다수의 파일 및 디렉토리가 포함된 파일 시스템의 경우, 낭비되는 총 디스크 공간이
많을 수 있습니다.
저널 파일 시스템(JFS)은 디스크 공간을 프래그먼트라는 할당 단위로 나눕니다. 확장 저널 파일 시스템(JFS2)은
디스크 공간을 블록으로 세그먼트화합니다. 두 파일 시스템의 목표는 모두 데이터를 효율적으로 저장하는 데 있
습니다.
JFS 프래그먼트는 디폴트 디스크 할당 크기인 4096바이트보다 작습니다. 프래그먼트는 파일이나 디렉토리의
부분 논리적 블록에 데이터를 보다 효율적으로 저장함으로써 낭비되는 디스크 공간을 최소화합니다. JFS 프래그
먼트 지원이 작동하는 방식은 BSD(Berkeley Software Distribution) 프래그먼트 지원이 제공하는 방식을 기반
으로 합니다.
JFS2는 512, 1024, 2048 및 4096과 같은 다양한 파일 시스템 블록 크기를 지원합니다. 블록 크기가 작을수록
파일이나 디렉토리의 부분 논리적 블록에 데이터가 보다 효율적으로 저장되어 낭비되는 디스크 공간이 최소화됩
니다. 하지만 블록 크기가 작으면 작업에 따르는 추가 오버헤드가 발생할 수도 있습니다. JFS2에서는 블록이 작
성될 때 그 크기가 지정됩니다. 파일 시스템마다 서로 다른 블록 크기를 사용할 수 있지만, 단일 파일 시스템 내에
서는 한 가지 블록 크기만 사용할 수 있습니다.
JFS 프래그먼트
JFS에서는 디스크 공간 할당 단위를 프래그먼트라고 하며, 프래그먼트의 크기는 논리적 블록 크기인 4096바이
트보다 작을 수 있습니다.
4096바이트보다 작은 프래그먼트를 사용할 수 있게 됨에 따라서, 부분 논리적 블록 내에 포함된 데이터를 보다
효율적으로 저장할 수 있게 되었습니다. 이는 데이터를 저장할 때 꼭 필요한 만큼의 프래그먼트만 사용하기 때문

입니다. 예를 들어, 500바이트만 있는 부분 논리적 블록에 512바이트(프래그먼트 크기가 512바이트라고 가정
할 경우)의 프래그먼트를 할당할 수 있으므로 낭비되는 디스크 공간이 크게 줄어듭니다. 부분 논리적 블록에 필요
한 스토리지가 늘어나면 하나 이상의 프래그먼트가 추가로 할당됩니다.
파일 시스템에 맞는 프래그먼트 크기는 파일 시스템이 작성될 때 지정됩니다. 저널 파일 시스템(JFS)에서 사용할
수 있는 프래그먼트 크기는 512, 1024, 2048 및 4096바이트입니다. 파일 시스템마다 서로 다른 프래그먼트 크
기를 사용할 수 있지만, 단일 파일 시스템 내에서는 한 가지 프래그먼트 크기만 사용할 수 있습니다. 단일 시스템
에서는 여러 가지 프래그먼트 크기를 사용할 수 있으므로 사용자가 각 파일 시스템에 가장 적합한 프래그먼트 크
기를 선택할 수 있습니다.
JFS 프래그먼트 지원은 일련의 연속적인 디스크 블록이 아니라 일련의 연속적인 프래그먼트로 파일 시스템을 보
여 줍니다. 하지만 효율적인 디스크 작업을 위해, 디스크 블록이나 할당 단위의 크기가 논리적 블록의 크기와 동
일하도록 대개 4096바이트 단위로 디스크 공간이 할당됩니다. 이 경우 디스크 블록 할당은 연속적인 4096바이
트 프래그먼트가 할당되는 것으로 볼 수 있습니다.
파일 시스템의 프래그먼트 크기가 줄어들수록 작업에 따르는 오버헤드(추가 디스크 탐색, 데이터 전송, 할당 활
동)는 늘어나지만 디스크 공간은 보다 효율적으로 사용됩니다. 오버헤드 증가와 디스크 공간 사용의 효율성 간에
적절한 균형을 유지하기 위해 JFS 프래그먼트 지원에는 다음과 같은 요소가 적용됩니다.
• 가능하면, 파일 또는 디렉토리의 논리적 블록에 4096바이트 프래그먼트로 디스크 공간이 할당됩니다.
• 크기가 32KB 미만인 파일이나 디렉토리의 부분 논리적 블록에만 크기가 4096바이트보다 작은 프래그먼트가
할당될 수 있습니다.
파일 시스템 내의 파일 및 디렉토리 크기가 32KB보다 커지면 4096바이트 미만의 디스크 공간을 할당함으로써
얻을 수 있는 혜택이 줄어듭니다. 즉, 총 파일 시스템 공간 대비 절약되는 디스크 공간은 줄어들면서 크기가 작은
디스크 공간을 할당함으로써 발생하는 추가 성능 손실은 그대로 가져가게 됩니다. 4096바이트 미만의 디스크 공
간 할당은 크기가 작은 파일 및 디렉토리에 사용할 때 최대의 효과를 가져올 수 있으므로 크기가 32KB 이상인 파
일과 디렉토리의 논리적 블록에는 항상 4096바이트 프래그먼트를 할당하는 것이 바람직합니다. 크기가 큰 파일
이나 디렉토리와 연관된 부분 논리적 블록에도 4096바이트 프래그먼트를 할당하는 것이 바람직합니다.
JFS2 블록
확장 저널 파일 시스템은 디스크 공간을 블록으로 세그먼트화합니다. JFS2는 512, 1024, 2048 및 4096과 같은
다양한 파일 시스템 블록 크기를 지원합니다.
파일 시스템마다 서로 다른 블록 크기를 사용할 수 있지만, 단일 파일 시스템 내에서는 한 가지 블록 크기만 사용
블록 크기가 작을수록 파일이나 디렉토리의 부분 논리적 블록에 데이터가 보다 효율적으로 저장되어 낭비되는
디스크 공간이 최소화됩니다. 하지만 블록 크기가 작으면 작업에 따르는 추가 오버헤드가 발생할 수도 있습니다.
또한 장치 드라이버는 파일 시스템 블록 크기와 같거나 작은 디스크 블록 주소 지정 가능성을 제공해야 합니다.
블록 크기가 4096바이트가 아닌 다른 크기인 파일 시스템에는 이보다 작은 단위로 디스크 공간이 할당되므로,
파일이나 디렉토리의 크기가 반복해서 늘어날 경우 할당 활동이 보다 자주 발생할 수 있습니다. 예를 들어, 길이
가 0인 파일의 크기를 512바이트씩 늘리는 쓰기 작업이 수행되면 블록 크기가 512바이트라고 간주하고 파일에
블록 하나가 할당됩니다. 512바이트의 다른 쓰기 작업으로 인해 파일 크기가 더 늘어나면 파일에 추가 블록이 할
당되어야 합니다. 4096바이트 블록 크기를 사용하는 파일 시스템에 이와 같은 예가 적용될 경우, 첫 번째 쓰기 작
업이 수행될 때 한 번만 디스크 공간이 할당됩니다. 처음에 할당된 4096바이트 블록만으로도 두 번째 쓰기 작업
으로 추가된 데이터를 보관하기에 충분하므로 두 번째 쓰기 작업이 수행될 때는 추가 할당이 이루어지지 않습니
다.
파일 시스템 블록 크기는 SMIT(System Management Interface Tool) 또는 crfs 및 mkfs 명령을 사용하여 파
일 시스템의 작성 동안에 지정됩니다. 파일 시스템 블록 크기는 파일 시스템에 포함될 예상 파일 크기를 기준으로
결정합니다.
파일 시스템 블록 크기 값은 SMIT(System Management Interface Tool) 또는 lsfs 명령을 통해 식별될 수 있
습니다. 애플리케이션에서는 statfs 서브루틴을 사용하여 파일 시스템 블록 크기를 식별할 수 있습니다.
블록은 디스크 공간 할당의 기본 단위로 사용되며 파일 시스템 내의 각 블록의 할당 상태는 파일 시스템 블록 할
당 맵에 기록됩니다. 블록 크기가 4096바이트보다 작은 파일 시스템에서는 블록 할당 맵을 보관하기 위해 가상
메모리와 파일 시스템 디스크 공간이 추가로 필요할 수도 있습니다.
장치 관리 103
가변 i-노드 수
4096바이트보다 작은 크기로 디스크 공간을 세그먼트화하면 디스크 공간 사용량이 최적화되지만, 이로 인해 파
일 시스템에 저장될 수 있는 작은 크기의 파일 및 디렉토리의 수가 늘어납니다.
하지만 디스크 공간은 파일과 디렉토리에 필요한 여러 파일 시스템 자원 중 하나에 불과합니다. 각 파일이나 디렉
토리에는 디스크 i-노드도 필요합니다.
JFS 및 i-노드
JFS에서는 디폴트 디스크 i-노드 수보다 많거나 적은 i-노드가 필요할 경우, 파일 시스템 내에 작성되는 디스크 i-
노드 수를 지정할 수 있습니다.
파일 시스템이 작성될 때 생성되는 디스크 i-노드 수는 i-노드당 바이트 수 또는 NBPI라는 값으로 지정됩니다. 예
를 들어, NBPI 값이 1024이면 1024바이트의 파일 시스템 디스크 공간마다 한 개의 디스크 i-노드가 작성됩니
다. 이를 보는 또 다른 방법은 작은 NBPI 값(예를 들어 512)은 다수의 i-노드가 결과로 나오는 반면, 큰 NBPI 값
(예: 16,384)은 작은 수의 i-노드가 결과로 나온다는 것입니다.
JFS 파일 시스템에서는 파일 시스템에 할당된 NBPI바이트의 할당 그룹 공간마다 한 개의 i-노드가 작성됩니다.
파일 시스템의 총 i-노드 수에 따라 파일 시스템에 상주하는 총 파일의 수와 파일 시스템의 총 크기가 제한됩니다.
할당 그룹의 일부만 할당할 수도 있습니다. 단, 할당 그룹에 대해 작성되는 i-노드 수는 모두 할당됩니다. NBPI는
파일 시스템의 총 i-노드 수에 반비례합니다.
JFS는 모든 파일 시스템을 16M(224) i-노드로 제한합니다.
허용되는 NBPI 값 세트는 할당 그룹 크기(agsize)에 따라 다릅니다. 디폴트는 8MB입니다. agsize가 8MB인 할당
그룹에 허용되는 NBPI 값은 512, 1024, 2048, 4096, 8192 및 16,384입니다. 더 큰 agsize를 사용할 수 있습니
다. agsize에 허용되는 값은 8, 16, 32 및 64입니다. 허용 가능한 NBPI 값의 범위는 agsize가 늘어남에 따라 증가
됩니다. agsize의 크기가 디폴트 크기의 두 배인 16MB로 늘어나면 NBPI 값 범위도 두 배인 1024, 2048, 4096,
8193, 16384 및 32768로 늘어납니다.
프래그먼트 크기와 NBPI 값은 파일 시스템이 SMIT(System Management Interface Tool) 또는 crfs 및 mkfs
명령으로 작성되는 동안 지정됩니다. 프래그먼트 크기와 파일 시스템에 작성할 i-노드 수는 파일 시스템에 포함
될 예상 파일 수 및 크기를 기준으로 결정합니다.
SMIT(System Management Interface Tool) 또는 lsfs 명령을 사용하여 프래그먼트 크기와 NBPI 값을 식별할
수 있습니다. 애플리케이션에서는 statfs 서브루틴을 사용하여 파일 시스템 프래그먼트 크기를 식별할 수 있습
니다.
JFS2 및 i-노드
JFS2에서는 필요에 따라 i-노드를 할당합니다.
파일 시스템에 추가 i-노드를 할당할 수 있는 공간이 있으면 i-노드가 자동으로 할당됩니다. 따라서, 사용 가능한
i-노드 수는 파일 시스템 자체의 크기에 따라 제한됩니다.
JFS 및 JFS2 크기 제한
JFS의 최대 크기는 사용자가 파일 시스템을 작성할 때 정의합니다. JFS의 크기는 몇 가지 중요한 요소를 기준으
로 결정합니다.
JFS2에 권장되는 최대 크기는 16TB입니다. JFS2의 최소 파일 시스템 크기는 16MB입니다.
4096바이트보다 크기가 작은 할당 단위를 사용하는 파일 시스템에서는 기본 할당 단위인 4096바이트를 사용하
는 파일 시스템보다 필요한 디스크 공간이 적지만 크기가 작은 프래그먼트를 사용할 경우 성능 저하를 감수해야
할 수도 있습니다.
파일 시스템 내의 각 프래그먼트(JFS) 또는 블록(JFS2)의 할당 상태는 파일 시스템 할당 맵에 기록됩니다. 프래
그먼트 또는 블록 크기가 4096바이트보다 작은 파일 시스템에서는 할당 맵을 보관하기 위해 가상 메모리와 파일
시스템 디스크 공간이 추가로 필요할 수도 있습니다.
프래그먼트(JFS) 또는 블록(JFS2) 크기가 4096바이트가 아닌 다른 크기인 파일 시스템에는 이보다 작은 단위로
디스크 공간이 할당되므로, 파일이나 디렉토리의 크기가 반복해서 늘어날 경우 할당 활동이 보다 자주 발생할 수
있습니다. 예를 들어, 길이가 0인 파일의 크기를 512바이트씩 늘리는 쓰기 작업이 수행되면, 파일 시스템 유형에
따라 파일에 512바이트의 프래그먼트 또는 블록이 하나 할당됩니다. 512바이트의 다른 쓰기 작업으로 인해 파
일 크기가 더 늘어나면 파일에 추가 프래그먼트나 블록이 할당되어야 합니다. 4096바이트 프래그먼트 또는 블록
크기를 사용하는 파일 시스템에 이와 같은 예가 적용될 경우, 첫 번째 쓰기 작업이 수행될 때 한 번만 디스크 공간
이 할당됩니다. 처음에 할당된 4096바이트만으로도 두 번째 쓰기 작업으로 추가된 데이터를 보관하기에 충분하

므로 두 번째 쓰기 작업이 수행될 때는 추가 할당이 이루어지지 않습니다. 파일이 한 번에 4096바이트씩 늘어날
경우 할당 활동이 최소화됩니다.
크기와 관련된 한 가지 문제는 파일 시스템 로그의 크기입니다.
JFS에서는 대부분의 경우 여러 개의 파일 시스템이 크기가 4MB로 구성된 공통 로그를 사용합니다. 예를 들어,
처음 설치된 후 루트 볼륨 그룹 내의 모든 파일 시스템은 논리적 볼륨 hd8을 공통 JFS 로그로 사용합니다. 논리적
볼륨 파티션의 디폴트 크기가 4MB이고 디폴트 로그 크기가 파티션 하나의 크기가 되므로 대개 루트 볼륨 그룹에
4MB의 JFS 로그가 포함됩니다. 파일 시스템이 2GB를 초과하거나 단일 로그를 사용하는 파일 시스템의 총 공간
이 2GB를 초과하면 디폴트 로그 크기가 충분하지 않을 수도 있습니다. 둘 중 어떤 경우에든 파일 시스템 크기가
늘어남에 따라 로그 크기도 늘어나야 합니다. 논리적 볼륨의 크기가 변경되면 logform 명령을 실행하여 로그를
다시 초기화함으로써 새로운 공간을 사용할 수 있게 만들어야 합니다. JFS 로그의 최대 크기는 256MB로 제한됩
니다.
실질적으로 단일 JFS 로그가 지원할 수 있는 크기는 여러 파일 시스템을 결합한 크기로 제한됩니다. 단일 JFS 로
그에 권장되는 총 파일 시스템 용량은 1조 바이트입니다. 이 크기를 초과하거나 곧 초과하게 될 경우 또는
logredo 명령(fsck 명령에 의해 호출됨)에서 메모리 부족 오류가 발생할 경우에는 추가 JFS 로그를 추가하여
두 개의 JFS 로그 파일로 로드를 분산시키십시오.
JFS2에서는 대부분의 경우 여러 개의 파일 시스템이 공통 로그를 사용합니다. 파일 시스템이 2GB를 초과하거나
단일 로그를 사용하는 파일 시스템의 총 공간이 2GB를 초과하면 디폴트 로그 크기가 충분하지 않을 수도 있습니
다. 둘 중 어떤 경우에든 파일 시스템 크기가 늘어나면 로그 크기를 늘릴 수 있습니다. 또는 추가 JFS2 로그를 추
가하여 두 개의 JFS2 로그 파일로 로드를 분산시킬 수 있습니다.
JFS 크기 제한
JFS의 최대 크기는 파일 시스템을 작성할 때 정의합니다. NBPI, 프래그먼트 크기 및 할당 그룹 크기를 토대로
JFS의 최대 크기를 결정할 수 있습니다.
파일 시스템 크기 제한은 최소한 다음 중 가장 작은 크기여야 합니다.
NBPI * 224
또는
FragmentSize * 228
예를 들어, NBPI 비율을 512로 선택한 경우, 파일 시스템 크기가 8GB(512 * 224 = 8 GB)로 제한됩니다.
JFS에서 NBPI에 지원하는 값은 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536 및 131072입니다.
JFS는 모든 파일 시스템을 16M(224) i-노드로 제한합니다.
JFS 파일 시스템에서는 파일 시스템에 할당된 NBPI바이트의 할당 그룹 공간마다 한 개의 i-노드가 작성됩니다.
할당 그룹의 일부만 할당할 수도 있습니다. 단, 할당 그룹에 대해 작성되는 i-노드 수는 모두 할당됩니다. NBPI는
파일 시스템의 총 i-노드 수에 반비례합니다.
JFS는 파일 시스템 공간을 사용자 데이터용 디스크 블록과 i-노드로 그룹화하여 분리합니다. 이러한 그룹을 할당
그룹이라고 합니다. 할당 그룹의 크기는 파일 시스템을 작성할 때 지정할 수 있습니다. 할당 그룹 크기는 8M,
16M, 32M 및 64M입니다. 각각의 할당 그룹 크기에는 연관된 NBPI 범위가 있습니다. 이 범위는 다음 표에 정의
되어 있습니다.
Allocation Group
Size in Megabytes Allowable NBPI Values
8 512, 1024, 2048, 4096, 8192, 16384
16 1024, 2048, 4096, 8192, 16384, 32768
32 2048, 4096, 8192, 16384, 32768, 65536
64 4096, 8192, 16384, 32768, 65536, 131072
장치 관리 105
JFS는 512, 1024, 2048 및 4096바이트의 연속 디스크 공간으로 이루어진 네 가지 프래그먼트 크기를 지원합니
다. JFS에서는 프래그먼트 주소를 i-노드와 간접 블록에 28비트 숫자로 유지합니다. 0에서 (228)까지의 숫자로
각 프래그먼트의 주소를 지정할 수 있어야 합니다.
JFS2 크기 제한
테스트 결과 매우 큰 파일들이 포함된 대형 JFS2 파일 시스템이 크기가 작은 파일이 다수 포함된 파일 시스템보
다 유지보수하기가 쉽다는 것이 입증되었습니다. 대형 파일 시스템에 크기가 작은 파일이 다수 포함되어 있으면
fsck 명령 및 기타 파일 시스템 유지보수 태스크를 실행하는 데 시간이 오래 걸립니다.
JFS2 파일 시스템 크기 한계는 다음과 같이 나열됩니다.
항목 설명
최대 JFS2 파일 시스템 크기: 32TB
최대 JFS2 파일 크기: 16TB
최소 JFS2 파일 시스템 크기: 16MB
JFS 사용 가능 공간 프래그먼트화
JFS 파일 시스템에서 4096바이트보다 작은 프래그먼트를 사용할 경우 디스크의 사용 가능 공간이 훨씬 많이 프
래그먼트화될 수 있습니다.
예를 들어, 디스크의 한 영역이 각각 512바이트의 프래그먼트 8개로 나뉜다고 가정해 보십시오. 이때, 각각 512
바이트가 필요한 여러 개의 파일이 이 디스크 영역의 첫째, 넷째, 다섯째, 일곱째 프래그먼트에 쓰이고 둘째, 셋
째, 여섯째, 여덟째 프래그먼트는 사용 가능하다고 간주합니다. 2048바이트의 디스크 공간을 나타내는 이 4개의
프래그먼트가 사용 가능하기는 하지만, 4개의 프래그먼트(또는 2048바이트)가 필요한 부분 논리적 블록이 이들
프래그먼트에 할당되지는 않습니다. 이는 한 번의 할당에 사용될 프래그먼트가 연속해서 위치해야 하기 때문입
니다.
파일이나 디렉토리의 논리적 블록에 할당되는 프래그먼트는 연속해야 하므로 사용 가능 공간이 프래그먼트화될
경우, 사용 가능한 총 공간이 파일 시스템 작업을 수행하기에 충분하더라도 새 디스크 공간을 요청하는 파일 시스
템 작업이 실패할 수 있습니다. 예를 들어, 한 개의 논리적 블록으로 길이가 0인 파일을 확장하는 쓰기 작업이 수
행되려면 4096바이트의 연속 디스크 공간이 할당되어야 합니다. 파일 시스템의 사용 가능 공간이 프래그먼트화
되어 32개의 연속되지 않은 512바이트의 프래그먼트로 구성되거나 총 16KB의 사용 가능 디스크 공간으로 구성
된 경우, 쓰기 작업이 실패합니다. 이는 쓰기 작업을 수행하려면 8개의 연속된 프래그먼트나 4096바이트의 연속
된 디스크 공간이 필요한데 이를 사용할 수 없기 때문입니다.
관리하기 어려울 정도로 프래그먼트화된 사용 가능 공간이 많은 JFS 파일 시스템의 경우, defragfs 명령을 사
용하여 파일 시스템에 대해 프래그먼트 모음을 수행할 수 있습니다. defrags 명령을 실행하면 성능이 개선됩니
다.
스파스 파일
파일은 일련의 색인화된 블록입니다. 블록은 i-노드에서 블록이 나타내는 파일의 논리적 오프셋으로 맵핑됩니다.
데이터 블록에 맵핑되지 않은 색인이 있는 한 개 이상 있는 파일을 스파스 할당 또는 스파스 파일이라고 합니다.
스파스 파일의 크기는 파일과 연관되지만 모든 데이터 블록이 크기 요구사항에 맞게 할당되지는 않습니다. 스파
스 할당 파일인지 식별하려면 fileplace 명령을 사용하십시오. 현재 할당되지 않은 파일의 모든 블록이 표시됩
니다.
참고: 대부분의 경우 du를 사용하여 파일에 할당된 데이터 블록 수가 해당 크기의 파일을 보관하는 데 필요한 블
록 수와 일치하지 않는지 판별할 수 있습니다. 압축 파일 시스템은 스파스 할당되지 않은 파일에 대해 같은 작동
을 나타낼 수 있습니다.
스파스 파일은 현재 할당된 색인 외부의 위치를 찾아서 애플리케이션이 파일을 확장할 때 작성되지만 쓰여진 데
이터는 새로 지정된 모든 색인을 사용하지 않습니다. 새 파일 크기는 가장 오래된 파일에 쓰기를 반영합니다.
할당되지 않은 데이터 블록이 있는 파일의 섹션을 읽으면 0 버퍼가 리턴합니다. 할당되지 않은 데이터 블록이 있
는 섹션에 쓰면 필수 데이터 블록이 할당되고 데이터가 쓰여집니다.
이 작동은 파일 조작 또는 아카이브 명령에 영향을 미칠 수 있습니다. 예를 들어, 다음 명령은 파일의 스파스 할당
을 보존하지 않습니다.
• cp

• mv
• tar
• cpio
참고: mv의 경우에는 파일을 다른 파일 시스템으로 이동하는 데에만 적용됩니다. 파일이 같은 파일 시스템 내에
서 이동하면 파일이 스파스됩니다.
파일이 선행 명령에서 복사되거나 복원되면 각 데이터 블록이 할당되므로 스파스 특성을 갖지 않습니다. 그러나
다음 아카이브 명령은 스파스 특성을 보존하거나 파일을 스파스합니다.
• backup
• restore
• pax
스파스 파일을 사용하면 파일 시스템의 자원이 지나치게 많이 사용될 수 있으므로 이 유형의 파일을 사용하고 유
지보수할 때는 주의해야 합니다.
JFS 및 대형 파일
JFS 파일 시스템 유형을 사용하여 대형 파일을 작성할 수 있습니다.
모든 JFS2 파일 시스템은 대형 파일을 지원합니다.
대형 파일을 사용할 수 있는 파일 시스템은 crfs 및 mkfs 명령으로 작성할 수 있습니다. 두 명령 모두 대형 파일
을 사용할 수 있는 파일 시스템을 지정하는 옵션(bf=true)을 제공합니다. SMIT를 사용하여 이러한 파일 시스템
을 작성할 수도 있습니다.
대형 파일을 사용할 수 있는 파일 시스템에서는 4MB 파일 오프셋 앞에 저장된 파일 데이터가 4096바이트 블록
에 할당됩니다. 4MB 파일 오프셋 뒤에 저장된 파일 데이터에는 크기가 128KB이니 대형 디스크 블록이 할당됩니
다. 대형 디스크 블록은 실제로는 32개의 연속된 4096바이트 블록입니다.
예를 들어, 정규 파일 시스템에서는 132MB 크기 파일에 33K 4KB의 디스크 블록이 필요합니다(33개의 단일 간
접 블록 각각이 1024 4KB 디스크 주소로 채워짐). 대형 파일을 사용할 수 있는 파일 시스템의 132MB 파일은
1024 4KB 디스크 블록과 1024 128KB 디스크 블록을 가집니다. 대형 파일 위치(geometry)에는 132MB 파일
에 두 개의 단일 간접 블록만 필요합니다. 대형 및 정규 파일 유형에는 모두 한 개의 이중 간접 블록이 필요합니다.
대형 디스크 블록에는 32개의 연속된 4KB 블록이 필요합니다. 대형 파일에 4MB가 넘게 쓸 경우, 사용되지 않은
32개의 연속된 4KB 블록이 없으면 ENOSPC로 파일 오프셋이 실패합니다.
참고: 파일 시스템에 사용 가능한 블록이 수천 개 있더라도 이 중 32개가 연속해서 있지 않으면 할당에 실패합니
다.
defragfs 명령은 보다 큰 연속된 사용 가능 블록 영역을 제공하기 위해 디스크 블록을 재구성합니다.
JFS에서 모든 새로운 디스크 할당을 초기화해야 합니다. JFS는 대형 파일을 사용할 수 있는 시스템의 첫 번째 파
일 시스템을 마운팅할 때 커널 kproc 프로시저를 시작하여 초기 파일 할당을 제로(0)로 만듭니다. 대형 파일을 사
용할 수 있는 파일 시스템이 성공적으로 마운트 해제된 후에도 kproc 프로시저는 그대로 남습니다.
JFS 데이터 압축
JFS는 프래그먼트화되고 압축된 파일 시스템을 지원합니다. 이는 전체 블록 크기인 4096바이트보다 작은 단위
또는 "프래그먼트"로 논리적 블록을 디스크에 저장할 수 있도록 함으로써 디스크 공간을 절약합니다.
JFS2에는 데이터 압축이 지원되지 않습니다.
프래그먼트화된 파일 시스템에서는 32KB보다 크지 않은 마지막 논리적 파일 블록이 이런 식으로 저장되므로, 프
래그먼트 지원은 크기가 작은 파일이 다수 포함된 파일 시스템에서만 효과가 있습니다. 하지만 데이터 압축을 사
용하면 크기에 관계없이 모든 논리적 블록을 하나 이상의 연속적인 프래그먼트로 저장할 수 있습니다. 데이터 압
축을 사용하면 평균적으로 디스크 공간이 두 배 절약됩니다.
하지만 프래그먼트와 데이터 압축을 사용하면 디스크 사용 가능 공간이 프래그먼트화될 가능성도 높아집니다.
논리적 블록에 할당된 프래그먼트는 디스크에서 연속적인 공간이어야 합니다. 사용 가능 공간이 프래그먼트화된
파일 시스템에서는 논리적 블록 할당에 사용할 충분한 연속적 프래그먼트를 찾는 데 어려움을 겪을 수도 있습니
다. 이는 사용 가능 프래그먼트의 수가 논리적 블록 요구사항을 초과할 경우에도 마찬가지입니다. JFS에서는 연
속적인 사용 가능 공간의 크기를 늘려서 파일 시스템에 대해 "프래그먼트 모음"을 수행하는 defragfs 프로그램
장치 관리 107
을 제공하여 사용 가능 공간의 프래그먼트화를 줄입니다. 이 유틸리티는 프래그먼트화되고 압축된 파일 시스템
에 사용할 수 있습니다. 프래그먼트 및 데이터 압축을 통해 절약되는 디스크 공간은 꽤 많은 반면 사용 가능 공간
의 프래그먼트화로 인한 문제는 관리할 수 있는 수준입니다.
현재 JFS의 데이터 압축은 이 운영 체제의 이전 버전과 호환됩니다. 모든 시스템 호출로 구성된 API는 두 버전의
JFS에서 동일합니다.
JFS 데이터 압축 구현
데이터 압축은 crfs 또는 mkfs 명령으로 파일 시스템을 작성할 때 지정하는 파일 시스템 속성입니다. SMIT를
사용하여 데이터 압축을 지정할 수 있습니다.
주의: 루트 파일 시스템(/)은 압축해서는 안됩니다. /usr 파일 시스템은 압축하지 않는 것이 좋습니다.
이는 installp가 갱신 및 새로 설치 시 이 파일 시스템의 크기를 정확하게 계산할 수 있어야 하기 때문
입니다.
압축은 정규 파일과 파일 시스템에 있는 긴 기호 링크에만 적용됩니다. 압축되지 않은 디렉토리와 메타데이터에
는 프래그먼트가 지원됩니다. 파일의 각 논리적 블록은 디스크에 쓰이기 전에 자체적으로 압축됩니다. 이런 식의
압축은 임의의 탐색과 갱신을 활용함으로써 보다 큰 단위로 데이터를 압축할 때보다 손실되는 사용 가능 디스크
공간이 적습니다.
압축된 논리적 블록 한 개에는 대개 4096바이트 미만의 디스크 공간이 필요합니다. 압축된 논리적 블록은 디스
크에 쓰이고, 이 블록을 저장하는 데 필요한 만큼의 연속 프래그먼트 수만 할당됩니다. 논리적 블록이 압축되지
않은 경우에는 압축되지 않은 양식으로 디스크에 쓰이고 4096바이트의 연속 프래그먼트가 할당됩니다.
lsfs -q 명령으로 현재 압축 값을 표시할 수 있습니다. SMIT를 사용하여 데이터 압축을 식별할 수도 있습니다.
JFS 데이터 압축의 암시적 동작

파일에 쓰는 프로그램은 쓰기(맵핑된 파일의 경우, 성공적인 저장)에 성공한 후 공간 부족(ENOSPC) 조건이 발생
할 것으로 예상하지 않으므로, 논리적 블록을 디스크에 쓸 때는 공간 사용이 보장되어야 합니다.
이는 논리적 블록이 처음 수정될 때 논리적 블록에 4096바이트를 할당하여 블록이 압축되지 않더라도 사용 가능
한 공간이 확보되도록 함으로써 이루어집니다. 4096바이트 할당만으로는 충분하지 않을 경우, 압축된 논리적 블
록을 수용할 만큼의 디스크 공간이 있더라도 시스템에서 ENOSPC 또는 EDQUOT 오류 조건을 리턴합니다. 대개
는 쿼럼 한계에서 또는 파일 시스템이 거의 다 찬 상태에서 시스템이 작동될 경우 공간 부족 상태가 미리 보고됩
니다.
또한 압축된 파일 시스템에서는 다음과 같은 동작이 발생할 수도 있습니다.
• 처음에 논리적 블록에 4096바이트가 할당되었으므로 특정 시스템 호출에서 ENOSPC 또는 EDQUOT 오류를
수신할 수도 있습니다. 예를 들어, 이전의 파일이 mmap 시스템 호출을 통해 맵핑되어 이전에 작성되었던 위치
에 저장된 결과 ENOSPC 오류가 발생할 수 있습니다.
• 데이터 압축이 사용될 경우, 디스크에 쓰이기 전까지는 전체 디스크 블록이, 수정된 블록에 할당된 상태로 유지
됩니다. 이 블록에 이전에 전체 블록보다 작은 크기의 공간이 할당된 경우, 이 블록에 사용되는 디스크 공간의
크기는 이 블록에 할당된 공간과 파일(i-노드)이 확정될 때까지 해제되지 않는 이전 할당을 더한 크기입니다. 이
는 일반적인 프래그먼트에 해당되는 사항입니다. 이전에 확정된 할당을 가질 수 있는 파일의 논리적 블록 수는
일반적인 프래그먼트일 경우 많아야 한 개이지만, 압축이 사용된 경우 파일에 있는 블록 수만큼 많을 수도 있습
니다.
• 애플리케이션에서 fsync 또는 sync 시스템 호출을 실행할 때까지, 논리적 블록용으로 이전에 확정된 자원이
해제되지 않습니다.
• stat 시스템 호출은 파일에 할당된 프래그먼트 수를 표시합니다. 보고되는 수치는 수정되었지만 쓰이지 않은
블록에 할당되는 4096바이트와 수정되지 않은 블록의 압축된 크기를 기준으로 계산됩니다. 이전에 확정된 자
원은 stat 시스템 호출로 계산되지 않습니다. stat 시스템 호출은 i-노드 확정 작업 후 할당된 프래그먼트의
올바른 수를 보고합니다(수정된 블록이 압축되지 않은 경우). 마찬가지로 현재 할당에 대한 디스크 할당량이 청
구됩니다. 파일의 논리적 블록이 디스크에 쓰일 때, 논리적 블록이 압축되면 논리적 블록에 할당된 프래그먼트
의 수가 줄어들고 이에 따라 디스크 할당량과 stat의 결과가 변경됩니다.
JFS 데이터 압축 알고리즘

이 압축 알고리즘은 IBM 버전의 LZ입니다. 일반적으로 LZ 알고리즘은 특정 문자열이 있는 첫 번째 위치와 그 길
이를 식별하는 포인터를 사용하여 해당 문자열의 두 번째 및 이후의 발생을 표현함으로써 데이터를 압축합니다.

압축 절차가 시작될 때는 어떤 문자열도 식별되지 않은 것이므로 최소한 데이터의 첫째 바이트는 9비트(0바이
트)가 필요한 "원시" 문자로 표현되어야 합니다. 지정된 데이터의 양, 예를 들어, N바이트가 압축된 후에는 처리
되지 않은 다음 바이트부터 시작하여 압축 프로그램이 이 N바이트에서 이 문자열과 일치하는 가장 긴 문자열을
검색합니다. 일치하는 가장 긴 문자열의 길이가 0이나 1일 경우, 다음 바이트가 "원시" 문자로 인코드됩니다. 그
렇지 않은 경우, 문자열이 (포인터, 길이) 쌍으로 표현되고 처리된 바이트 수가 이 길이만큼 증분됩니다. 구조상
IBM LZ는 N 값으로 512, 1024 또는 2048을 지원합니다. IBM LZ는 (포인터, 길이) 쌍 및 원시 문자의 인코딩을
지정합니다. 포인터는 크기가 log2 N인 고정 길이 필드인 반면 길이는 가변 길이 필드로 인코드됩니다.
JFS 데이터 압축이 성능에 미치는 영향

데이터 압축은 프래그먼트 지원이 확장된 기능이므로, 프래그먼트와 연관된 성능 문제가 데이터 압축에도 적용
됩니다.
압축된 파일 시스템은 다음과 같은 방법으로 성능에도 영향을 줍니다.
• 압축된 파일 시스템의 사용성이 일부 사용자 환경에서 제한될 수 있도록 데이터를 압축하고 추출하는 데에는
상당한 시간 필요할 수 있습니다.
• 대부분의 UNIX 정규 파일은 한 번만 쓰이지만 일부 파일은 적절히 갱신됩니다. 파일이 갱신될 경우, 데이터 압
축을 사용하면 논리적 블록이 처음 수정될 때 4096바이트의 디스크 공간을 할당해야 하고 그런 다음 논리적 블
록이 디스크에 쓰인 후 디스크 공간을 다시 할당함에 따라 추가적인 성능 비용이 발생할 수 있습니다. 압축되지
않은 파일 시스템의 정규 파일에는 이러한 추가적인 할당 활동이 필요하지 않습니다.
• 데이터 압축은 프로세서 순환 수를 늘립니다. 소프트웨어 압축 프로그램의 경우, 압축에 필요한 순환 수가 대략
바이트당 50번이고 압축을 푸는 데 필요한 순환 수가 바이트당 10번입니다.
JFS 온라인 백업 및 JFS2 스냅샷

백업 목적으로 사용할 수 있는 JFS 파일 시스템 또는 JFS2 파일 시스템의 특정 시점 이미지를 만들 수 있습니다.
단, 파일 시스템 유형마다 이 이미지가 작동하는 방식이나 요구사항이 다릅니다.
JFS 파일 시스템에서는 파일 시스템의 미러 사본에 대한 읽기 전용 정적 사본을 분할할 수 있습니다. 일반적으로,
미러 사본은 원래 파일 시스템이 갱신될 때마다 갱신되지만 이 특정 시점 사본은 변경되지 않습니다. 이 사본은
사본이 작성되었을 당시의 이미지 그대로 남아 있습니다. 이 이미지가 백업에 사용된 경우, 이미지를 작성하는 절
차를 시작한 이후 시작된 수정사항은 백업 사본에 없을 수도 있습니다. 따라서 분할이 수행되는 동안에는 파일 시
스템 활동을 최소화하는 것이 바람직합니다. 분할이 수행된 이후 발생한 변경사항은 백업 사본에 포함되지 않습
니다.
JFS2 파일 시스템에서는 이와 같은 특정 시점 이미지를 스냅샷이라고 합니다. 스냅샷은 스냅샷 작성 시 원래 파
일 시스템(snappedFS)이 가지고 있었던 것과 동일한 보안 권한을 가집니다. 또한, 파일 시스템을 마운트 해제하
거나 정지하지 않고도 JFS2 스냅샷을 작성할 수 있습니다. JFS2 스냅샷을 파일 시스템의 온라인 백업으로 사용
하여 스냅샷이 작성되었을 때의 상태로 파일이나 디렉토리에 액세스하거나 이동식 매체에 백업할 수 있습니다.
JFS2 스냅샷의 경우 다음과 같은 사항에 유의하십시오.
• 시스템이 재부트될 때 루트(/) 또는 /usr 파일 시스템이 겹쳐쓰기됩니다. 시스템을 재부트하기 전에 파일 시
스템을 마운트 해제하여 다른 파일 시스템의 스냅샷은 보존할 수 있습니다. AIX 5.2 5200-01에서 생성된 스냅
샷은 복구할 수 있습니다. AIX 5.2 5200-01에서 생성된 스냅샷이 있는 JFS2 파일 시스템에서 fsck나
logredo를 실행하면 스냅샷이 보존됩니다. AIX 5.2에서 생성된 스냅샷이 있는 완전히 마운트 해제된 파일 시
스템도 AIX 5.2 5200-01 시스템에 마운트된 후에는 복구가 가능합니다.
• 스냅샷이 있는 파일 시스템에 대해서는 defragfs 명령을 실행하지 않는 것이 좋습니다. 프래그먼트 모음 중
이동된 모든 블록이 스냅샷에 복사되어야 하는데 이를 수행하려면 시간이 많이 걸릴 뿐만 아니라 스냅샷 논리
적 볼륨의 공간도 낭비됩니다.
• 스냅샷 실행 중 공간이 부족해지면 해당 snappedFS에 대한 모든 스냅샷이 삭제됩니다. 이로 인해 오류 로그에
항목이 하나 기록됩니다.
• 스냅샷 파일에 쓰는 데 실패하면 해당 snappedFS에 대한 모든 스냅샷이 삭제됩니다. 이로 인해 오류 로그에 항
목이 하나 기록됩니다.
• AIX 5.2 5200-01 시스템에서 생성되거나 액세스된 스냅샷은 AIX 5.2 시스템에서 액세스될 수 없습니다. 파일
시스템을 마운트하려면 먼저 이러한 스냅샷을 삭제해야 합니다.
• AIX 5.3에서 생성된 스냅샷이 있는 JFS2 파일 시스템은 AIX 5.2 5200-01 이전 릴리스에서 액세스될 수 없습
니다. 시스템을 이전 버전으로 바꾸려는 경우, 먼저 스냅샷을 삭제하여 파일 시스템에 액세스할 수 있게 만들어
야 합니다.
장치 관리 109
JFS 온라인 백업
그런 다음 백업 목적을 위해 사용할 수 있는 JFS 파일 시스템의 특정 시점 이미지를 만들 수 있습니다.
JFS 파일 시스템에서는 파일 시스템의 미러 사본에 대한 읽기 전용 정적 사본을 분할할 수 있습니다. 일반적으로,
미러 사본은 원래 파일 시스템이 갱신될 때마다 갱신되지만 이 특정 시점 사본은 변경되지 않습니다. 이 사본은
사본이 작성되었을 당시의 이미지 그대로 남아 있습니다. 이 이미지가 백업에 사용된 경우, 이미지를 작성하는 절
차를 시작한 이후 시작된 수정사항은 백업 사본에 없을 수도 있습니다. 따라서 분할이 수행되는 동안에는 파일 시
스템 활동을 최소화하는 것이 바람직합니다. 분할이 수행된 이후 발생한 변경사항은 백업 사본에 포함되지 않습
니다.
JFS2 스냅샷
그런 다음 백업 목적을 위해 사용할 수 있는 JFS2 파일 시스템의 특정 시점 이미지를 만들 수 있습니다.
JFS2 파일 시스템의 특정 시점 이미지는 스냅샷이라고 합니다. 스냅샷은 스냅샷 작성 시 원래 파일 시스템
(snappedFS)이 가지고 있었던 것과 동일한 보안 권한을 가집니다. 또한 파일 시스템을 마운트 해제하거나 파일
시스템을 정지하지 않고 JFS2 스냅샷을 만들 수도 있습니다. JFS2 스냅샷을 사용하여 다음을 수행할 수 있습니
다.
• 스냅샷이 작성되었을 때 존재했던 파일이나 디렉토리에 액세스합니다.
• 이동식 매체로 백업합니다.
JFS2 스냅샷에는 내부와 외부의 두 가지 유형이 있습니다. JFS2 외부 스냅샷은 파일 시스템으로부터 별도의 논
리적 볼륨에 작성됩니다. 외부 스냅샷은 자체 고유한 마운트 위치에서 파일 시스템으로부터 별도로 마운트될 수
있습니다.
JFS2 내부 스냅샷은 파일 시스템과 동일한 논리적 볼륨에 작성되고 파일 시스템으로부터 블록을 할당합니다. 내
부 스냅샷은 스냅샷이 있는 JFS2 파일 시스템의 루트에서 보이지 않는 .snapshot 디렉토리로부터 액세스 가
능합니다. JFS2 파일 시스템은 파일 시스템이 작성될 때 내부 스냅샷을 지원할 수 있어야 합니다.
JFS2 스냅샷은 파일 시스템 할당량의 검사를 지원하지 않습니다. 할당량의 상태를 판별하기 위해 스냅샷에서
repquota 명령을 사용할 수 없습니다. 파일 시스템 이미지를 스냅샷 이미지로 롤백하는 경우 특정 시점 할당량
정보가 보존됩니다. JFS2 외부 스냅샷과 JFS2 내부 스냅샷에 특정적인 다음 고려사항을 참고하십시오.
• AIX 5.2 5200-01 시스템에서 작성되거나 액세스한 외부 스냅샷은 AIX 5.2 시스템에서 액세스할 수 없습니다.
이러한 스냅샷은 파일 시스템을 마운트하기 전에 삭제되어야 합니다.
• AIX 5.3에서 생성된 스냅샷이 있는 JFS2 파일 시스템은 AIX 5.2 5200-01 이전 릴리스에서 액세스될 수 없습
니다. 시스템을 이전 버전으로 바꾸려는 경우, 먼저 스냅샷을 삭제하여 파일 시스템에 액세스할 수 있게 만들어
야 합니다.
• 외부 스냅샷이 있는 JFS2 파일 시스템에 대해 defragfs 명령을 실행하는 것은 권장되지 않습니다. 프래그먼
트 모음 동안에 이동된 모든 블록 또한 스냅샷에 복사해야 하는데, 이는 시간이 많이 걸리고 스냅샷 논리적 볼
륨의 공간을 낭비하기 때문입니다.
• 외부 스냅샷이 공간을 다 소비하거나 외부 스냅샷이 실패하면 해당 snappedFS의 모든 외부 스냅샷이 유효하
지 않은 것으로 표시됩니다. 스냅샷에 대한 추가 액세스는 실패합니다. 이러한 실패는 오류 로그에 항목을 기록
합니다.
내부 JFS2 스냅샷 고려사항:
• 내부 스냅샷은 logredo 명령이 내부 스냅샷이 있는 JFS2 파일 시스템에서 실행할 때 보존됩니다.
• 내부 스냅샷은 fsck 명령이 JFS2 파일 시스템을 수리하기 위해 수정해야 하는 경우에 제거됩니다.
• 내부 스냅샷에 공간이 부족하거나 내부 스냅샷에 쓰기가 실패하면 해당 snappedFS의 모든 내부 스냅샷이 유
효하지 않은 것으로 표시됩니다. 내부 스냅샷에 대한 추가 액세스는 실패합니다. 이러한 실패는 오류 로그에 항
목을 기록합니다.
• 내부 스냅샷은 개별적으로 마운트 가능하지 않습니다. 내부 스냅샷이 작성된 직후에 파일 시스템의 루트
의 .snapshot 디렉토리에서 내부 스냅샷에 액세스할 수 있습니다. 결과적으로, 스냅샷의 개별 마운트 위치를
반출할 필요 없이 NFS 서버를 통해 내부 스냅샷에 액세스할 수 있습니다.
• 내부 스냅샷은 AIX 6.1 이전 AIX 릴리스와는 호환 가능하지 않습니다. 내부 스냅샷을 지원하기 위해 작성된
JFS2 파일 시스템은 AIX 의 이전 릴리스에서는 수정할 수 없습니다.
• 내부 스냅샷을 지원하기 위해 작성된 JFS2 파일 시스템은 또한 Extended Attributes 버전 2를 지원할 수도 있
습니다.

• 내부 스냅샷이 있는 JFS2 파일 시스템은 DMAPI(Data Management Application Programming Interface)와
함께 사용할 수 없습니다.
• 내부 스냅샷이 있는 JFS2 파일 시스템에 대해 defragfs 명령을 사용할 수 없습니다.
• .snapshot 디렉토리는 readdir() 시스템 호출에서 리턴되지 않습니다. 그러면 스냅샷의 원치 않는 방문을 막
을 수 있습니다. readdir() 시스템에 의존하는 모든 시스템 호출 또는 명령은 .snapshot 디렉토리와 함께 실
패합니다. 예를 들어, /bin/pwd 명령 및 .snapshot 디렉토리의 getcwd() 시스템 호출이 상위 디렉토리를
찾을 수 없습니다.
호환성 및 이주
JFS 파일 시스템은 AIX 5.1과 AIX 5.2 내에서 완전하게 호환됩니다. 이전에 지원되었던 운영 체제 버전도 현재
JFS와 호환됩니다. 단, 디폴트가 아닌 프래그먼트 크기, NBPI 값 또는 할당 그룹 크기를 사용하지 않는 파일 시스
템을 이전 버전 운영 체제로 이주할 때는 특별히 주의를 기울여야 할 수도 있습니다.
참고: JFS 파일 시스템은 4KB의 섹터 크기가 있는 디스크에서는 지원되지 않습니다. 그러므로, 파일 시스템을 작
성하거나 백업 조작을 수행할 때 디스크가 4KB 섹터 크기가 아닌지 확인하십시오.
스냅샷을 제외한 모든 JFS2 파일 시스템이 AIX 5.1과 AIX 5.2 내에서 호환되지만 이전 버전의 운영 체제와는 호
환되지 않습니다. 스냅샷이 있는 JFS2 파일 시스템은 AIX 5.1에서 지원되지 않습니다. 이전 버전의 AIX 로 되돌
리기 전에 항상 모든 JFS2 파일 시스템에 완전히 마운트 해제되었는지 확인하십시오. 이는 logredo 명령이, 이
후 릴리스용으로 작성된 파일 시스템에 대해 실행되지 않을 수도 있기 때문입니다.
참고: v2 형식으로 작성되거나 변환된 JFS2 파일 시스템은 이전 AIX 릴리스에서는 액세스될 수 없습니다.
다음 리스트에서는 이전 버전의 운영 체제에서 작성된 파일 시스템에서 문제를 일으킬 수 있는 요소에 대해 설명
합니다.
JFS 파일 시스템 이미지
디폴트 프래그먼트 크기 및 NBPI 값 4096바이트와 디폴트 할당 그룹 크기(agsize) 8을 사용하여 작성된 모
든 JFS 파일 시스템 이미지는 특별한 이주 활동을 수행하지 않고도 AIX 4.3 및 이후 버전의 운영 체제에서 작
성된 JFS 파일 시스템 이미지와 교환할 수 있습니다.
주: JFS2 스냅샷: 5200-01 권장 유지보수 패키지를 포함한 AIX 5L 버전 5.2에서 작성되거나 액세스되는
JFS2 스냅샷은 이전 릴리스에서는 액세스할 수 없습니다. 파일 시스템을 마운트하려면 먼저 이러한 스냅샷
을 삭제해야 합니다.
JFS 파일 시스템 간 백업 및 복원
블록 크기가 서로 다른 JFS 파일 시스템 간에 백업과 복원을 순서대로 수행할 수 있습니다. 하지만 이러한 작
업을 수행할 때는 디스크 사용량이 늘어나므로 소스 파일 시스템의 블록 크기가 목표 파일 시스템의 블록 크
기보다 작을 경우, 사용 가능한 블록이 부족해서 복원 작업에 실패할 수 있습니다. 파일 시스템 전체 백업과
복원 작업을 순서대로 수행할 경우 특히 이 문제에 주의를 기울여야 합니다. 이 문제는 목표 파일 시스템의 총
파일 시스템 크기가 소스 파일 시스템의 총 파일 시스템 크기보다 크더라도 발생할 수 있습니다.
압축된 파일 시스템에서 압축되지 않은 파일 시스템으로 또는 프래그먼트 크기가 서로 다른 압축된 파일 시
스템 간에 백업과 복원 작업을 순서대로 수행할 수 있습니다. 하지만 압축된 파일 시스템에서는 디스크 공간
이 보다 효율적으로 사용되므로 디스크 공간 부족으로 인해 복원 작업에 실패할 수도 있습니다. 파일 시스템
전체 백업과 복원 작업을 순서대로 수행할 경우 특히 이 문제에 주의를 기울여야 합니다. 이 문제는 목표 파일
시스템의 총 파일 시스템 크기가 소스 파일 시스템의 총 파일 시스템 크기보다 크더라도 발생할 수 있습니다.
JFS 및 JFS2 장치 드라이버 제한
장치 드라이버는 JFS 파일 시스템 프래그먼트 크기 또는 JFS2 블록 크기와 같거나 작은 디스크 블록 주소 지
정 가능성을 제공해야 합니다. 예를 들어, 사용자가 제공한 RAM 디스크 장치 드라이버에 JFS 파일 시스템이
작성된 경우, 512바이트의 프래그먼트를 가진 파일 시스템을 포함할 수 있도록 드라이버가 512바이트 블록
을 허용해야 합니다. 드라이버가 페이지 레벨 주소 지정 가능성만 허용하는 경우에는 4096바이트 프래그먼
트 크기를 사용하는 JFS만 사용할 수 있습니다.
JFS를 다른 물리적 볼륨에 복사

파일 시스템의 무결성을 유지하면서 JFS 파일 시스템을 다른 물리적 볼륨에 복사할 수 있습니다.
다음 시나리오에서는 파일 시스템의 무결성을 유지하면서 JFS 파일 시스템을 다른 물리적 볼륨에 복사하는 방법
에 대해 설명합니다.
장치 관리 111
파일 시스템 무결성을 유지하면서 JFS를 다른 물리적 볼륨에 복사하려면 다음을 수행하십시오.
1. 복사할 파일 시스템의 활동을 정지하십시오. 파일 시스템을 사용하는 애플리케이션이 정지되거나 알려진 상
태에 있지 않은 한 백업 데이터에 무엇이 있는지 알 수 없습니다.
2. 명령행에서 다음 SMIT 단축 경로를 입력하여 논리적 볼륨을 미러링하십시오.
smit mklvcopy
3. 다음 명령을 사용하여 파일 시스템을 복사하십시오.

chfs -a splitcopy=/backup -a copy=2 /testfs
-a 플래그에 대한 splitcopy 매개변수로 인해 명령이 파일 시스템의 미러링된 사본을 분할하고 새로운 마

운트 위치에 읽기 전용으로 마운트합니다. 이 조치는 파일 시스템의 사본에게 백업에 사용할 수 있는 지속적
인 저널 메타 데이터를 제공합니다.
4. 미러링된 사본을 다른 마운트 위치로 이동하려면 다음 SMIT 단축 경로를 사용하십시오.
smit cplv
이 시점에서 파일 시스템이 사용 가능합니다.
CD-ROM 파일 시스템과 UDF 파일 시스템

CD-ROM 파일 시스템(CDRFS)은 CD-ROM 미디어, CD-RW 미디어(쓰기 보호된 경우) 및 DVD-ROM 미디어에 저
장되었을 수도 있는 읽기 전용 로컬 파일 시스템 구현입니다. 최대 CDRFS 파일 크기는 사용된 미디어에 관계 없
이 2GB입니다. 범용 디스크 형식(UDF) 파일 시스템은 DVD-ROM 미디어에 읽기 전용으로서 또는 DVD-RAM 미
디어에서 읽기-쓰기로서 저장되었을 수도 있는 쓰기 가능한 로컬 파일 시스템 구현입니다.
CD는 기본적으로 자동으로 마운트되지만 이 기능은 사용 안함으로 설정될 수 있습니다. 이 기능이 사용 안함으로
설정된 경우, CDRFS 파일 시스템을 마운트하려면 cdmount 명령을 사용하십시오.
AIX 에서 지원하는 CDRFS 볼륨 및 파일 구조 형식은 다음과 같습니다.
유형 설명
ISO 9660:1988(E) 표준 CDRFS가 ISO 9660 레벨 3 교환과 레벨 1 구현을 지원
합니다.
High Sierra 그룹 스펙 ISO 9660보다 우선순위가 높으며 이전 CD-ROM과의
호환성을 제공합니다.
Rock Ridge 그룹 프로토콜 ISO 9660과 완전하게 호환되며, SUSP(System Use
Sharing Protocol) 및 RRIP(Rock Ridge Interchange
Protocol)를 기반으로 전체 POSIX 파일 시스템 의미를
제공하는 ISO 9660에 대한 확장을 지정함으로써 다른
UNIX 파일 시스템과 마찬가지로 CD-ROM의 마운트
및 액세스를 가능하게 만듭니다.
CD-ROM eXtended Architecture 파일 형식(모드 2 양 CD-ROM XA(eXtended Architecture) 파일 형식은
식 1 섹터 형식만 해당) CD-ROM 기반 멀티미디어 애플리케이션(예: Photo
CD)에 사용되는 ISO 9660에 대한 확장을 지정합니다.
모든 볼륨 및 파일 구조 형식에는 다음과 같은 제한사항이 적용됩니다.

• 단일 볼륨의 볼륨 세트만 사용 가능
• 인터리브(interleave)되지 않은 파일만 사용 가능
물리적 섹터 형식(CD-ROM 모드 1 및 CD-ROM XA 모드 2 양식 1) 및 디스크의 다중 세션 형식(마지막 세션의 볼
륨 인식 영역에 있는 볼륨 설명자 세트에 맵핑)의 투명성을 제공하기 위해 CDRFS는 기본 CD-ROM 장치 드라이
버에 의존합니다.
참고: CD-ROM 미디어를 제거하려면 먼저 시스템에서 CDRFS를 마운트 해제해야 합니다.

UDFS라는 또 다른 지원되는 파일 시스템 유형이 있고, 이는 DVD-ROM 미디어에 저장되는 읽기 전용 파일 시스
템입니다. 미디어를 제거하기 전에 시스템에서 UDFS를 마운트 해제해야 합니다. AIX 에서는 UDFS 형식 버전
1.50, 2.00 및 2.01을 지원합니다.
UDFS는 읽기 전용 모드에서 NFS를 사용하여 반출되어야 합니다. NFS 마운트된 UDFS에 쓰기는 지원되지 않습
니다.
cdmount 명령을 사용하여 읽기/쓰기 UDFS를 자동 마운트하려면 cdromd.conf 파일을 편집하십시오. mount
명령을 사용하여 읽기/쓰기 UDFS를 수동으로 마운트할 수도 있습니다.
디렉토리
디렉토리는 파일 또는 다른 디렉토리에 액세스할 때 필요한 정보만을 포함하는 하나의 고유한 파일 유형입니다.
결과적으로 디렉토리는 파일의 다른 유형보다 적은 공간을 차지합니다.
파일 시스템은 디렉토리 그룹 및 디렉토리 내의 파일로 구성됩니다. 파일 시스템은 일반적으로 역 트리로 표현됩
니다. 슬래시(/) 기호로 선언되는 루트 디렉토리는 파일 시스템을 정의하며 파일 시스템 트리 다이어그램의 맨 위
에 나타납니다.
트리 다이어그램에서 디렉토리는 루트 디렉토리 아래로 분기되고 파일과 서브디렉토리 모두를 포함할 수 있습니
다. 분기되면서 파일 시스템의 모든 오브젝트에 대한 디렉토리 구조를 통해 고유한 경로를 작성합니다.
파일 집합은 디렉토리에 저장됩니다. 이러한 파일 집합은 서로 관련되므로, 이들을 디렉토리 구조에 저장하면 파
일들의 구성 관계가 유지됩니다.
파일은 읽거나 쓸 수 있는 데이터의 집합입니다. 파일은 사용자가 작성하는 프로그램, 작성하는 텍스트 및 얻은
데이터 또는 사용하는 장치가 될 수 있습니다. 명령, 프린터, 터미널, 통신문 및 애플리케이션은 모두 파일에 저장
됩니다. 따라서 일률적인 방법으로 시스템의 다양한 요소에 액세스할 수 있어서 파일 시스템의 유연성이 증대됩
니다.
디렉토리는 파일 및 다른 디렉토리를 그룹화하여 파일 시스템을 모듈 방식의 계층으로 구성할 수 있도록 하며, 이
는 파일 시스템 구조에 유연성과 깊이를 더해줍니다.
디렉토리에는 디렉토리 항목이 있습니다. 각 항목에는 파일 또는 서브디렉토리 이름 및 색인 노드 참조 번호(i-노
드 번호)가 있습니다. 디스크 공간 사용의 속도를 높이고 향상시키기 위해, 파일의 데이터는 컴퓨터 메모리의 다
양한 위치에 저장됩니다. i-노드 번호에는 파일과 관련된 데이터의 모든 분산된 블록을 찾을 때 사용하는 주소가
포함됩니다. 또한 i-노드 번호는 수정 및 액세스 시간, 액세스 모드, 링크 수, 파일 소유자 및 파일 유형 등 기타 파
일 정보를 씁니다.
특수 명령 세트가 디렉토리를 제어합니다. 예를 들어, ln 명령으로 디렉토리 항목을 작성하여 한 파일의 여러 이
름을 동일한 i-노드 번호에 링크할 수 있습니다.
디렉토리가 시스템의 모든 사용자가 사용할 수 없는 정보를 포함할 때도 많기 때문에, 디렉토리 액세스는 보호될
수 있습니다. 디렉토리의 권한을 설정하여, 디렉토리에 대한 액세스 제어를 할 수 있고 또한 어떤 사용자가 디렉
토리 내에서 정보를 변경할 수 있는지를(사용자가 있는 경우) 결정할 수 있습니다.
디렉토리 유형
디렉토리는 운영 체제, 시스템 관리자 또는 사용자가 정의할 수 있습니다.
시스템 정의 디렉토리는 명령과 같은 특정 유형의 시스템 파일을 포함합니다. 파일 시스템 계층의 맨 위에는 시스
템 정의 /(root) 디렉토리가 있습니다. /(root) 디렉토리에는 항상 다음과 같은 표준 시스템 관련 디렉토리
가 포함됩니다.
항목 설명
/dev 입출력 장치를 위한 특수 파일이 들어 있습니다.
/etc 시스템 초기화 및 시스템 관리를 위한 파일이 들어 있습니다.
/home 시스템 사용자를 위한 로그인 디렉토리가 들어 있습니다.
/tmp 임시 파일 및 지정된 날짜가 지나면 자동으로 삭제되는 파일이 들어 있습니다.
/usr lpp, include 및 다른 시스템 디렉토리가 있습니다.
/usr/bin 사용자 실행 가능 프로그램이 들어 있습니다.
장치 관리 113
로그인 또는 홈 디렉토리($HOME)와 같은 몇몇 디렉토리는 시스템 관리자에 의해 정의되고 조정됩니다. 운영 체
제에 로그인할 때는 로그인 디렉토리가 현재 디렉토리가 됩니다.
사용자가 작성한 디렉토리는 사용자 정의 디렉토리라고 합니다. 이러한 디렉토리를 이용하면 파일을 구성 및 유
지할 수 있습니다.
디렉토리 조직
디렉토리에는 파일, 서브디렉토리 또는 이 둘의 조합이 들어 있습니다. 서브디렉토리는 디렉토리 내에 있는 디렉
토리입니다. 서브디렉토리를 포함한 디렉토리를 상위 디렉토리라고 합니다.
각 디렉토리에는 디렉토리가 작성된 상위 디렉토리의 항목, ..(이중점)이 있고, 디렉토리 자체, . (점)에 대한 항
목이 있습니다. 대부분의 디렉토리 목록에서는 이러한 파일은 숨겨져 있습니다.
디렉토리 트리
디렉토리의 파일 시스템 구조는 복잡해지기 쉽습니다. 파일 및 디렉토리 구조를 가능하면 단순하게 유지하려
고 하십시오. 파일 및 디렉토리를 인식하기 쉬운 이름으로 작성하십시오. 그러면 파일에 대해 작업하기가 쉬
워집니다.
상위 디렉토리
/(root)를 제외한 각 디렉토리에는 하나의 상위 디렉토리가 있고 하위 디렉토리가 있을 수 있습니다.
홈 디렉토리
로그인하면, 시스템은 사용자를 홈 디렉토리 또는 로그인 디렉토리에 놓습니다. 이러한 디렉토리는 시스템
관리자가 각각의 사용자에 대해 설정합니다. 홈 디렉토리는 개인 파일을 위한 저장소입니다. 보통, 사용자 자
신을 위해 만든 디렉토리는 홈 디렉토리의 서브디렉토리가 됩니다. 언제든지 홈 디렉토리로 돌아가려면, 프
롬프트에서 cd 명령을 입력한 후 Enter를 누르십시오.
작업 디렉토리
사용자는 항상 한 디렉토리 안에서 작업합니다. 현재 작업 중인 디렉토리를 현재 또는 작업 디렉토리라고 합
니다. pwd(작업 디렉토리 표시) 명령은 사용자의 작업 디렉토리 이름을 알려줍니다. 작업 디렉토리를 변경하
려면 cd 명령을 사용하십시오.
디렉토리 이름 지정 규칙
각 디렉토리 이름은 저장되어 있는 디렉토리 내에서 고유해야 합니다. 이름이 고유해야 디렉토리가 파일 시스템
에서 고유한 경로 이름을 가지고 있음을 보장할 수 있습니다.
디렉토리는 파일 이름 지정 규칙에서 설명한 대로 파일과 동일한 이름 지정 규칙을 준수합니다.
디렉토리 약어
약어는 특정 디렉토리를 지정하는 편리한 방법입니다.
다음은 약어 리스트입니다.
약어 의미
. 현재 작업 디렉토리입니다.
.. 현재 작업 디렉토리 위의 디렉토리(현재 디렉토리의 상위)입니다.
~ 홈 디렉토리입니다. (Bourne 쉘에는 적용되지 않습니다. 자세한 정보는 Bourne 쉘을
참조하십시오.)
$HOME 홈 디렉토리입니다. (모든 쉘에 적용)
디렉토리 경로 이름
각 파일 및 디렉토리는 파일 시스템 트리 구조 전반에 걸쳐 경로 이름이라고 하는 고유한 경로에 의해 이를 수 있
습니다. 경로 이름은 파일 시스템 내에서 디렉토리 또는 파일의 위치를 지정합니다.
참고: 경로 이름은 1023자를 초과할 수 없습니다.
파일 시스템은 다음과 같은 유형의 경로 이름을 사용합니다.
항목 설명
절대 경로 이름 /(root) 디렉토리에서부터 경로를 추적합니다. 절대 경로 이름은 항상 슬
래시(/) 기호로 시작합니다.

항목 설명
상대 경로 이름 현재 디렉토리에서 상위 또는 서브디렉토리 또는 파일에 걸쳐 경로를 추적
합니다.
절대 경로 이름은 /(root) 디렉토리에서부터 아래 방향으로 디렉토리 또는 파일의 완전한 이름을 말합니다. 파

일 시스템 어디에서 작업하든지, 해당 절대 경로 이름을 지정하여 파일 또는 디렉토리를 찾을 수 있습니다. 절대
경로 이름은 루트 디렉토리를 나타내는 기호인 슬래시(/)로 시작합니다. 경로 이름 /A/D/9은 9를 위한 절대 경
로 이름입니다. 최초 슬래시( /)는 검색을 위한 시작 지점인 /(root) 디렉토리를 나타냅니다. 경로 이름의 나머
지는 A, 그 다음 D, 마지막으로 9의 순서로 검색을 수행하도록 지시합니다.
9라는 이름의 파일 두 개가 있습니다. 이는 파일에 대한 절대 경로 이름이 파일 시스템 내에서 고유한 이름을 파일
에 지정하기 때문에 가능합니다. 경로 이름 /A/D/9 및 /C/E/G/9는 9라는 고유한 두 파일을 지정합니다.
전체 경로 이름과는 달리, 상대 경로 이름은 현재의 작업 디렉토리를 기준으로 해서 디렉토리 또는 파일을 지정합
니다. 상대 경로 이름의 경우, 이중점(..) 표기법을 사용하여 파일 시스템 계층의 위쪽으로 이동할 수 있습니다. 이
중점(..)은 상위 디렉토리를 나타냅니다. 상대 경로 이름은 현재 디렉토리에서 시작 경로를 지정하므로 슬래시(/)
로 시작하지 않습니다. 상대 경로 이름은 현재 디렉토리의 파일 또는 파일 시스템의 현재 디렉토리의 위 또는 아
래 레벨의 파일 또는 디렉토리의 경로 이름을 지정할 때 사용됩니다. D가 현재 디렉토리일 경우, 10에 액세스하
기 위한 상대 경로 이름은 F/10입니다. 그러나 절대 경로 이름은 항상 /A/D/F/10입니다. 또한 3에 액세스하기
위한 상대 경로 이름은 ../../B/3입니다.
점 표기법(.)을 사용하여 현재 디렉토리의 이름을 표시할 수도 있습니다. . 점(.) 표기법은 현재 디렉토리 이름을
읽는 프로그램을 실행할 때 주로 사용됩니다.
디렉토리 작성(mkdir 명령)

mkdir 명령을 사용하여 Directory 매개변수에 의해 지정된 하나 이상의 새로운 디렉토리를 작성합니다.
각 새로운 디렉토리는 표준 항목 점(.) 및 이중점(..)을 포함합니다. -m Mode 플래그를 사용하여 새로운 디렉토
리에 대한 사용 권한을 지정할 수 있습니다.
디렉토리 작성 시, 파일 시스템의 다른 위치로 절대 경로 이름을 지정하지 않으면 디렉토리가 현재 또는 작업 디
렉토리에 작성됩니다.
다음은 mkdir 명령을 사용하는 방법의 예제입니다.
• 현재 작업 디렉토리에 디폴트 권한을 갖는 Test라는 새로운 디렉토리를 작성하려면 다음을 입력하십시오.
mkdir Test
• 이전에 작성된 /home/demo/sub1 디렉토리에 rwxr-xr-x 권한을 가진 Test라는 디렉토리를 작성하려면

다음을 입력하십시오.
mkdir -m 755 /home/demo/sub1/Test
• 디폴트 권한이 있는 Test라는 디렉토리를 /home/demo/sub2 디렉토리에 작성하려면 다음을 입력하십시

오.
mkdir -p /home/demo/sub2/Test
-p 플래그는 /home, /home/demo 및 /home/demo/sub2 디렉토리를 작성합니다(기존에 없는 경우).
디렉토리 이동 또는 이름 바꾸기(mvdir 명령)

mvdir 명령을 사용하면 디렉토리를 이동하거나 이름을 변경할 수 있습니다.
다음은 mvdir 명령을 사용하는 방법에 대한 예제입니다.
• 디렉토리를 이동하려면 다음을 입력하십시오.
mvdir book manual
manual 디렉토리가 있는 경우, manual이라는 이름의 디렉토리 아래에 있는 book 디렉토리가 이동됩니다.
또는 book 디렉토리가 manual로 이름이 바뀔 수도 있습니다.
장치 관리 115
• 디렉토리를 이동하고 이름을 변경하려면 다음을 입력하십시오.
mvdir book3 proj4/manual
manual이라는 이름의 디렉토리가 이미 있으면 book3 및 해당 내용이 proj4/manual로 이동됩니다. 즉,

book3이 proj4/manual의 서브디렉토리가 됩니다. 매뉴얼이 없으면 book3 디렉토리가 proj4/manual
로 이름이 바뀝니다.
현재 디렉토리 표시(pwd 명령)

pwd 명령을 사용하여 /(root) 디렉토리에서 사용자의 현재 디렉토리의 전체 경로 이름을 표준 출력에 쓸 수 있
습니다.
모든 디렉토리는 슬래시(/)로 구분됩니다. /(root) 디렉토리는 첫 번째 슬래시(/)로 표현되며, 이름 붙여진 최
종 디렉토리가 현재 디렉토리가 됩니다.
예를 들면, 현재 디렉토리를 표시하려면 다음을 입력하십시오.
pwd
현재 디렉토리의 전체 경로 이름이 다음과 같이 표시됩니다.

/home/thomas
다른 디렉토리로 변경(cd 명령)

현재 디렉토리에서 다른 디렉토리로 이동하려면 cd 명령을 사용하십시오. 사용자는 지정된 디렉토리의 실행(검
색) 권한을 가지고 있어야 합니다.
Directory 매개변수를 지정하지 않은 경우, cd 명령을 사용하면 로그인 디렉토리로 이동합니다(ksh 및 bsh 환경
에서는 $HOME, csh 환경에서는 $home). 지정한 디렉토리 이름이 전체 경로 이름이면, 이는 현재 디렉토리가 됩
니다. 전체 경로 이름은 슬래시(/)로 시작하여 /(root) 디렉토리를 나타내고, 점(.)으로 시작하면 현재 디렉토
리를 나타내거나 이중점(..)으로 시작하면 상위 디렉토리를 나타냅니다. 디렉토리 이름이 전체 경로 이름이 아
닐 경우, cd 명령이 $CDPATH 쉘 변수(또는 $cdpath csh 변수)로 지정된 경로 중 하나와 관련하여 디렉토리 이
름을 검색합니다. 이 변수는 $PATH 쉘 변수(또는 $path csh 변수)와 동일한 구문 및 유사한 의미를 가집니다.
다음은 cd 명령을 사용하는 방법에 대한 예제입니다.
• 홈 디렉토리로 변경하려면 다음을 입력하십시오.
cd
• /usr/include 디렉토리로 변경하려면 다음을 입력하십시오.
cd /usr/include
• 디렉토리 트리에서 한 레벨 아래인 sys로 이동하려면 다음을 입력하십시오.
cd sys
현재 디렉토리가 /usr/include이고 이 디렉토리에 sys라는 서브디렉토리가 있을 경우, /usr/

include/sys가 현재 디렉토리가 됩니다.
• 디렉토리 트리에서 한 레벨 위로 가려면 다음을 입력하십시오.
cd ..
특수 파일 이름인 이중점(..)은 현재 디렉토리의 바로 위 디렉토리인 상위 디렉토리를 나타냅니다.
디렉토리 복사(cp 명령)

cp 명령을 사용하면 SourceFile 또는 SourceDirectory 매개변수로 지정된 파일 또는 디렉토리의 컨텐츠 사본을
TargetFile 또는 TargetDirectory 매개변수로 지정된 파일 또는 디렉토리에 복사할 수 있습니다.
TargetFile로 지정된 파일이 존재할 경우, 사본은 파일의 원래 컨텐츠를 겹쳐씁니다. 두 개 이상의 SourceFile을
복사하는 경우에는 목표가 디렉토리여야 합니다.

SourceFile의 사본을 디렉토리에 배치하려면 경로를 TargetDirectory 매개변수에 대한 기존 디렉토리로 지정하
십시오. 경로 끝에 새로운 파일 이름을 지정하지 않는 한, 파일은 디렉토리에 복사되어도 각자의 이름을 유지합니
다. 또한 -r 또는 -R 플래그를 지정한 경우 cp 명령은 전체 디렉토리를 다른 디렉토리로 복사합니다.
다음은 cp 명령을 사용하는 방법에 대한 예제입니다.
• /home/accounts/customers/orders 디렉토리에 있는 모든 파일을 /home/accounts/customers/
shipments 디렉토리로 복사하려면 다음을 입력하십시오.
cp /home/accounts/customers/orders/* /home/accounts/customers/shipments
그러면 orders 디렉토리에서 shipments 디렉토리로 디렉토리가 아니라 파일이 복사됩니다.

• 모든 파일 및 서브디렉토리를 포함하여 하나의 디렉토리를 다른 디렉토리에 복사하려면 다음을 입력하십시오.
cp -R /home/accounts/customers /home/accounts/vendors
이 명령은 모든 파일, 서브디렉토리 및 서브디렉토리의 파일을 포함하여 customers 디렉토리를 vendors 디

렉토리로 복사합니다.
디렉토리의 컨텐츠 표시
디렉토리의 컨텐츠를 표시하려면 ls 명령을 사용하십시오.
ls 명령은 플래그로 요청한 정보와 함께 지정된 디렉토리 내용 및 지정된 파일의 이름을 표준 출력에 씁니다. 파
일 또는 디렉토리를 지정하지 않을 경우, ls 명령은 현재 디렉토리의 컨텐츠를 표시합니다.
디폴트로, ls 명령은 파일 이름의 알파벳 순으로 모든 정보를 표시합니다. 명령이 루트 권한이 있는 사용자에 의
해 실행되는 경우, 이는 기본적으로 -A 플래그를 사용하여 점(.)과 이중점(..)을 제외한 모든 항목을 나열합니
다. 점(.)으로 시작하는 파일을 포함하여 파일에 대한 모든 항목을 표시하려면, ls -a 명령을 사용하십시오.
다음의 방법으로 출력을 형식화할 수 있습니다.
• -l 플래그를 사용하여 행 당 하나의 항목을 나열합니다.
• -C 또는 -x 플래그를 지정하여 여러 열에 항목을 나열합니다. -C 플래그는 tty로 출력될 때 디폴트 형식입니다.
• -m 플래그를 지정하여 쉼표로 분리되게 항목을 나열합니다.
출력 행에서 문자 위치 수를 결정하기 위해 ls 명령은 $COLUMNS 환경 변수를 사용합니다. 이 변수를 설정하지
않으면, 명령은 terminfo 파일을 읽습니다. 이 두 가지 메소드로도 ls 명령이 문자 위치 수를 결정할 수 없을 경
우, 디폴트 값 80을 사용합니다.
-e와 -l 플래그로 표시된 정보는 다음과 같이 해석됩니다.
첫 번째 문자는 다음 중 한 가지일 수 있습니다.
항 설명
목
d 항목이 디렉토리입니다.
b 항목이 블록 특수 파일입니다.
c 항목이 문자 특수 파일입니다.
l 항목이 기호 링크입니다.
p 항목이 선입선출(FIFO) 파이프 특수 파일입니다.
s 항목이 로컬 소켓입니다.
- 항목이 보통 파일입니다.
다음 9개 문자는 각각 3 문자로 된 3개의 집합으로 나누어집니다. 최초 세 개의 문자는 파일 또는 디렉토리 소유

자의 사용 권한을 표시합니다. 다음의 세 문자는 그룹에 있는 다른 사용자들의 사용 권한을 표시합니다. 마지막
세 문자는 파일에 액세스할 수 있는 기타 다른 사용자의 사용 권한입니다. 각 집합의 3개의 문자는 해당 파일에 대
한 읽기, 쓰기 및 실행 권한을 표시합니다. 디렉토리의 실행 권한이 있으면, 사용자는 지정된 파일에 대해 디렉토
리를 검색할 수 있습니다.
장치 관리 117
사용 권한은 다음과 같이 지시됩니다.
항 설명
목
r 읽기 권한 부여
t 다른 사용자들이 디렉토리에 대한 쓰기 권한이 있더라도 디렉토리 소유자 또는 파일 소유자만이 해당 디
렉토리의 파일을 삭제 또는 이름 바꾸기할 수 있습니다.
w 쓰기(편집) 권한 부여
x 실행(검색) 권한 부여
- 상응하는 권한이 부여되지 않음
-e 플래그로 표시된 정보는 추가된 11번째 문자가 다음과 같이 해석되는 것을 제외하고는 -l 플래그와 같습니다.
항 설명
목
+ 파일이 확장된 보안 정보를 가지고 있음을 가리킵니다. 예를 들어, 파일이 모드에서 ACL, TCB 또는 TP 속
성을 확장했을 수 있습니다.
- 파일이 확장된 보안 정보를 가지지 않음을 가리킵니다.
디렉토리의 파일 크기가 나열될 때, ls 명령은 간접 블록을 포함한 블록의 전체 계수를 나열합니다.

다음 예를 참조하십시오.
• 현재 디렉토리의 모든 파일을 나열하려면 다음을 입력하십시오.
ls -a
다음을 포함한 모든 파일을 나열합니다.

– 점(.)
– 이중점(..)(. .)
– 이름이 점(.)으로 시작하거나 시작하지 않는 기타 파일
• 상세 정보를 표시하려면 다음을 입력하십시오.
ls -l chap1 .profile
그러면 chap1 및 .profile에 대한 상세 정보가 있는 긴 리스트가 표시됩니다.

• 디렉토리에 대한 자세한 정보를 표시하려면 다음을 입력하십시오.
ls -d -l . manual manual/chap1
이는 . 및 manual 디렉토리 및 manual/chap1 파일의 긴 리스트를 표시합니다. -d 플래그가 없이는 이는 디

렉토리 자체에 대한 자세한 정보 대신에 파일을 . 및 manual 디렉토리에 나열합니다.
디렉토리 삭제 또는 제거(rmdir 명령)

rmdir 명령을 사용하여, Directory 매개변수에 지정된 디렉토리를 시스템에서 제거할 수 있습니다.
디렉토리는 제거하기 전에 비어 있어야 하고(. 및 ..만을 포함할 수 있음) 해당 상위 디렉토리에 쓰기 권한이 있
어야 합니다. ls -a Directory 명령을 사용하여 디렉토리가 비어 있는지 확인하십시오.
다음은 rmdir 명령을 사용하는 방법에 대한 예제입니다.
• 디렉토리를 비우고 제거하려면 다음을 입력하십시오.
rm mydir/* mydir/.*
rmdir mydir

이는 mydir의 내용을 제거한 후, 빈 디렉토리를 제거합니다. rm 명령이 디렉토리 점(.)과 이중점(..)을 제거
하려는 시도에 대한 오류 메시지를 표시한 다음 rmdir 명령이 이들과 디렉토리 자체를 제거합니다.
참고: rm mydir/* mydir/.*는 점으로 시작하지 않는 이름을 가진 파일을 먼저 제거한 후, 점으로 시작하
는 이름을 가진 파일을 제거함을 주의하십시오. ls 명령은 -a 플래그를 사용하지 않는 한 점으로 시작하는 파
일 이름을 나열하지 않습니다.
• /tmp/jones/demo/mydir 디렉토리와 하위의 모든 디렉토리들을 제거하려면 다음을 입력하십시오.
cd /tmp
rmdir -p jones/demo/mydir
jones/demo/mydir 디렉토리가 /tmp 디렉토리에서 제거됩니다. 디렉토리를 제거할 때 디렉토리가 비어 있

지 않거나 쓰기 권한이 없으면, 명령이 해당 오류 메시지와 함께 종료됩니다.
디렉토리의 컨텐츠 비교(dircmp 명령)

dircmp 명령을 사용하여 Directory1과 Directory2 매개변수로 지정된 두 디렉토리를 비교하고, 그 컨텐츠에 대
한 정보를 표준 출력에 쓸 수 있습니다.
먼저, dircmp 명령이 각 디렉토리에서 파일 이름을 비교합니다. 같은 파일 이름이 둘 다에 포함되어 있으면,
dircmp 명령은 두 파일의 컨텐츠를 비교합니다.
출력에서 dircmp 명령은 각 디렉토리에 고유한 파일을 나열합니다. 그런 다음 양쪽 디렉토리에서 이름은 같고
컨텐츠는 다른 파일을 나열합니다. 플래그를 지정하지 않으면, 두 디렉토리에서 동일한 이름뿐만 아니라 동일한
컨텐츠를 가지는 파일도 나열합니다.
다음은 dircmp 명령을 사용하는 방법의 예제입니다.
• proj.ver1과 proj.ver2 디렉토리의 파일 간의 차이점을 요약하려면 다음을 입력하십시오.
dircmp proj.ver1 proj.ver2
그러면 proj.ver1과 proj.ver2 디렉토리 간의 차이점이 요약되어 표시됩니다. 요약은 한 디렉토리에만 있

는 파일과 둘 다에 있는 파일을 각각 나열합니다. 파일이 두 디렉토리 모두에 있으면, dircmp 명령은 두 개의
사본이 동일한지를 나타냅니다.
• proj.ver1과 proj.ver2 디렉토리에 있는 파일들 간 차이점의 세부사항을 표시하려면 다음을 입력하십시
오.
dircmp -d -s proj.ver1 proj.ver2
-s 플래그는 동일한 파일에 대한 정보를 억제합니다. -d 플래그는 두 디렉토리 모두에 있는 다른 파일들 각각에
대한 diff 목록을 표시합니다.
파일 시스템 및 디렉토리용 명령 요약
다음은 파일 시스템 및 디렉토리용 명령, 디렉토리 처리 프로시저용 명령 및 디렉토리 약어 리스트입니다.
표 6. 파일 시스템용 명령 요약
항목 설명
df 파일 시스템의 영역에 대한 정보를 보고합니다.
표 7. 디렉토리 약어
항목 설명
. 현재 작업 디렉토리입니다.
.. 현재 작업 디렉토리 위의 디렉토리(상위 디렉토리)입니다.
~ 홈 디렉토리입니다. (Bourne 쉘에는 적용되지 않습니다. 자세한 정보는 Bourne 쉘을 참조
하십시오.)
$HOME 홈 디렉토리입니다. (모든 쉘에 적용)
장치 관리 119
표 8. 디렉토리 처리 프로시저용 명령 요약
항목 설명
cd 현재 디렉토리를 변경합니다.
cp 파일 또는 디렉토리를 복사합니다.
dircmp 두 개의 디렉토리 및 공통 파일의 컨텐츠를 비교합니다.
ls 디렉토리의 컨텐츠를 표시합니다.
mkdir 하나 이상의 새로운 디렉토리를 작성합니다.
mvdir 디렉토리를 이동(이름 바꾸기)합니다.
pwd 작업 디렉토리의 경로 이름을 표시합니다.
rmdir 디렉토리를 제거합니다.
워크로드 관리자
워크로드 관리자(WLM)는 스케줄러 VMM(virtual memory manager)과 디스크 입출력 서브시스템이 처리할 자
원을 할당하는 방법을 시스템 관리자가 보다 잘 제어할 수 있도록 해줍니다.
WLM을 사용하여 다른 작업 클래스들이 서로 방해하는 것을 막고 다른 사용자 그룹의 요구사항에 따라 자원을 할
당할 수 있습니다.
주의: WLM을 효율적으로 사용하려면 기존의 시스템 프로세스와 성능에 대해 자세히 알고 있어야 합니
다. 시스템 관리자가 WLM을 정확하지 않거나 극단적인 값으로 구성하면 성능이 크게 저하됩니다.
WLM은 주로 큰 시스템에 사용됩니다. 큰 시스템은 시스템 유지보수 비용을 줄이기 위해 여러 서버 시스템(예: 프
린터, 데이터베이스, 일반 사용자, 트랜잭션 처리 시스템)의 워크로드를 하나의 큰 시스템으로 결합하는 서버 통
합에 사용되기도 합니다. 이러한 워크로드는 종종 서로에게 방해가 되며 다른 목적과 서비스 계약을 갖습니다.
또한 WLM은 시스템 동작이 매우 다른 사용자 공동체를 서로 격리시킵니다. 특정 동작(예: 대화식 또는 낮은 CPU
사용량 작업)을 보이는 워크로드의 부족을 다른 동작을 나타내는 워크로드(예: 일괄처리 또는 상위 메모리 사용
법 작업)를 통해 효과적으로 막을 수 있습니다.
또한 WLM은 사용자가 사용자 또는 그룹별 표준 사용통계에 추가로 WLM 클래스별 자원 사용량 사용통계를 수행
할 수 있도록 허용하는 사용통계 서브시스템에 묶입니다.
워크로드 관리 개념
WLM을 사용하여 작업에 대해 다른 서비스 클래스를 작성하고 해당 클래스의 속성을 지정할 수 있습니다.
이러한 속성은 클래스에 할당할 CPU의 최소 및 최대량, 실제 메모리, 디스크 입출력 처리량을 지정합니다. 그런
다음, WLM은 시스템 관리자가 제공한 클래스 지정 규칙을 사용하여 작업을 클래스에 자동으로 지정합니다. 이러
한 지정 규칙은 프로세스의 속성 세트 값을 기준으로 합니다. 시스템 관리자 또는 특권 사용자도 작업을 클래스에
자동으로 지정하여 자동 지정을 재정의할 수 있습니다.
워크로드 관리에 대한 용어
이 표는 워크로드 관리와 연관된 일반 용어 리스트 및 설명입니다.
항목 설명
클래스 클래스는 프로세스 및 연관된 스레드의 집합입니다. 클래스에는 자원 제한 값과
목표 공유의 단일 세트가 있습니다. 클래스는 서브클래스와 수퍼클래스 둘 모두
를 설명하는 데 사용됩니다.

항목 설명
수퍼클래스 수퍼클래스는 수퍼클래스와 연관된 서브클래스가 있는 클래스입니다. 프로세
스는 서브클래스에 속하지 않으면 수퍼클래스에 속할 수 없습니다. 수퍼클래스
에는 수퍼클래스에 어떤 프로세스가 지정되는지를 판별하는 클래스 지정 규칙
세트가 있습니다. 수퍼클래스에는 또한 수퍼클래스에 속하는 프로세스가 사용
할 수 있는 자원의 양을 판별하는 자원 한계 값과 자원 대상 공유 세트가 있습니
다. 이러한 자원은 서브클래스의 자원 제한 값과 자원 목표 공유에 따라 서브클
래스에 분배됩니다.
서브클래스 서브클래스는 정확히 하나의 수퍼클래스와 연관된 클래스입니다. 서브클래스
의 모든 프로세스는 수퍼클래스의 멤버이기도 합니다. 서브클래스는 수퍼클래
스에 사용할 수 있는 자원에만 액세스합니다. 서브클래스에는 서브클래스에 속
한 수퍼클래스에 지정할 프로세스를 결정하는 클래스 지정 규칙 세트가 있습니
다. 또한 서브클래스에는 서브클래스의 프로세스에 사용할 수 있는 자원을 결정
하는 자원 제한 값과 자원 목표 공유 세트가 있습니다.
이러한 자원 제한 값과 자원 목표 공유는 서브클래스의 프로세스가 사용할 수
있는 수퍼클래스(수퍼클래스의 목표)에서 사용할 수 있는 자원의 양을 표시합
니다.
WLM 관리는 SMIT 또는 WLM 명령행 인터페이스를 사용하여 수행할 수 있습니
다.
분류 메커니즘 분류 메커니즘은 어떤 프로세스가 어떤 클래스에 지정되는지를 판별하는 클래

스 지정 규칙 세트입니다(수퍼클래스 또는 수퍼클래스 내의 서브클래스).
클래스 지정 규칙 클래스 지정 규칙은 특정 클래스(수퍼클래스 또는 수퍼클래스 내의 서브클래
스)에 지정할 프로세스의 프로세스 속성 결과 세트 내의 값을 표시합니다.
프로세스 속성값 프로세스 속성값은 프로세스가 프로세스 속성에 대해 갖는 값입니다. 프로세스
속성은 사용자 ID, 그룹 ID 및 응용프로그램 경로 이름과 같은 속성을 포함할 수
있습니다.
자원 제한 값 자원 제한 값은 WLM이 자원 사용량 값에 대해 유지하는 값 세트입니다. 이러한
제한은 setrlimit 서브루틴을 사용하여 지정한 자원 제한과는 완전히 별개입
니다.
자원 목표 공유 자원 목표 공유는 클래스(서브클래스 또는 수퍼클래스)에 사용할 수 있는 자원
의 공유입니다. 이러한 공유는 같은 레벨과 티어에서 다른 클래스 공유(서브클
래스 또는 수퍼클래스)와 함께 사용되어 해당 레벨과 티어의 클래스 사이에 원
하는 자원의 분배를 결정합니다.
자원 사용량 값 자원 사용량 값은 프로세스 또는 프로세스 세트가 시스템에서 현재 사용 중인
자원의 양입니다. 하나의 프로세스인지 또는 프로세스 세트인지는 프로세스 자
원 집합의 범위에 의해 결정됩니다.
자원 집합의 범위 자원 집합의 범위는 자원 사용량이 수집되는 레벨과 자원 제한 값이 적용되는
레벨입니다. 이 레벨은 클래스의 각 프로세스 레벨, 각 사용자가 소유한 클래스
의 모든 프로세스에 대한 합계의 레벨, 클래스의 모든 프로세스에 대한 합계의
레벨이 될 수 있습니다. 현재 후자만 유일하게 지원됩니다.
프로세스 클래스 특성 프로세스 클래스 특성은 지정된 클래스(서브클래스 및 수퍼클래스)에 따라 프
로세스에 지정된 특성 세트입니다.
클래스 권한 부여 클래스 권한 부여는 클래스 또는 클래스의 프로세스와 스레드에 대한 조작을 수
행할 수 있는 사용자와 그룹을 표시하는 규칙 세트입니다. 여기에는 프로세스를
클래스에 수동으로 지정하거나 수퍼클래스의 서브클래스를 작성하는 권한 부
여가 포함됩니다.
장치 관리 121
항목 설명
클래스 티어 클래스 티어 값은 모든 클래스에 권장되는 자원 제한 계층 내의 클래스 위치입
니다. 낮은 티어 클래스에 자원을 제공하려면 티어의 모든 클래스에 대한 자원
제한(자원 목표 포함)이 충족되어야 합니다. 티어는 수퍼클래스와 서브클래스
레벨에 모두 제공됩니다. 자원은 해당 티어를 기반으로 수퍼클래스에 제공됩니
다. 수퍼클래스 내에서 자원은 수퍼클래스 내의 티어 값에 따라 서브클래스에
제공됩니다. 그러므로 수퍼클래스 티어는 자원 분배의 주요한 구별자이며 서브
클래스 티어는 수퍼클래스 내에 이보다 추가 구별자를 제공합니다.
워크로드 관리용 클래스

WLM을 사용하여 시스템 관리자는 클래스를 정의하고 각 클래스에 대해 속성과 자원 제한 세트를 정의할 수 있습
니다.
시스템 관리자가 제공하는 기준에 따라 클래스에 프로세스가 지정됩니다. 자원 인타이틀먼트와 제한은 클래스
레벨에 적용됩니다. 서비스의 클래스를 정의하고 각 애플리케이션 클래스의 자원 사용량을 조정하는 이 메소드
를 사용하면 다른 자원 사용 패턴을 가진 애플리케이션들이 단일 서버를 공유할 때 서로 방해하지 않습니다.
WLM은 두 레벨의 클래스 계층을 지원합니다.
• 각 수퍼클래스의 자원 인타이틀먼트에 따라 시스템의 자원이 수퍼클래스 사이에 분배됩니다. 시스템 관리자는
자원 인타이틀먼트를 정의합니다.
• 각 수퍼클래스는 서브클래스를 포함할 수 있습니다. 수퍼클래스에 할당된 자원은 각 서브클래스에 제공된 자
원 인타이틀먼트에 따라 서브클래스 사이에 분배됩니다.
• 시스템 관리자는 각 수퍼클래스의 서브클래스 관리를 수퍼클래스 관리자 또는 수퍼클래스 관리자 그룹에 위임
• WLM은 최대 69개의 수퍼클래스(64개의 사용자 정의)와 수퍼클래스당 64개의 서브클래스(61개 사용자 정의)
를 지원합니다.
• 시스템 관리자는 조직의 요구에 따라 수퍼클래스만 사용할 것인지 또는 수퍼클래스와 서브클래스를 사용할 것
인지 결정할 수 있습니다.
참고: WLM에 대한 설명에서 클래스란 용어는 수퍼클래스와 서브클래스에 모두 적용됩니다. 특정 클래스 유형에
대해 설명할 경우에는 해당 유형을 명시합니다.
워크로드 관리를 위해 클래스에 프로세스 지정

프로세스는 시스템 관리자가 제공하는 클래스 지정 규칙을 사용하여 클래스에 지정됩니다. 분류 기준은 사용자
ID, 그룹 ID, 애플리케이션 파일 이름, 프로세스 유형 및 애플리케이션 태그와 같은 프로세스의 속성 세트 값을 기
준으로 합니다.
정의된 규칙 세트는 프로세스가 지정된 수퍼클래스를 확인하는 데 사용됩니다. 이 수퍼클래스에 서브클래스가
정의되어 있는 경우 어떤 서브클래스가 어떤 프로세스에 지정되었는지 확인할 수 있도록 수퍼클래스에 대한 또
다른 규칙 세트가 있는 것입니다. 이 자동 지정 프로세스에서는 또한 수퍼클래스와 서브클래스의 inheritance
속성도 고려합니다
프로세스에서 exec 서브루틴을 호출하면 자동 클래스 지정이 수행됩니다. 분류용으로 사용되는 프로세스 속성
을 변경할 수 있는 서브루틴을 프로세스에서 사용하면 클래스 지정이 재평가됩니다. 그러한 예로는 setuid,
setgid, setpri 및 plock 서브루틴이 있습니다.
이러한 자동 클래스 지정 이외에도 적절한 권한이 있는 사용자는 프로세스 또는 프로세스 그룹을 수동으로 특정
수퍼클래스 또는 서브클래스에 지정할 수 있습니다.
관련 개념
클래스 속성
WLM 클래스의 모든 속성을 나열하십시오.
자원 제어
WLM을 사용하여 사용 가능한 자원의 백분율 또는 총 자원 사용량에 따라 자원을 관리할 수 있습니다.
백분율에 따라 제어할 수 있는 자원은 다음과 같습니다.

• 클래스에서 SCHED_OTHER 유형 스레드의 프로세서 사용. 클래스의 모든 스레드가 사용하는 모든 프로세스
순환의 합계입니다. 고정 우선순위 스레드는 조정할 수 없습니다. 그러므로 변경할 수 없으며 프로세서 사용량
목표가 초과될 수 있습니다.
• 클래스에서 프로세스의 실제 메모리 사용량. 클래스의 프로세스에 속한 모든 메모리 페이지의 합계입니다.
• 클래스의 디스크 입출력 대역폭. 클래스가 액세스하는 각 디스크 장치에 있는 클래스의 스레드에 의해 시작된
모든 입출력의 대역폭(초당 512바이트 블록)입니다.
총 사용량에 따라 제어할 수 있는 자원은 두 범주, 즉 총 클래스 또는 총 프로세스 중 하나에 속합니다. 총 클래스
범주는 다음과 같습니다.
클래스의 프로세스 수
클래스에서 한 번에 활성화되는 프로세스 수입니다.
클래스의 스레드 수
클래스에서 한 번에 활성화되는 스레드 수입니다.
클래스의 로그인 수
클래스에서 한 번에 활성화되는 로그인 세션 수입니다.
총 프로세스 범주는 다음과 같습니다.
총 CPU 시간
단일 프로세스에 대해 누적된 총 CPU 시간입니다.
총 디스크 입출력
단일 프로세스에 대해 누적된 총 디스크 입출력의 블록입니다.
총 연결 시간
로그인 세션이 활성화될 수 있는 총 시간입니다.
자원 인타이틀먼트
WLM을 사용하면 시스템 관리자는 각 자원 유형마다 클래스별 자원 인타이틀먼트를 따로 지정할 수 있습니다.
이러한 인타이틀먼트는 다음을 표시하여 지정할 수 있습니다.
• 여러 유형의 자원 사용에 대한 목표. 이 목표는 공유와 함께 지정됩니다. 공유는 여러 클래스들 간의 관계를 고
려한 사용량으로 지정됩니다. 예를 들어, 두 클래스의 공유가 각각 CPU의 1과 3이고 이 두 클래스만 현재 활성
화되어 있으면 CPU 규정에 따라 WLM에 사용되는 목표 백분율은 각각 25%와 75%입니다. 목표 백분율은 티
어에서의 활성 공유 수와 티어에 사용할 수 있는 자원량을 기준으로 각 티어의 클래스에 대해 계산됩니다.
• 최소 및 최대 한계. 이러한 한계는 사용 가능한 총 자원의 백분율로 지정됩니다. WLM은 두 종류의 최대 한계를
지원합니다.
– 소프트 최대값 한계는 자원에 대한 경합이 있을 때 자원을 사용 가능하게 만드는 최대 자원량을 표시합니다.
경합이 없는 경우(즉, 자원이 필요한 다른 사용자가 없는 경우)에는 이 최대 한계가 초과될 수 있습니다.
– 하드 최대값 한계는 자원에 대한 경합의 유무와 관계없이 자원을 사용 가능하게 만드는 최대 자원량을 표시
합니다. 그러나 고정 우선순위 스레드는 이와 같은 규칙의 적용을 받지 않으므로 한계를 초과할 수 있습니다.
• 총계 한계. 총계 한계는 엄격하게 적용됩니다. 프로세스가 총 소비량 한계 중 하나를 초과하면 종료됩니다. 클
래스가 총계 한계 중 하나에 속하는 경우 해당 자원의 다른 인스턴스를 작성하는 조작은 실패합니다.
대부분, 자원 인타이틀먼트가 충족되고 적용되는 데에는 소프트 최대값 한계로 충분합니다. 하드 최대값 한계를
사용하면 자원에 대한 경합이 없는 경우에도 한계가 엄격하게 적용되므로 시스템 자원이 사용되지 않을 수 있습
니다. 이러한 한계가 너무 낮게 설정되면 시스템이나 애플리케이션 성능에 큰 영향을 미칠 수 있으므로 하드 최대
값 한계를 사용할 때는 주의해야 합니다. 총계 한계도 프로세스가 종료되거나 예상대로 작동하지 못할 수 있으므
로 주의해서 사용해야 합니다.
활성 모드에서 WLM은 활성 클래스를 목표에 가깝게 유지합니다. 다양한 한계 값에 대한 제한조건이 거의 없기
때문에 모든 클래스에서 한계의 합계는 100%를 훨씬 초과할 수 있습니다. 이 경우 모든 클래스가 활동 중이면 모
든 클래스가 한계에 도달할 수 없습니다. WLM은 시스템의 비 고정 우선순위 스레드가 속한 클래스가 한계와 목
표를 고려하여 수행하는 방법에 따라 해당 스레드의 스케줄 우선순위를 조정하여 프로세서 소비량을 제한합니
다. 이 방법을 사용하면 매우 짧은 간격(예: 10ms)에서의 프로세서 소비량이 아니라 지정된 시간 동안의 프로세
서 소비량이 평균을 유지합니다.
예를 들어, 클래스 A가 프로세서 최소가 0%이고 프로세서 목표가 60 공유인 유일한 활성 클래스이면 프로세서
의 100%를 사용할 수 있습니다. 프로세서 최소값 제한이 0%이고 프로세서 목표가 40 공유인 클래스 B가 활성
장치 관리 123
화되면 클래스 A 프로세서 사용량은 60%로 점차 감소하고 클래스 B 프로세서 사용량은 0%에서 40%로 증가합
니다. 두 번째의 경우 시스템은 각각 60%와 40% 프로세서 사용량에서 안정화됩니다.
이 예제에서는 클래스 간에 메모리 경합이 없는 것으로 가정합니다. 정상적인 작업 조건에서 프로세서와 메모리
에 대해 설정한 한계는 상호 의존적입니다. 예를 들어, 메모리 사용량에 대한 최대 한계가 작업 세트에 비해 너무
낮으면 클래스는 해당 목표 또는 최소 프로세서 할당에도 도달할 수 없습니다.
제공된 응용프로그램 세트에 대한 클래스 정의와 클래스 한계를 구체화할 수 있도록 WLM은 각 클래스에서 현재
사용 중인 자원의 양을 표시하는 wlmstat 보고 도구를 제공합니다. 그래픽 표시 도구 wlmmon도 시스템 모니터
링을 위해 제공됩니다.
워크로드 관리자 가상 메모리 제한

워크로드 관리자(WLM) 가상 메모리 제한은 클래스 또는 프로세스에 대한 가상 메모리 제한을 설정하여 시스템
관리자에게 과다한 페이징으로 인한 시스템 장애 또는 시스템 성능 저하를 방지하는 수단을 제공합니다.
제한이 초과되면 WLM은 다음 중 하나를 수행하여 조치를 취합니다.
• 제한을 초과한 WLM 클래스 아래의 모든 프로세스 종료
• WLM 클래스 사용량이 제한을 초과한 프로세스만 종료
• 프로세스 제한을 초과한 프로세스 종료
가상 메모리 제한은 사용자 정의 클래스, 사용자 정의 수퍼클래스 아래의 디폴트 서브클래스 및 디폴트 서브클래
스에 지정할 수 있습니다.
사용통계를 위해 WLM은 WLM 총 클래스 또는 프로세스 사용량을 결정할 때 다음만 가상 메모리로 고려합니다.
• 힙
• 로더 초기화 데이터, BSS, 공유 라이브러리, 개인적으로 로드된 세그먼트
• UBLOCK 및 mmap 영역
• 큰 및 고정된 사용자 공간 페이지
시스템 관리자는 클래스 또는 클래스의 각 프로세스에 대한 WLM 가상 메모리 제한을 지정할 수 있습니다. 클래
스 제한이 초과되면 WLM은 vmenforce 클래스 속성이 각각 class 또는 proc로 설정되었는지에 따라 클래스
에 지정된 모든 프로세스를 종료하거나 제한을 초과한 프로세스만 종료할 수 있습니다. 디폴트 작동은 제한을 초
과한 프로세스만 종료하는 것입니다. 프로세스 제한은 프로세스의 가상 메모리 사용이 제한을 초과한 경우 종료
됩니다.
워크로드 관리자에 대한 조작 모드
WLM을 사용하면 자원 소비량을 클래스별 백분율, 클래스별 총계 또는 프로세스별 총계로 제한할 수 있습니다.
WLM을 활성 모드로 실행하면 모든 자원 유형에 대한 제한이 활성화됩니다.
새 프로세스와 기존 프로세스를 분류하고 다양한 클래스의 자원 사용량을 제한 없이 모니터링하는 WLM 모드를
시작할 수도 있습니다. 이 모드를 수동 모드라고 합니다.
수동 모드는 새 시스템에서 WLM을 구성하여 분류와 지정 규칙을 확인하고 WLM이 프로세서와 메모리 할당을 제
한하지 않을 때 여러 클래스에 대한 자원 사용량의 기준선을 설정하는 데 사용할 수 있습니다. 이것은 시스템 관
리자가 비즈니스 목표를 달성하기 위해 중요한 애플리케이션을 우선 시하고 덜 중요한 작업은 제한하도록 자원
공유 및 자원 한계(필요한 경우)를 적용하는 방법을 결정하기 위한 기본 사항을 제공합니다.
제한하려는 자원이 프로세서 시간일 경우 WLM을 프로세서에 대해서는 활성 모드로 실행하고 다른 모든 자원에
대해서는 수동 모드로 실행할 수 있습니다. 이 모드를 cpu 전용 모드라고 합니다. 클래스별 백분율만 제한하고 총
자원 유형은 제한하지 않을 경우 클래스별 총계, 프로세스별 총계 또는 둘 다에 대해 총 자원 사용통계와 제한을
사용할 수 없게 됩니다. 자원 세트 바인딩은 모든 모드에서 사용 불가능하게 할 수 있습니다.
워크로드 관리자의 동적 제어
WLM이 활성화되면 클래스의 속성, 자원 공유 및 제한, 지정 규칙을 포함하여 언제든지 현재 구성의 매개변수를
수정하고 새 클래스를 추가하거나 기존 클래스를 삭제할 수 있습니다.
이러한 작업은 다음과 같은 여러 방식으로 수행할 수 있습니다.
• 현재 활성 구성에 대한 특성 파일 수정(기호 링크 /etc/wlm/current를 가리키는 디렉토리) 및 새 매개변수
를 사용하기 위해 wlmcntrl 명령을 사용하여 WLM 갱신

• 다른 매개변수 세트로 다른 구성 작성 및 새 구성의 매개변수를 로드하도록 WLM을 갱신하여 현재 구성으로 만
듦
• WLM 명령행 인터페이스(mkclass, chclass 및 rmclass 명령)를 사용하여 현재 활성 구성의 일부 매개변
수 수정
• WLM API를 사용하여 애플리케이션에서 현재 활성 구성의 일부 매개변수 수정
구성 세트를 사용하여 하루 중 지정된 시간에 새 구성으로의 자동 전환을 수행할 수 있습니다. 구성 세트를 사용
하여 관리자는 사용할 구성 세트와 각각 활성화되는 시간 범위를 지정할 수 있습니다.
모니터링 도구
WLM 통계를 표시하고 WLM의 조작을 모니터링하려면 다음 WLM 명령을 사용하십시오.
• wlmstat 명령은 텍스트 지향 명령이며 통계를 텍스트(WLM이 관리하는 모든 자원 유형에 대한 클래스별 자원
사용량의 백분율)로 표시합니다.
• wlmmon 명령은 클래스별 자원 사용량과 WLM 규정에 대한 그래픽 보기를 제공합니다.
• wlmperf 명령은 Performance Toolbox로 사용할 수 있는 선택적 도구로, 장기 레코드 및 재생과 같은 추가 기
능을 제공합니다.
워크로드 관리자의 이전 버전과의 호환성

wlmstat 명령의 디폴트 출력에는 수퍼클래스만 나열되며 이전 버전의 출력과 비슷합니다.
# wlmstat
CLASS CPU MEM DKIO
Unclassified 0 0 0
Unmanaged 0 0 0
Default 0 0 0
Shared 0 2 0
System 2 12 0
class1 0 0 0
class2 0 0 0
#
일부 수퍼클래스에 WLM 관리자에 정의된 서브클래스가 있으면 서브클래스가 나열됩니다. 예를 들어 다음과 같

습니다.
# wlmstat
CLASS CPU MEM DKIO
Unclassified 0 0 0
Unmanaged 0 0 0
Default 0 0 0
Shared 0 2 0
System 3 11 7
class1 46 0 0
class1.Default 28 0 0
class1.Shared 0 0 0
class1.sub1 18 0 0
class2 48 0 0
#
출력은 ps 명령을 사용할 때와 같습니다. 서브클래스가 없는 수퍼클래스의 프로세스에 대해 ps 명령은 수퍼클래

스 이름을 프로세스 클래스 이름으로 나열합니다.
클래스별 사용통계
AIX 사용통계 시스템 유틸리티를 사용하여 여러 시스템 자원을 사용자, 그룹 또는 WLM 클래스별로 수집하고 보
고할 수 있습니다.
프로세스 사용통계를 켜면 운영 체제는 프로세스가 종료할 때 사용통계 파일의 프로세스 자원 사용량에 대한 통
계를 기록합니다. 이 사용통계 레코드에는 프로세스가 속한 WLM 클래스의 이름을 나타내는 64비트 숫자 키를
포함합니다.
사용통계 서브시스템은 전체 34자 클래스 이름 대신 64비트 키를 사용하여 공간을 절약합니다(그렇지 않으면 변
경할 때 실제로 사용통계 레코드 크기의 두 배가 됩니다). 프로세스별 데이터를 발췌하기 위해 사용통계 명령이
실행되면 위에서 설명한 루틴을 사용하여 키가 클래스 이름으로 다시 변환됩니다. 이 변환에서는 현재 WLM 구성
파일의 클래스 이름을 사용합니다. 그러므로 프로세스가 종료될 때 사용통계 레코드를 쓴 시간과 사용통계 보고
장치 관리 125
서가 실행된 시간 사이에 클래스가 삭제된 경우 키에 해당되는 클래스 이름을 찾을 수 없으며 클래스가 알 수 없
음으로 표시됩니다.
사용통계 기간 동안 클래스의 자원 사용량에 대한 정확한 레코드를 삭제된 상태로 두려면 다음 중 하나를 수행하
십시오.
• 클래스를 삭제하는 대신, 클래스 이름을 클래스 파일에 보관하고 규칙 파일에서 클래스를 제거하여 프로세스
를 지정할 수 없도록 하십시오. 그러면 사용통계 기간이 끝날 때 사용통계 보고서를 생성한 후 클래스를 삭제할
수 있습니다.
• 클래스가 속한 구성에서 클래스를 삭제하고, 기간 동안의 사용통계 레코드가 생성될 때까지 클래스 이름을 "더
미" 구성(활성화되지 않은 구성)의 클래스 파일에 보관하십시오.
워크로드 관리자 관리
워크로드 관리자(WLM)는 스케줄러와 VMM(virtual memory manager)이 처리할 자원을 할당하는 방법을 시스
템 관리자가 보다 잘 제어할 수 있도록 해줍니다. WLM을 사용하면 다른 작업 클래스들이 서로 방해하는 것을 막
고 다른 사용자 그룹의 요구사항에 따라 자원을 할당할 수 있습니다.
WLM을 사용하여 작업에 대해 다른 서비스 클래스를 작성하고 해당 클래스의 속성을 지정할 수 있습니다. 이러한
속성은 클래스에 할당할 CPU의 최소 및 최대량, 실제 메모리, 디스크 입출력 처리량을 지정합니다. 그런 다음,
WLM은 시스템 관리자가 제공한 클래스 지정 규칙을 사용하여 작업을 클래스에 자동으로 지정합니다. 이러한 지
정 규칙은 프로세스의 속성 세트 값을 기준으로 합니다. 시스템 관리자 또는 특권 사용자도 작업을 클래스에 자동
으로 지정하여 자동 지정을 재정의할 수 있습니다.
WLM은 기본 운영 체제(BOS)의 일부로 기본 운영 체제와 같이 설치되지만 선택적 서비스입니다. WLM은 WLM을
사용할 때 시작되고 WLM 서비스를 일시 중단 또는 종료할 때 시스템 환경에 맞게 구성되어야 합니다.
이 섹션에서는 해당 사이트에 맞는 클래스와 규칙으로 WLM을 구성하는 절차와 예기치 않은 자원 사용 작동 문제
점을 해결하기 위한 제안사항을 설명합니다.
주의: 이 섹션의 태스크에서는 사용자가 WLM 개념에 친숙하다고 가정합니다. WLM을 효율적으로 사용
하려면 기존의 시스템 프로세스와 성능에 대해 자세히 알고 있어야 합니다. 시스템 관리자가 WLM을 정확
하지 않거나 극단적인 값으로 구성하면 성능이 크게 저하됩니다.
워크로드 관리자 시작 및 종료
WLM은 시작하고 정지해야 하는 선택적 서비스입니다.
WLM을 시작하거나 중지하려면 시스템 관리 인터페이스, SMIT 중 하나를 사용하는 것이 권장됩니다.
• SMIT를 사용하여 WLM을 시작하거나 정지하려면 smit wlmmanage 단축 경로를 사용하십시오.
이러한 옵션의 주요한 차이는 성능입니다. SMIT에서 세 가지 방법으로 WLM을 시작하거나 중지할 수 있습니다.
현재 세션
이 옵션을 사용하여 WLM을 정지하도록 요청하면 이 세션에서만 WLM이 정지되고 다음에 재부팅할 때 재시
작됩니다. 이 옵션을 사용하여 시작을 요청하면 이 세션에서만 WLM이 시작되고 다음에 재부팅할 때 재시작
되지 않습니다.
다음 재부팅
이 옵션을 사용하여 WLM을 정지하도록 요청하면 이 세션에서만 WLM이 계속 실행되고 다음에 재부팅할 때
재시작되지 않습니다. 이 옵션을 사용하여 시작을 요청하면 이 세션에서 WLM을 사용할 수 없지만 다음에 재
부팅할 때 시작됩니다.
둘다
이 옵션을 사용하여 WLM을 정지하도록 요청하면 이 세션에서만 WLM이 정지되고 다음에 재부팅할 때 재시
작되지 않습니다. 이 옵션을 사용하여 시작을 요청하면 이 세션에서만 WLM이 시작되고 다음에 재부팅할 때
재시작됩니다.
wlmcntrl 명령을 사용할 수도 있지만 wlmcntrl 명령을 사용하면 현재 세션에서만 WLM을 시작하거나 정지
할 수 있습니다. 명령행 인터페이스를 사용하고 시스템이 재부팅될 때 변경을 적용하려면 /etc/inittab 파일
을 편집해야 합니다.
WLM을 사용하면 자원 소비량을 클래스별 백분율, 클래스별 총계 또는 프로세스별 총계로 제한할 수 있습니다.
WLM을 활성 모드로 실행하면 모든 자원 유형에 대한 제한이 활성화됩니다. 새 프로세스와 기존 프로세스를 분류
하고 다양한 클래스의 자원 사용량을 제한 없이 모니터링하는 WLM 모드를 시작할 수도 있습니다. 이 모드를 수

동 모드라고 합니다. 제한하려는 자원이 CPU 시간일 경우 WLM을 CPU에 대해서는 활성 모드로 실행하고 다른
모든 자원에 대해서는 수동 모드로 실행할 수 있습니다. 이 모드를 cpu 전용 모드라고 합니다.
WLM이 시작되기 전에 시스템에 있는 모든 프로세스는 새로 로드된 지정 규칙에 따라 분류되고 WLM에 의해 모
니터링됩니다.
워크로드 관리자 특성
SMIT, WLM 명령행 인터페이스를 사용하거나 플랫 ASCII 파일을 작성하여 WLM 구성의 특성을 지정할 수 있습
니다. SMIT 인터페이스는 WLM 명령을 사용하여 특성 파일이라는 동일한 플랫 ASCII 파일에 정보를 레코드합니
다.
WLM 특성 파일 세트는 WLM 구성을 정의합니다. 여러 세트의 특성 파일을 작성하여 워크로드 관리에 대한 다른
구성을 정의할 수 있습니다. 이러한 구성은 /etc/wlm의 서브디렉토리에 있습니다. Config 구성의 수퍼클래스
를 설명하는 WLM 특성 파일은 /etc/wlm/Config에서 파일의 , description, limits, shares 및 rules입니다. 이
구성의 수퍼클래스 Super의 서브클래스를 설명하는 특성 파일은 /etc/wlm/Config/Super 디렉토리에 있는
파일의 classes, limits, shares 및 rules입니다. 루트 사용자만 WLM을 시작 또는 중지하고 한 구성에서 다른 구성
으로 전환할 수 있습니다.
특성 파일의 이름은 다음과 같습니다.
항목 설명
클래스 클래스 정의
설명 구성 설명 텍스트
그룹화 속성값 그룹화
한계 클래스 한계
공유 클래스 목표 공유
규칙 클래스 지정 규칙
WLM 특성 파일을 제출하는 명령 wlmcntrl과 기타 WLM 명령을 통해 사용자는 WLM 특성 파일의 대체 디렉토
리 이름을 지정할 수 있습니다. 그러면 디폴트 WLM 특성 파일을 변경하지 않고 WLM 특성을 변경할 수 있습니다.
기호 링크 /etc/wlm/current는 현재 구성 파일이 들어 있는 디렉토리를 가리킵니다. 지정된 구성 또는 구성
세트로 WLM을 시작할 때 wlmcntrl 명령을 사용하여 이 링크를 갱신하십시오. 운영 체제와 함께 제공된 샘플
구성 파일은 /etc/wlm/standard에 있습니다.
속성값 그룹화 작성
속성값을 그룹화하여 rules 파일에 단일 값으로 표시할 수 있습니다. 이러한 속성값 그룹화는 WLM 구성 디렉
토리 내의 groupings 파일에 정의됩니다.
기본적으로 구성에는 groupings 파일이 없습니다. 파일을 작성할 명령 또는 관리 인터페이스가 없습니다. 속
성값 그룹화를 작성하고 사용하려면 다음 절차를 수행하십시오.
1. 루트 권한을 사용하여 다음 예제에 표시된 것처럼 해당 구성 디렉토리로 변경하십시오.
cd /etc/wlm/MyConfig
2. groupings이라는 파일을 작성하고 편집하려면 즐겨찾기 편집기를 사용하십시오.

vi groupings
3. 다음 형식을 사용하여 속성 및 연관된 값을 정의하십시오.
attribute = value, value, ...
모든 값은 쉼표로 구분해야 합니다. 공백은 중요하지 않습니다. 범위와 와일드카드는 허용됩니다. 예를 들어

다음과 같습니다.
trusted = user[0-9][0-9], admin*
nottrusted = user23, user45
장치 관리 127
shell = /bin/?sh, \
/bin/sh, \
/bin/tcsh
rootgroup=system,bin,sys,security,cron,audit
4. 파일을 저장하십시오.
5. 클래스의 선택 기준 내에서 속성 그룹화를 사용하려면 rules 파일을 편집하십시오.
속성 그룹화 이름 앞에는 해당 값을 포함하는 달러 부호($) 또는 값을 제외하는 느낌표(!)가 와야 합니다. 느낌
표는 그룹의 멤버에 사용할 수 없으며(127 페이지의 『3』 단계) 이 규칙 파일의 그룹화 앞에 유일하게 사용
할 수 있는 수정자입니다. 다음 예제에서 별표(*)는 주석 행을 표시합니다.
*class resvd user group application type tag
classA - $trusted,!$nottrusted - - - -
classB - - - $shell,!/bin/zsh - -
classC - - $rootgroup - - -
6. 파일을 저장하십시오.
이제, 분류 규칙에 속성값 그룹화가 포함됩니다. 규칙이 구문 분석될 때 해당 요소가 $로 시작되면 시스템은
groupings 파일 내에서 해당 요소를 찾습니다. 요소가 구문상 유효하지 않거나 groupings 파일이 없으면 시
스템은 경고 메시지를 표시하고 다른 규칙을 계속 처리합니다.
시간 기반 구성 세트 작성
특수 구성 세트를 작성하여 특정 구성을 적용할 때 세트 내의 각 구성을 날짜와 시간으로 설정할 수 있습니다.
시간 기반 구성 세트라고 하는 이러한 세트는 정상적인 구성과 완전히 별개이지만 호환 가능합니다. 필요에 따라
wlmcntrl 명령을 사용하여 -u 구성 세트와 정상적인 구성 사이를 전환할 수 있습니다.
구성 세트를 사용할 때 이름이 붙여진 기존 구성을 특정 시간 범위와 연관시키십시오. 지정된 시간에 하나의 구성
만 사용할 수 있기 때문에 지정된 각 시간 범위는 고유해야 합니다. 시간 범위는 중첩되거나 중복될 수 없습니다.
wlmd 디먼은 지정된 구성이 시간 범위를 벗어나고 다른 구성을 사용해야 될 경우 WLM에 경고합니다. 루트 사용
자만 구성 세트의 디렉토리 내에 .times이라고 하는 ASCII 파일에 지정된 시간 범위를 관리할 수 있습니다.
시간 기반 구성 세트를 작성하려면 다음 절차를 사용하십시오.
1. 루트 권한을 사용하여 구성 세트 디렉토리를 작성한 후 해당 디렉토리로 변경하십시오.
mkdir /etc/wlm/MyConfigSet
cd /etc/wlm/MyConfigSet
2. 즐겨찾기 편집기를 사용하여 구성 세트의 .times 파일을 작성하고 구성과 시간 범위를 다음 형식으로 지정
하십시오.
ConfigurationName:
time = "N-N,HH:MM-HH:MM"
또는
ConfigurationName:
time = -
(no time value specified)

여기서 N은 0(일요일) - 6(토요일)의 요일을 표시하는 숫자이고 HH는 00(자정) - 23(11 p.m.)의 시간을 표시
하며 MM은 00 - 59의 분을 표시합니다. 요일만 지정하거나 전부 지정하지 않을 수 있습니다. 24시간 값은 분
값이 00인 경우 하루의 끝 시간에 유효합니다. 특정 구성에 시간 범위 대신 대시(-)를 입력하면 해당 구성은 다
른 구성의 시간 범위가 적용되지 않은 경우에 사용됩니다. 시간 범위 없이 하나의 구성만 지정할 수 있습니다.
conf1:
time =
conf2:
time = "1-5,8:00-17:00"
conf2
time = "6-0,14:00-17:00"

conf3
time = "22:00-6:00"
3. WLM을 새 구성 세트로 갱신하려면 wlmcntrl -u 명령을 사용하십시오.

wlmcntrl -u /etc/wlm/MyConfigSet
이제, WLM의 현재 구성은 새 시간 기반 구성 세트입니다.

confsetcntrl 및 lswlmconf 명령을 사용하여 구성 세트를 작성하고 조작할 수도 있습니다. 예를 들어 다음과 같
습니다.
confset1 구성 세트를 디폴트 구성 conf1로 작성하려면 다음 명령을 사용하십시오.
confsetcntrl -C confset1 conf1
conf2를 confset1에 추가하여 매일 8:00 AM에서 5:00 PM까지 활성 구성으로 만들려면 다음 명령을 사용하
십시오.
confsetcntrl -d confset1 -a conf2 "0-6,08:00-17:00"
이 구성 세트를 활성 구성으로 만들려면 다음 명령을 사용하십시오.

wlmcntrl -d confset1
자원 세트 작성
자원 세트(rset)를 사용하는 것은 CPU가 관련되는 한 워크로드를 서로 격리하는 효과적인 방법입니다. 두 워크로
드를 두 클래스로 분리하고 각 클래스에 CPU의 다른 서브세트를 제공하여 두 워크로드가 실제 메모리와 입출력
대역폭에 대해 경합하는 경우에도 두 워크로드가 CPU 자원에 대해 서로 경합하지 않도록 할 수 있습니다.
자원 세트를 작성하는 가장 간단한 방법은 SMIT 인터페이스(smit addrsetcntl 단축 경로) 또는 mkrset 명
령을 사용하는 것입니다.
다음 예제에서는 4웨이 시스템에 설정된 자원을 작성하고 이름을 지정하는 각 단계를 설명합니다. 예제의 목적
은 프로세서 0 - 2가 포함된 자원 세트를 작성하고 WLM 구성에서 사용하여 수퍼클래스의 모든 프로세스를 이러
한 세 프로세서로 제한하는 것입니다.
1. 루트 권한을 사용하여 다음 명령으로 자원 세트 작성에 사용할 수 있는 기본 원칙을 확인하십시오.
lsrset -av
이 예제에 대한 출력은 다음과 같습니다.

T Name Owner Group Mode CPU Memory Resources
r sys/sys0 root system r----- 4 98298 sys/sys0
r sys/node.00000 root system r----- 4 98298 sys/sys0
r sys/mem.00000 root system r----- 0 98298 sys/mem.00000
r sys/cpu.00003 root system r----- 1 0 sys/cpu.00003
출력에서 sys/sys0은 전체 시스템(이 경우는 4웨이 SMP)을 표시합니다. WLM 클래스가 rset 속성을 지정
하지 않으면 해당 프로세스가 액세스할 수 있는 디폴트 세트가 됩니다.
2. 다음 SMIT 단축 경로를 사용하여 자원 세트를 작성하고 이름을 지정하십시오.
smit addrsetcntl
이 예제의 경우 다음과 같이 필드를 채우십시오.

이름 공간
admin
자원 세트 이름
proc0_2
장치 관리 129
자원
리스트에서 메모리에 해당하는 행과 CPU 0 - 2(sys/cpu.00000 - sys.cpu.00002)를 선택하십시오.
기타 모든 필드
리스트에서 선택하십시오.
필드에 입력하고 SMIT를 종료하면 admin/proc0_2 rset이 /etc/rsets에 작성됩니다.
3. 새 rset을 사용하려면 다음 SMIT 단축 경로를 사용하여 커널 데이터 구조에 추가하십시오.
smit reloadrsetcntl
이 메뉴는 now, at next boot 또는 both 데이터베이스를 다시 로드하는 옵션을 제공합니다. 새 자원 세트

를 처음 사용하는 경우이므로 이 rset이 지금과 재부팅된 후에 로드되도록 both를 선택하십시오. (기존 rset
을 변경한 경우에는 now를 선택합니다.)
4. 다음 SMIT 단축 경로를 사용하여 새 rset을 WLM 클래스에 추가하십시오.
smit wlmclass_gal
클래스(이 예제에서는 super1)를 선택한 후 자원 세트 필드의 사용 가능한 리스트에서 admin/proc0_2를 선

택하십시오. 선택한 후 SMIT를 종료하면 디스크의 classes 파일이 변경됩니다.
5. 다음 중 하나를 수행하십시오.
• WLM이 실행 중이면 다음 SMIT 단축 경로를 사용하여 구성을 갱신하십시오.
smit wlmupdate
• WLM이 실행 중이 아니면 다음 SMIT 단축 경로를 사용하여 시작하십시오.

smit wlmstart
6. 새 자원 세트가 클래스에 미치는 영향을 모니터링하십시오. 예를 들어 다음과 같습니다.

a) super1 클래스에서 90 CPU 루프(무한 루프를 실행하는 프로그램)를 시작하십시오.
b) 명령행에 wlmstat를 입력하십시오. 이 예제에 대한 출력은 다음과 같습니다.
CLASS CPU MEM BIO

Unclassified 0 0 0
Unmanaged 0 0 0
Default 8 0 0
Shared 0 0 0
System 0 0 0
super1 75 0 0
super2 0 0 0
super2.Default 0 0 0
super2.Shared 0 0 0
super2.sub1 0 0 0
super2.sub2 0 0 0
이 출력은 제한이 없는 경우 CPU의 100%를 사용하는 90 CPU 바운드 프로세스가 CPU 0 - 2에서 실행되
도록 자원 세트에 의해 제한되기 때문에 현재 75%만 사용하고 있음을 보여줍니다.
c) 프로세스(PID로 식별)가 액세스할 자원 세트를 확인하려면 다음 SMIT 단축 경로를 사용하십시오.
smit lsrsetproc
해당되는 프로세스의 PID를 입력하거나 리스트에서 선택하십시오. 다음 출력은 루프 프로세스 중 하나에

대한 것입니다.
CPU Memory Resources

3 98298 sys/mem.00000 sys/cpu.00002 sys/cpu.00001 sys/cpu.00000
그러나, 지정된 rset 속성이 없는 클래스의 프로세스는 독점 자원 세트의 일부인 프로세서를 제외한 모든
프로세서를 포함하는 Default 자원 세트를 사용합니다. 클래스에 속하지 않는 프로세스는 System 클래
스(루트 프로세스인 경우) 또는 Default 클래스(비루트 프로세스인 경우)를 사용합니다. 이러한 각 클래
스에는 정의된 자원 세트가 있을 수도 있습니다.

다음은 자원 세트를 지정하지 않은 클래스에 있는 init 프로세스의 출력입니다.
CPU Memory Resources

4 98298 sys/sys0
현재 자원 세트가 존재하며 최소한 WLM 내의 한 클래스에서 사용하고 있습니다.

참고: WLM은 현재 bindprocessor 서브루틴 바인딩이 있는 프로세스의 rset 접속 또는 다른 rset 접속을 설정
하지 않습니다. 더 이상 다른 접속이 없으면 WLM은 자동으로 rset을 지정합니다.
참고: 자원 세트는 Default 및 System 클래스를 포함하는 WLM 클래스에 대해 작성될 수 있습니다.
워크로드를 통합하도록 워크로드 관리자 구성

워크로드 관리자(WLM)를 사용하면 시스템 작업에 사용되는 자원을 제어할 수 있습니다.
디폴트 WLM 구성 템플리트는 설치된 AIX 운영 체제마다 있습니다. 다음 프로시저에서는 WLM 구성 템플리트를
갱신하여 공유 서버에서 자원 관리 정책을 구현합니다. 최종 구성은 테스팅의 시작점으로 사용될 수 있습니다.
WLM을 구성하는 구체적인 방법은 사용자 환경의 워크로드 및 정책 요구사항에 따라 달라집니다.
참고:
1. WLM을 효율적으로 사용하려면 기존의 시스템 프로세스와 성능에 대해 자세히 알고 있어야 합니다. 사용자
환경의 워크로드에 적합한 구성을 개발할 때까지 테스트와 성능 조정을 반복해서 수행해야 할 수도 있습니다.
너무 높거나 낮은 값 또는 정확하지 않은 값으로 WLM을 구성할 경우 시스템 성능이 눈에 띄게 저하될 수 있습
니다.
2. 프로세스의 분류 속성(예: 사용자, 그룹 또는 응용프로그램 이름) 중 하나를 이미 알고 있으면 WLM을 훨씬 간
단하게 구성할 수 있습니다. 현재 자원 사용에 대해 잘 모를 경우, topas와 같은 도구를 사용하여 1차 자원 사
용자인 프로세스를 식별한 후 해당 정보를 기준으로 클래스와 규칙을 정의하십시오.
3. 다음 시나리오에서는 120 페이지의 『워크로드 관리 개념 』에 설명된 워크로드 관리자의 기본 개념에 대해
사용자가 잘 알고 있다고 가정합니다.
WLM 구성 파일은 /etc/wlm/ConfigurationName 디렉토리에 있습니다. 각 수퍼클래스에 대한 각 서브클래스
는 /etc/wlm/ConfigurationName/SuperClassName이라는 구성 파일에 정의되어 있습니다. 이들 파일에 대한
자세한 정보는 파일 참조서의 내용을 참조하십시오.
다음 절차에서는 두 개의 서로 다른 부서 서버에 있는 워크로드를 더 큰 하나의 서버에 통합합니다. 이 예는 구성
파일을 편집하지만 SMIT(smit wlmconfig_create 단축 경로 사용)를 사용하여 구성을 작성할 수도 있습니
다. 간략하게 이 프로시저에서는 다음을 수행합니다.
1. 통합하려는 애플리케이션의 자원 요구사항을 식별합니다. 그러면 더 큰 서버로 이동할 수 있는 애플리케이션
의 수를 결정할 수 있습니다.
2. 티어와 자원 공유 및 한계를 정의하여, 통합된 워크로드로 테스트를 시작하십시오.
3. 원하는 결과를 얻을 때까지 구성을 미세 조정하십시오.
1단계. 애플리케이션 요구사항 식별

이 시나리오에서는 워크로드는 데이터베이스 서버에서 볼 수 있는 일반적인 것입니다. 작업이 다음 일반적인 카
테고리로 나뉜다고 가정하십시오.
리스너
이는 대부분의 시간 동안 작동하지 않다가 요청에 의해 응답하는 프로세스입니다. 이러한 프로세스는 많은
양의 자원을 사용하지는 않지만 응답 시간은 매우 중요합니다.
작업자
이는 요청이 로컬이건, 원격이건 관계 없이 요청대신 작동하는 프로세스입니다. 이러한 프로세스는 많은 양
의 CPU 시간과 메모리를 사용합니다.
보고서
이는 자동화된 태스크를 수행하는 프로세스입니다. 이러한 프로세스는 실행하는 데 많은 양의 CPU 시간이나
메모리가 필요할 수도 있지만 응답 시간이 느려도 문제가 되지 않습니다.
장치 관리 131
모니터
이는 시스템이나 애플리케이션의 상태를 검증하기 위해 보통 주기적으로 실행되는 프로세스입니다. 이러한
프로세스는 많은 양의 자원을 사용할 수 있지만 사용하는 시간이 짧습니다.
명령
이는 시스템 사용자가 언제든지 실행할 수 있는 명령이나 기타 애플리케이션입니다. 이러한 프로세스의 자원
요구량은 예측할 수 없습니다.
이와 같은 작업 외에도 계획된 작업이 다음 카테고리 중 하나에 해당합니다.
SysTools
이는 자동화된 태스크를 수행하는 프로세스입니다. 이 작업은 시스템 조작에 중요하지 않지만, 주기적으로
특정 시간 제한 하에서 실행되어야 합니다.
SysBatch
이는 가끔 실행되고 시스템 조작에 중요하지 않으며 시기적절하게 종료될 필요가 없는 프로세스입니다.
구성을 작성하는 첫 번째 단계는 클래스와 규칙을 정의하는 것입니다. 다음 단계에서는 위에 나열된 일반적인 작
업 카테고리를 사용하여 클래스를 정의합니다. 다음 프로시저를 사용하십시오.
1. 다음 명령을 사용하여 /etc/wlm 디렉토리에 MyConfig라는 새 구성을 작성하십시오.
mkdir /etc/wlm/MyConfig
2. 다음 명령을 사용하여 /etc/wlm/MyConfig 디렉토리에 템플리트 파일을 복사하십시오.
cp -pr /etc/wlm/template/* /etc/wlm/MyConfig
3. 수퍼클래스를 작성하려면, 즐겨찾기 편집기를 사용하여 /etc/wlm/MyConfig/classes 파일이 다음을

포함하도록 수정하십시오.
System:
Default:
DeptA:
DeptB:
SysTools:
SysBatch:
먼저, 각 부서에 대해 수퍼클래스를 하나씩 정의하십시오. 이는 두 부서가 서버를 공유하기 때문입니다.

SysTool 및 SysBatch 수퍼 클래스는 위의 일반 카테고리에 아웃라인된 계획된 작업을 처리합니다. 시스템 및
디폴트 수퍼클래스는 항상 정의됩니다.
4. MyConfig 디렉토리 내에서 각 DeptA 및 DeptB 수퍼클래스를 위한 디렉토리를 작성하십시오. (구성을 작성
할 때에는 서브클래스가 있는 모든 수퍼클래스에 대해 디렉토리를 작성해야 합니다.) 다음 단계에서는 각 부
서의 수퍼클래스에 대해 5개(각 작업 카테고리에 대해 하나씩)의 서브클래스를 정의합니다.
5. 각각의 일반 작업 카테고리에 대해 서브클래스를 작성하려면 다음 내용이 포함되도록 /etc/wlm/
MyConfig/DeptA/classes와 /etc/wlm/MyConfig/DeptB/classes 파일을 편집하십시오.
Listen:
Work:
Monitor:
Report:
Command:
참고: classes 파일의 컨텐츠는 각 수퍼클래스마다 다를 수 있습니다.

클래스를 식별한 후, 다음 단계에서는 수퍼클래스와 서브클래스 레벨에서 프로세스를 분류하는 데 사용되는
분류 규칙을 작성합니다. 작업을 간단하게 만들기 위해, 모든 애플리케이션이 알려진 위치에서 실행된다고 가

정합니다. 또한 한 부서의 프로세스는 모두 deptA UNIX 그룹에서 실행되고 다른 부서의 프로세스는 deptB
UNIX 그룹에서 실행된다고 가정합니다.
6. 수퍼클래스 지정 규칙을 작성하려면 다음 내용이 포함되도록 /etc/wlm/MyConfig/rules 파일을 수정하
십시오.
DeptA - - deptA - -
DeptB - - deptB - -
SysTools - root,bin - /usr/sbin/tools/* -
SysBatch - root,bin - /usr/sbin/batch/* -
System - root - - -
Default - - - - -
참고: 같은 애플리케이션의 두 개 이상의 인스턴스가 실행 중일 수 있고, 모든 분류 속성(태그가 아닌)이 같으

면, wlmassign 명령이나 wlm_set_tag 서브루틴으로 다른 클래스에 지정하여 인스턴스를 구별하십시오.
7. 보다 구체적인 서브클래스 규칙을 작성하려면 다음 내용으로 /etc/wlm/MyConfig/DeptA/rules
와 /etc/wlm/MyConfig/DeptB/rules 파일을 작성하십시오.
Listen - - - /opt/myapp/bin/listen* -
Work - - - /opt/myapp/bin/work* -
Monitor - - - /opt/bin/myapp/bin/monitor -
Report - - - /opt/bin/myapp/report* -
Command - - - /opt/commands/* -
8. 각 클래스의 자원 사용 동작을 결정하려면 다음 명령을 사용하여 수동 모드로 WLM을 시작하십시오.

wlmcntrl -p -d MyConfig
WLM을 수동 모드로 시작한 후, 자원 요구사항의 더 상세한 면을 얻기 위해 처음에는 각 애플리케이션을 별도

로 실행할 수 있습니다. 그런 다음 모든 애플리케이션을 동시에 실행하여 모든 클래스 간의 상호작용을 볼 수
있습니다.
애플리케이션 자원 요구사항을 식별하는 대체 방법은 애플리케이션을 통합하고 있는 분리된 서버들에서 처음에
WLM을 수동 모드로 실행하는 것입니다. 이 방법을 사용할 때의 단점은 더 큰 시스템에서 구성을 다시 작성해야
하고, 더 큰 시스템에서는 필요한 자원의 백분율이 다를 수도 있다는 점입니다.
2단계. 티어, 공유 및 한계 정의
WLM 구성은 자원 관리 정책을 이행하는 것입니다. 수동 모드로 WLM을 실행하면 사용자의 자원 관리 정책이 주
어진 워크로드에 적합한지를 결정하는 데 도움이 되는 정보를 제공합니다. 이제 자원 관리 정책을 기준으로 워크
로드를 제어할 티어, 공유 및 한계를 정의할 수 있습니다.
이 시나리오에서는 사용자의 요구사항이 다음과 같다고 가정합니다.
• 시스템 클래스의 우선순위가 가장 높아야 하고 항상 일정량의 시스템 자원에 액세스할 수 있어야 합니다.
• SysTools 클래스가 항상 특정 백분율의 자원에 대한 액세스를 가지고 있어야 하나, DeptA와 DeptB에서 실행
중인 애플리케이션에 영향을 미칠 정도는 아니어야 합니다.
• SysBatch 클래스는 시스템의 다른 작업을 방해할 수 없습니다.
• DeptA가 사용 가능한 자원(공유를 통해 클래스에서 사용할 수 있는 자원)의 60%를 받고 DeptB가 40%를 받
습니다. DeptA와 DeptB 내에서는 다음과 같습니다.
– Listen 클래스의 프로세스가 짧은 대기 시간으로 요청에 응답해야 하지만 많은 양의 자원을 사용해서는 안
됩니다.
– Work 클래스가 대부분의 자원을 사용할 수 있어야 합니다. Monitor와 Command 클래스가 일정량의 자원을
사용해야 하지만 Work 클래스가 사용하는 것보다는 적어야 합니다.
– Report 클래스는 다른 어떤 작업도 간섭할 수 없습니다.
다음 프로시저에서 티어, 공유, 한계를 정의합니다.
1. 수퍼클래스 티어를 작성하려면 편집기에서 다음 내용이 포함되도록 /etc/wlm/MyConfig/classes 파일
을 수정하십시오.
System:
장치 관리 133
Default:
DeptA:
localshm = yes
adminuser = adminA
authuser = adminA
inheritance = yes
DeptB:
localshm = yes
adminuser = adminB
authuser = adminB
inheritance = yes
SysTools:
localshm = yes
SysBatch:
tier = 1
localshm = yes
SysBatch 수퍼클래스는 티어 1에 배치됩니다. 이는 SysBatch 수퍼클래스에 시스템의 다른 작업을 간섭하지

않아야 할 우선순위가 매우 낮은 작업이 포함되기 때문입니다. 티어가 지정되지 않으면 디폴트로 티어 0에 클
래스가 배치됩니다. 각 부서의 수퍼클래스에 대한 관리는 adminuser 및 authuser 속성으로 정의합니다.
inheritance 속성이 DeptA와 DeptB에 대해 사용 가능합니다. 상속이 있는 클래스에서 시작된 모든 새 프로세
스는 해당 클래스로 분류됩니다.
2. 각각의 작업 그룹에 대해 서브클래스 티어를 작성하려면 다음 내용이 포함되도록 /etc/wlm/MyConfig/
DeptA/classes와 /etc/wlm/MyConfig/DeptB/classes 파일을 수정하십시오.
Listen:
Work:
Monitor:
Report:
tier = 1
Command:
3. 수퍼클래스에 초기 공유를 지정하려면 다음 내용이 포함되도록 /etc/wlm/MyConfig/shares 파일을 편

집하십시오.
DeptA:
CPU = 3
memory = 3
DeptB:
CPU = 2
memory = 2
총 5개의 공유가 있는 CPU를 지정했으므로, DeptA 프로세스는 총 CPU 자원인 5개의 공유 중 3개(60%)에 액
세스하게 되고 DeptB 프로세스는 5개 중 2개(40%)에 액세스하게 됩니다. SysTools, System, Default 클래
스에 공유를 지정하지 않았기 때문에, 소모 목표는 활성 공유 수와는 독립적으로 남아, 자원에 DeptA와
DeptB보다 높은 우선순위 액세스를 줍니다(한계에 도달할 때까지). SysBatch 클래스는 티어 1의 유일한 수
퍼클래스이기 때문에 어떠한 공유도 지정하지 않았으므로, 모든 공유 지정이 의미가 없습니다. SysBatch 클
래스의 작업만 티어 0의 모든 클래스가 사용하지 않은 자원을 사용할 수 있습니다.
4. 서브클래스에 초기 공유를 지정하려면 다음 내용이 포함되도록 /etc/wlm/MyConfig/DeptA/shares
와 /etc/wlm/MyConfig/DeptB/shares 파일을 편집하십시오.
Work:
CPU = 5
memory = 5
Monitor:
CPU = 4
memory = 1
Command:
CPU = 1
memory = 1

Listen 클래스에는 공유를 지정하지 않았으므로 자원이 필요할 때는 다른 어떤 클래스보다 먼저 수퍼클래스
의 자원에 액세스할 수 있습니다. Work 클래스의 자원 요구량이 가장 많으므로 여기에 가장 많은 수의 공유를
지정했습니다. Monitor와 Command 클래스에 이들 클래스에서 관찰된 작동 및 관련 중요성을 기준으로 공유
를 지정했습니다. Report 클래스에는 공유를 지정하지 않았습니다. Report 클래스는 티어 1의 유일한 서브클
래스이므로 공유를 지정하는 것이 의미가 없기 때문입니다. Report 클래스의 작업만 티어 0의 서브클래스가
사용하지 않은 자원을 사용할 수 있습니다.
이 예제의 다음 단계에서는 공유를 지정받지 않은 클래스에 한계를 지정합니다. 공유가 있는 클래스에 한계를
지정할 수도 있습니다. 자세한 정보는 WLM을 사용하여 자원 관리를 참조하십시오.
5. 수퍼클래스에 한계를 지정하려면 다음 내용이 포함되도록 /etc/wlm/MyConfig/limits 파일을 편집하
십시오.
Default:
CPU = 0%-10%;100%
memory = 0%-10%;100%
SysTools:
CPU = 0%-10%;100%
memory = 0%-5%;100%
System:
CPU = 5%-50%;100%
memory = 5%-50%;100%
System, SysTools, Default 클래스가 시스템의 다른 작업을 방해하지 않도록 소프트 한계를 지정했습니다.
System 클래스에는 CPU 및 메모리에 대한 최소 한계를 지정했습니다. System 클래스에는 시스템 운영에 반
드시 필요한 프로세스가 포함되어 있어서 일정량의 자원을 사용할 수 있어야 하기 때문입니다.
6. 서브클래스에 한계를 지정하려면 다음 내용이 포함되도록 /etc/wlm/MyConfig/DeptA/limits
와 /etc/wlm/MyConfig/DeptB/limits 파일을 편집하십시오.
Listen:
CPU = 10%-30%;100%
memory = 10%-20%;100%
Monitor:
CPU = 0%-30%;100%
memory = 0%-30%;100%
참고: 한계는 각 서브클래스 파일마다 다를 수 있습니다.

Litemn과 Monitor 클래스가 같은 수퍼클래스에 있는 다른 서브클래스를 방해하지 않도록 소프트 한계를 지
정했습니다. 특히, Work 클래스에서 자원에 액세스할 수 없어 이 클래스의 작업을 처리할 수 없을 경우, 시스
템에서 Work 클래스의 작업에 대한 요청은 더 이상 승인하지 않도록 만들려고 합니다. 빠른 응답 시간을 보장
하기 위해 Listen 클래스에도 최소 한계를 지정했습니다. 메모리 최소 한계는 이 클래스에 사용된 페이지가 페
이지 대체를 통해 다른 프로세스에 의해 스틸(steal)되지 않도록 함으로써 실행 시간을 단축시킵니다. CPU 최
소 한계는 이러한 프로세스가 실행될 수 있을 때 CPU 자원에 대해 가장 높은 우선순위(수퍼클래스 내에서)로
액세스할 수 있게 해 줍니다.
3단계. 워크로드 관리자 구성 조정

1. wlmstat 명령을 사용하여 시스템을 모니터하십시오. 또한 WLM에 의해 수행된 제어가 사용자의 목표에 부
합하는지와 일부 애플리케이션에서는 필요한 것보다 많은 자원을 사용하는 반면 자원이 꼭 필요한 다른 애플
리케이션에서는 자원을 사용하지 못하고 있지는 않은지를 확인하십시오. 이와 같은 경우에는 공유를 조정하
고 WLM을 갱신하십시오.
2. 공유, 한계 및 티어 수를 모니터링하고 조정할 때 수퍼클래스의 일부 또는 전부에 대한 서브클래스의 관리를
위임할 것인지 여부를 결정하십시오. 그러면 관리자가 서브클래스 공유, 한계 및 티어 번호를 모니터하고 설
정할 수 있습니다.
각 수퍼클래스의 관리자가 각 수퍼클래스의 서브클래스에 대해 이 프로세스를 반복할 수 있습니다. 서브클래스
레벨에서는 수동 모드로 WLM을 실행할 수 없다는 점만 다릅니다. 서브클래스 구성 및 조정 작업은 WLM을 활성
모드로 실행하여 수행해야 합니다. 수퍼클래스의 사용자와 애플리케이션에 영향을 주지 않으려면 서브클래스의
티어 번호, 공유 및 한계를 디폴트 값(공유는 '-'(하이픈), 최소는 0%, 소프트 및 하드 최대는 100%)에서 시작하
면 됩니다. 이렇게 설정하면 WLM이 서브클래스 간의 자원 할당을 제어하지 않습니다.
장치 관리 135
자세한 정보
• 워크로드 관리자.
• 워크로드 관리.
• 워크로드 관리 진단 in 성능 관리.
• 파일 참조서의 classes, limits, rules 및 shares 파일에 대한 설명
• topas, wlmassign, wlmcheck, wlmcntrl 및 wlmstat.
• WLM 서브루틴(특히, wlm_set_tag)에 대한 설명
클래스
워크로드 관리자는 서비스의 클래스를 정의하고 이러한 각 클래스에 자원을 할당하여 시스템 자원의 할당을 제
어하도록 도와줍니다.
각 클래스에는 자원 인타이틀먼트를 결정하는 속성 세트와 기타 작동이 있습니다. 시스템의 모든 프로세스는 서
비스 클래스로 분류되므로 해당 클래스에 대한 자원 인타이틀먼트와 동작이 적용됩니다. 프로세스는 수동 지정
을 사용하여 수동으로 클래스에 지정되거나 사용자 정의 클래스 규칙에 따라 자동으로 지정됩니다.
WLM은 두 레벨의 클래스, 즉 수퍼클래스와 서브클래스를 지원합니다. 수퍼클래스는 사용 가능한 시스템 자원을
기반으로 자원 인타이틀먼트를 받고, 서브클래스는 연관된 수퍼클래스의 인타이틀먼트와 관련된 자원 인타이틀
먼트를 받습니다. 수퍼클래스의 프로세스를 더 잘 제어할 수 있도록 서브클래스를 정의할 수도 있습니다. 수퍼클
래스에 관리 사용자 또는 관리 그룹을 지정하여 서브클래스를 정의하는 책임을 위임할 수도 있습니다.
수퍼클래스와 서브클래스 레벨 둘 모두의 경우, 클래스, 자원 공유 및 한계 및 SMIT를 사용하는 규칙 또는 명령행
인터페이스를 정의할 수 있습니다. 애플리케이션은 WLM API를 사용할 수 있습니다. 구성 정의는 WLM 특성 파
일이라고 하는 텍스트 파일 세트에 보관됩니다.
클래스 이름은 최대 16자이며 대문자, 소문자, 숫자 및 밑줄 문자(_)를 사용할 수 있습니다. 지정된 WLM 구성에
서 각 수퍼클래스 이름은 고유해야 합니다. 각 서브클래스 이름은 해당 수퍼클래스 내에서 고유해야 하지만 다른
수퍼클래스에서의 서브클래스 이름과 일치할 수 있습니다. 모든 서브클래스를 고유하게 식별하기 위해 서브클래
스의 전체 이름은 점으로 구분되는 수퍼클래스 이름과 서브클래스 이름으로 구성됩니다(예: Super.Sub).
수퍼클래스
시스템 관리자는 최대 64개의 수퍼클래스를 정의할 수 있습니다.
또한 다음의 5개의 수퍼클래스가 자동으로 작성됩니다.
Default 수퍼클래스
디폴트 수퍼클래스이며 항상 정의됩니다. 특정 수퍼클래스에 자동으로 지정되지 않은 루트가 아닌 프로세스
가 모두 Default 수퍼클래스에 지정됩니다. 특정 지정 규칙을 제공하여 다른 프로세스를 Default 수퍼클래스
에 지정할 수도 있습니다.
System 수퍼클래스
해당 프로세스가 규칙에 의해 특정 클래스에 지정되지 않은 경우 모든 특권(루트) 프로세스가 특정 클래스에
지정됩니다. 이 수퍼클래스는 커널 메모리 세그먼트와 커널 프로세스에 속한 메모리 페이지를 수집합니다.
이 수퍼클래스에 대한 특정 지정 규칙을 제공하여 다른 프로세스를 System 수퍼클래스에 지정할 수도 있습
니다. 이 수퍼클래스의 최소 메모리 제한은 1%로 디폴트 값입니다.
Shared 수퍼클래스
수퍼클래스의 두 개 이상의 프로세스에 사용되는 메모리 페이지를 수신합니다. 여기에는 공유 메모리 영역의
페이지 및 두 개 이상의 서브클래스(또는 같은 수퍼클래스의 서브클래스)에 있는 프로세스에 사용되는 파일
의 페이지가 포함됩니다. 모두 단일 수퍼클래스(또는 같은 수퍼클래스의 서브클래스)에 속하는 여러 프로세
스에 사용되는 공유 메모리와 파일은 해당 수퍼클래스와 연관됩니다. 다른 수퍼클래스의 프로세스가 공유 메
모리 영역 또는 파일에 액세스할 때만 페이지가 Shared 수퍼클래스에 포함됩니다. 이 수퍼클래스는 수퍼클
래스에 적용된 실제 메모리 공유와 제한만 포함할 수 있습니다. 지정된 다른 자원 유형, 서브클래스 또는 지정
규칙에 대한 공유나 제한은 포함할 수 없습니다. 같은 수퍼클래스의 다른 서브클래스에 있는 프로세스가 공
유하는 메모리 세그먼트가 Shared 서브클래스로 분류되는지 원래 서브클래스에 그대로 있는지는 원래 서브
클래스의 localshm 속성의 값에 따라 다릅니다.
Unclassified 수퍼클래스
분류되지 않은 프로세스에 대한 메모리 할당입니다. WLM이 시작될 때 존재하는 프로세스는 로드 중인 WLM
구성의 지정 규칙에 따라 분류됩니다. 이 초기 분류 중에 각 프로세스에 접속된 모든 메모리 페이지는 같은 수

퍼클래스의 프로세스가 공유하지 않거나 공유할 경우 프로세스가 속한 수퍼클래스에 지정되거나 다른 수퍼
클래스의 프로세스가 공유할 경우 Shared 수퍼클래스에 지정됩니다.
그러나 분류 시 여러 페이지를 모든 프로세스(및 모든 클래스)에 직접 결합할 수 없으며 이 메모리는
Unclassified 수퍼클래스에 지정됩니다. 이 메모리의 대부분은 시간이 지나면, 즉 프로세스가 액세스하거나
WLM이 시작된 후 해제되어 프로세스에 재할당될 때 올바르게 재분류됩니다. Unclassified 수퍼클래스에는
프로세스가 없습니다. 이 수퍼클래스는 수퍼클래스에 적용된 실제 메모리 공유와 제한을 포함할 수 있습니
다. 지정된 다른 자원 유형, 서브클래스 또는 지정 규칙에 대한 공유나 제한은 포함할 수 없습니다.
Unmanaged 수퍼클래스
Unmanaged라는 특수 수퍼클래스는 항상 정의됩니다. 이 클래스에는 어떤 프로세스도 지정되지 않습니다.
이 클래스는 WLM이 관리하지 않는 시스템에서 모든 고정된 페이지의 메모리 사용량을 누적합니다.
waitproc 프로세스의 CPU 사용량은 시스템이 100% 사용량인 것처럼 보이지 않게 하기 위해 어떤 클래스
에서도 누적되지 않습니다. 이 수퍼클래스는 자원 유형, 서브클래스 또는 지정된 지정 규칙에 대한 공유나 한
계를 가질 수 없습니다.
서브클래스
시스템 관리자 또는 수퍼클래스 관리자는 최대 61 서브클래스를 정의할 수 있습니다.
또한 두 개의 특수 서브클래스, 즉 Default와 Shared가 항상 정의됩니다.
Default 서브클래스
디폴트 서브클래스이며 항상 정의됩니다. 수퍼클래스의 특정 서브클래스에 자동으로 지정되지 않는 모든 프
로세스가 Default 서브클래스에 지정됩니다. 특정 지정 규칙을 제공하여 다른 프로세스를 Default 서브클래
스에 지정할 수도 있습니다.
Shared 서브클래스
수퍼클래스에서 두 개 이상의 서브클래스의 프로세스에 사용되는 모든 메모리 페이지를 수신합니다. 여기에
는 공유 메모리 영역의 페이지 및 같은 수퍼클래스의 두 개 이상의 서브클래스에 있는 프로세스에 사용되는
파일의 페이지가 포함됩니다. 모두 단일 서브클래스에 속하는 여러 프로세스에 사용되는 공유 메모리와 파일
은 해당 서브클래스와 연관됩니다. 같은 수퍼클래스의 다른 서브클래스에 있는 프로세스가 공유 메모리 영역
또는 파일에 액세스할 때만 페이지가 수퍼클래스의 Shared 서브클래스에 포함됩니다. Shared 서브클래스
에는 프로세스가 없습니다. 이 서브클래스는 서브클래스에 적용된 실제 메모리 공유와 제한만 포함할 수 있
으며 지정된 다른 자원 유형 또는 지정 규칙에 대한 공유나 제한을 포함할 수 없습니다. 같은 수퍼클래스의 다
른 서브클래스에 있는 프로세스가 공유하는 메모리 세그먼트가 Shared 서브클래스로 분류되는지 원래 서브
클래스에 그대로 있는지는 원래 서브클래스의 localshm 속성의 값에 따라 다릅니다.
클래스 속성
WLM 클래스의 모든 속성을 나열하십시오.
클래스 이름
최대 16자이며 대문자, 소문자, 숫자 및 밑줄 문자(_)를 사용할 수 있습니다.
티어
클래스 간의 자원 할당을 우선순위화하는 데 사용되는 0에서 9 사이의 숫자
상속
하위 프로세스가 상위 프로세스에서 클래스 지정을 상속하는지 여부를 지정합니다.
localshm
한 클래스에 속한 메모리 세그먼트를 공유 클래스로 마이그레이션하지 못하도록 합니다.
관리자(adminuser, admingroup, authgroup)(수퍼클래스만)
수퍼클래스의 관리를 위임합니다.
권한 부여(authuser, authgroup)
프로세스를 수동으로 지정할 수 있는 권한을 클래스에 위임합니다.
자원 세트(rset)
지정된 클래스가 CPU(프로세서 세트)에 따라 액세스할 수 있는 자원 세트를 제한합니다.
delshm
가상 메모리 한계로 인해 최종 참조 프로세스가 종료될 경우 공유 메모리 세그먼트를 삭제합니다.
장치 관리 137
vmeforce
클래스가 가상 메모리 제한에 도달할 때 클래스의 모든 프로세스를 중단할 것인지 또는 잘못된 프로세스만
중단할 것인지 표시합니다.
io_priority
클래스에 분류된 스레드별로 발행된 입출력 요청에 지정된 우선순위를 지정합니다. 이 우선순위는 장치 레벨
에서 입출력 버퍼의 우선순위를 지정하는 데 사용됩니다.스토리지 장치가 입출력 우선순위를 지원하지 않는
경우 우선순위가 무시됩니다. 유효한 입출력 우선순위는 0부터 15의 범위입니다.
관련 개념
워크로드 관리를 위해 클래스에 프로세스 지정
프로세스는 시스템 관리자가 제공하는 클래스 지정 규칙을 사용하여 클래스에 지정됩니다. 분류 기준은 사용자
ID, 그룹 ID, 애플리케이션 파일 이름, 프로세스 유형 및 애플리케이션 태그와 같은 프로세스의 속성 세트 값을 기
준으로 합니다.
티어 속성
티어는 시스템 자원이 WLM 클래스에 할당되는 순서를 표시합니다.
시스템 관리자는 0부터 9(가장 높거나 가장 중요한 티어는 0임)까지 번호를 매긴 최대 10개의 티어에 클래스를
정의할 수 있습니다. 티어 0에 사용할 수 있는 자원의 양은 모두 사용 가능한 시스템 자원입니다. 낮은(높은 번호)
티어에 사용할 수 있는 자원의 양은 모든 높은 티어에 사용되지 않은 자원의 양입니다. 클래스에 대한 목표 소비
백분율은 티어의 활성 공유 수, 티어에서 사용할 수 있는 자원의 양을 기준으로 합니다. 티어 0이 티어에서 항상
자원을 사용할 수 있도록 하는 유일한 티어이므로 시스템 조작에 필요한 프로세스를 이 티어의 클래스에 분류하
는 것이 좋습니다. 클래스에 대한 티어 값이 지정되지 않으면 티어 0에 지정됩니다.
티어는 수퍼클래스와 서브클래스 레벨에서 지정할 수 있습니다. 수퍼클래스 티어는 수퍼클래스 간의 자원 할당
우선순위를 지정하는 데 사용됩니다. 서브클래스 티어는 같은 수퍼클래스의 서브클래스 간의 자원 할당 우선순
위를 지정하는 데 사용됩니다. 다른 수퍼클래스의 서브티어 간의 관계는 없습니다.
상속 속성
클래스의 inheritance 속성은 프로세스의 분류 속성 중 하나가 변경될 때 클래스의 프로세스를 자동으로 재분
류할 것인지 표시합니다.
fork 서브루틴으로 새 프로세스가 작성되면 상속의 사용 여부와 관계없이 자동으로 상위 클래스를 상속받습니
다. 상위 프로세스에 태그가 있고 inherit tag at fork가 오프로 설정되고 상위 클래스에 대한 클래스 상속이 오프
인 경우는 예외입니다. 이 경우 하위 프로세스는 분류 규칙에 따라 재분류됩니다.
클래스에 대해 상속을 사용할 수 없는 경우 클래스의 프로세스는 규칙에 사용되는 프로세스 속성을 변경하는 서
비스를 호출한 후 분류 규칙에 따라 자동으로 분류됩니다. 가장 일반적인 호출은 exec 서브루틴이지만 분류를
변경할 수 있는 다른 서브루틴은 setuid, setgid, plock, setpri 및 wlm_set_tag입니다. 상속을 사용할
수 있는 경우 프로세스는 분류 규칙에 따라 재분류될 수 없으며 현재 클래스에 그대로 있습니다. 수동 지정은 상
속보다 우선하며 상속을 사용할 수 있는 클래스에 있는 프로세스를 재분류하는 데 사용될 수 있습니다.
inheritance 속성의 지정된 값은 예 또는 아니오일 수 있습니다. 지정되지 않은 경우, 상속은 클래스에 사용 가
능하지 않습니다.
이 속성은 수퍼클래스와 서브클래스 레벨에서 지정할 수 있습니다. 지정된 수퍼클래스의 서브클래스 경우
• inheritance 속성이 수퍼클래스와 서브클래스 레벨에서 예로 설정되면 서브클래스에 있는 프로세스의 하
위는 같은 서브클래스에 있습니다.
• inheritance 속성이 수퍼클래스에서 예로 설정되고 서브클래스에서 아니오(또는 지정되지 않음)로 설정되
면 서브클래스에 있는 프로세스의 하위는 같은 수퍼클래스에 있으며 수퍼클래스에 대한 지정 규칙에 따라 서브
클래스 중 하나에 분류됩니다.
• inheritance 속성이 수퍼클래스에 대해 아니오(또는 지정되지 않음)로 설정되고 서브클래스에 대해 예로
설정되면 서브클래스에 있는 프로세스의 하위는 수퍼클래스에 대한 자동 지정 규칙에 제출됩니다.
– 프로세스가 같은 수퍼클래스의 규칙에 따라 분류되면 계속 서브클래스에 있고 서브클래스의 지정 규칙으로
제출되지 않습니다.
– 프로세스가 다른 수퍼클래스의 수퍼클래스 규칙에 따라 분류되면 새 수퍼클래스의 서브클래스 지정 규칙이
적용되어 프로세스가 지정될 새 수퍼클래스의 서브클래스를 판별합니다.

• 수퍼클래스와 서브클래스 inheritance 속성이 모두 아니오(또는 지정되지 않음)로 설정되면 서브클래스에
있는 프로세스의 하위가 표준 자동 지정에 제출됩니다.
localshm 속성
localshm 속성은 수퍼클래스와 서브클래스 레벨에 지정될 수 있습니다.
localshm 속성은 다른 클래스의 프로세스에서 액세스할 때 하나의 클래스에 속한 메모리 세그먼트가 Shared
수퍼클래스 또는 서브클래스로 이주할 수 없도록 하는 데 사용됩니다. 속성의 가능한 값은 예 또는 아니오입니다.
yes의 값은 이 클래스의 공유 메모리 세그먼트가 클래스에 로컬로 남아 있어야 하고 적합한 공유 클래스로 마이
그레이션하지 않아야 한다는 의미입니다. 아니오 값은 속성이 지정되지 않은 경우 디폴트 값입니다.
메모리 세그먼트는 페이지 부재 시 분류됩니다. 세그먼트가 작성되면 Unclassified 수퍼클래스에 속하는 것으로
표시됩니다. 세그먼트의 첫 번째 페이지 부재 시 이 세그먼트는 결함 있는 프로세스와 같은 클래스로 분류됩니다.
나중에 세그먼트 페이지와는 다른 클래스에 속한 프로세스가 이 세그먼트에 없으면 WLM은 세그먼트를 해당
Shared 클래스(수퍼클래스 또는 서브클래스)로 재분류할 것인지 여부를 고려합니다. 결함 있는 프로세스와 세그
먼트가 다른 수퍼클래스에 속하면 다음 중 하나와 같이 됩니다.
• 세그먼트의 수퍼클래스에 예로 설정된 localshm 속성이 있으면 세그먼트는 계속 현재 수퍼클래스에 있습니
다. 세그먼트의 서브클래스에 예로 설정된 localshm 속성이 있으면 세그먼트는 계속 현재 서브클래스에 있습
니다. 수퍼클래스 localshm 속성이 예로 설정되고 서브클래스 속성이 아니오로 설정되면 현재 수퍼클래스의
Shared 클래스로 이동합니다.
• 세그먼트의 수퍼클래스에 아니오로 설정된 localshm 속성이 있으면 세그먼트는 Shared 수퍼클래스로 이동
합니다. 이는 기본 조치입니다.
결함 있는 프로세스와 세그먼트가 같은 수퍼클래스의 다른 서브클래스에 속하고 세그먼트의 서브클래스에 예로
설정된 localshm 속성이 있으면 세그먼트는 계속 현재 클래스(수퍼클래스 및 서브클래스)에 있습니다. 그렇지
않으면 세그먼트는 수퍼클래스의 Shared 서브클래스로 이동합니다.
물론, 결함 있는 프로세스와 세그먼트가 같은 클래스(같은 수퍼클래스와 같은 서브클래스)에 속하면 세그먼트는
localshm 속성의 값과 관계없이 재분류되지 않습니다.
관리자 속성
adminuser 및 admingroup 속성은 수퍼클래스 관리를 사용자 또는 사용자 그룹에 위임하는 데 사용됩니다.
참고: 이러한 속성은 수퍼클래스에만 유효합니다.
adminuser 속성은 수퍼클래스에 대한 관리 태스크를 수행할 수 있는 권한이 부여된 사용자(/etc/passwd에
나열)의 이름을 지정합니다. admingroup 속성은 수퍼클래스에 대한 관리 태스크를 수행할 수 있는 권한이 부여
된 사용자 그룹(/etc/group에 나열)의 이름을 지정합니다.
각 속성에 하나의 값(사용자 또는 그룹)만 허용됩니다. 둘 중 하나, 둘 다 또는 없음을 지정할 수 있습니다. 사용자
또는 그룹은 다음을 수행할 권한을 갖습니다.
• 서브클래스 작성 및 삭제
• 서브클래스에 대한 속성, 자원 송유 및 제한 변경
• 서브클래스 지정 규칙 정의, 제거 또는 수정
• 수퍼클래스에 대한 활성 WLM 구성 갱신
권한 부여 속성
authuser 및 authgroup 속성은 모든 클래스에 유효합니다. 이러한 속성은 프로세스를 클래스(수퍼클래스 또
는 서브클래스)에 수동으로 지정할 권한이 부여된 사용자 또는 그룹을 지정하는 데 사용됩니다.
프로세스(또는 프로세스 그룹)를 수퍼클래스에 수동으로 지정할 경우 각 프로세스에 지정할 수퍼클래스의 서브
클래스를 판별하는 데 수퍼클래스의 지정 규칙이 사용됩니다.
각 속성에 하나의 값(사용자 또는 그룹)만 허용됩니다. 둘 중 하나, 둘 다 또는 없음을 지정할 수 있습니다.
자원 세트 속성
자원 세트 속성(rset이라고 함)은 모든 클래스에 대해 지정할 수 있습니다. 해당 값은 시스템 관리자에 정의된 자
원 세트의 이름입니다.
장치 관리 139
rset 속성은 시스템에서 사용할 수 있는 CPU 자원의 서브세트(프로세서 세트)를 표시합니다. 디폴트 값은 시스템
에서 사용할 수 있는 모든 CPU에 대한 액세스를 부여하는 "시스템"입니다. 서브클래스에 대해 rset이 지정된 경
우 세트에 있는 CPU 세트가 수퍼클래스에서 사용할 수 있는 CPU의 서브세트이어야 한다는 것이 유일한 제한입
니다. (자세한 정보는 mkrset 명령을 참조하십시오.)
참고: 자원을 지정하면 티어 0에 있지 않은 클래스로 설정된다는 것을 고려하십시오. 낮은 티어는 높은 티어에 사
용되지 않은 자원에만 액세스하므로 non-tier-0 클래스를 시스템에서 CPU의 서브세트로 제한하면 해당 CPU에
서 사용할 수 있는 CPU 시간이 없는 경우 자원이 공급되지 않을 수 있습니다.
워크로드 관리자에서 프로세스 분류

WLM에서 다음 두 방법 중 하나로 프로세스를 분류할 수 있습니다.
• 프로세스 분류 속성이 변경될 때 지정 규칙을 사용하여 프로세스가 자동으로 지정됩니다. WLM이 활성 모드에
서 실행되면 이 자동 지정은 항상 유효합니다(끌 수 없음). 이 방법은 프로세스를 분류하는 가장 일반적인 방법
입니다.
• 선택된 프로세스 또는 프로세스 그룹을 프로세스와 목표 클래스에 대한 필수 권한을 가진 사용자별로 클래스에
수동으로 지정할 수 있습니다. 매뉴얼 지정은 WLM 명령을 사용하여 수행될 수 있고, 이는 직접 또는 SMIT를
통해 또는 WLM API(Application Programming Interface)의 기능을 사용하여 애플리케이션에 의해 호출될 수
있습니다. 이 수동 지정은 자동 지정과 상속을 재정의합니다.
워크로드 관리자에서 자동 클래스 지정

클래스에 프로세스를 자동 지정할 경우 WLM 관리자가 지정한 클래스 지정 규칙 세트가 사용됩니다.
지정 규칙에는 두 가지 레벨이 있습니다.
• 제공된 프로세스를 지정할 수퍼클래스를 결정하는 데 사용되는 WLM 구성 레벨의 지정 규칙 세트
• 프로세스를 지정할 수퍼클래스의 서브클래스를 결정하는 데 사용되는 지정 규칙 세트가 있는 서브클래스가 정
의되어 있는 각 수퍼클래스
두 레벨의 지정 규칙은 프로세스 속성 세트 값을 기준으로 합니다. 이러한 속성은 다음과 같습니다.
• 프로세스 사용자 ID
• 프로세스 그룹 ID
• 실행된 애플리케이션(프로그램)의 경로 이름
• 프로세스의 유형(예: 32bit 또는 64bit)
• 프로세스 태그
태그는 애플리케이션이 WLM API를 사용하여 프로그램별로 설정할 수 있는 문자열로 정의되는 프로세스 속성입
니다.
이러한 프로세스 속성의 값과 클래스 지정 규칙 파일(rules)에 지정된 가능한 값 리스트를 비교하여 속성이 변
경될 때마다 분류가 수행됩니다. 비교를 통해 프로세스 속성의 현재 값과 일치하는 규칙이 판별됩니다.
클래스 지정 규칙은 다음 필드(하나 이상의 공백으로 구분됨)가 포함된 텍스트 문자열입니다.
항목 설명
이름 rules 파일의 레벨에 해당하는 클래스 파일에 정의된 클래스의 이름을 포함해야 합니다
(수퍼클래스 또는 서브클래스). 클래스 이름에는 대문자와 소문자, 숫자, 밑줄 문자만 사
용할 수 있으며 최대 길이는 16자입니다. 시스템 정의 클래스인 Unclassified,
Unmanaged 및 Shared에 대해서는 지정 규칙을 지정할 수 없습니다.
예약됨. 나중에 확장할 수 있도록 예약되었습니다. 값은 하이픈(-)이어야 하며 반드시 표시되어야
합니다.
사용자 하이픈(-) 또는 한 개 이상의 유효한 사용자 이름(/etc/passwd 파일에 정의됨)을 포함
할 수 있습니다. 리스트는 쉼표(,)로 구분되는 하나 이상의 이름으로 구성됩니다. 오른쪽
분할창의 느낌표(!)는 지정된 사용자를 클래스에서 제외하기 위해 이름 앞에 사용될 수 있
습니다. 전체 Korn 쉘 패턴 대응 구문을 사용하여 사용자 이름 세트를 일치시키는 패턴을
지정할 수 있습니다. 유효한 사용자 이름이 없으면 규칙이 무시됩니다.

항목 설명
그룹 하이픈(-) 또는 한 개 이상의 유효한 그룹 이름(/etc/group 파일에 정의됨)을 포함할 수
있습니다. 리스트는 쉼표(,)로 구분되는 하나 이상의 이름으로 구성됩니다. 오른쪽 분할창
의 느낌표(!)는 지정된 그룹을 클래스에서 제외하기 위해 이름 앞에 사용될 수 있습니다.
패턴은 구문과 대응하는 전체 Korn 쉘 패턴을 사용하여 그룹 이름 세트와 대응하도록 지
정될 수 있습니다. 유효한 그룹 이름이 없으면 규칙이 무시됩니다.
애플리케이션 하이픈(-) 또는 애플리케이션 경로 이름의 리스트를 포함할 수 있습니다. 클래스에 포함
된 프로세스가 실행하는 애플리케이션(프로그램)의 경로 이름입니다. 애플리케이션 이름
은 전체 경로 이름 또는 경로 이름과 일치하는 Korn 쉘 패턴이 됩니다. 리스트는 쉼표(,)로
구분되는 하나 이상의 경로 이름으로 구성됩니다. 오른쪽 분할창의 느낌표(!)는 지정된 애
플리케이션을 제외하기 위해 이름 앞에 사용될 수 있습니다.
로드할 때 리스트에 최소한 하나의 애플리케이션이 있어야 합니다. 그렇지 않으면 규칙이
무시됩니다. 그러므로 처음에 무시되는 규칙은 나중에 리스트에 있는 애플리케이션을 한
개 이상 포함하는 파일 시스템이 마운트되면 유효하게 될 수 있습니다.
유형 하이픈(-) 또는 프로세스 속성 리스트를 포함할 수 있습니다. 이러한 속성의 값은 다음과

같습니다.
• 32bit: 32비트 프로세스
• 64bit: 64비트 프로세스
• plock: 메모리를 고정하는 plock 서브루틴이라는 프로세스
• fixed: 고정 우선순위 프로세스(SCHED_FIFO 또는 SCHED_RR)
fixed 유형은 분류에만 사용됩니다. WLM은 고정 우선순위 프로세스 또는 스레드의 프
로세서 사용을 규제하지 않습니다. 고정 우선순위 프로세스로 인해 클래스의 다른 프로세
스들이 손실될 수 있으므로 이러한 작업을 격리시키기 위해 이 분류 속성이 제공됩니다.
이 속성은 이러한 프로세스의 소비량을 보고하는 데도 사용할 수 있습니다.
type 필드의 값은 위의 속성 중 하나 이상을 더하기(+) 기호로 구분하여 조합할 수 있습
니다. 32bit와 64bit 값은 함께 사용할 수 없습니다.
태그 하이픈(-) 또는 애플리케이션 태그 리스트를 포함할 수 있습니다. 애플리케이션 태그는

최대 30개의 영숫자 문자열입니다. 리스트는 쉼표로 구분되는 하나 이상의 애플리케이션
태그 값으로 구성됩니다.
User, Group, Application 및 Tag 속성은 속성값 그룹화가 될 수 있습니다.

프로세스가 작성되면(분기 실행) 상위와 같은 클래스에 있게 됩니다. 새 프로세스가 분류에 사용된 프로세스 속
성 중 하나를 수정할 수 있는 시스템 호출(예: exec, setuid(및 관련 호출), setgid(및 관련 호출), setpri 및 plock)을
발행하면 재분류가 수행됩니다.
프로세스를 분류하기 위해 WLM은 활성 구성에 대한 최상위 rules 파일을 검사하여 프로세스가 속한 수퍼클래
스를 판별합니다. 파일의 각 규칙에 대해 WLM은 프로세스 속성의 현재 값을 규칙에 지정된 값 및 값 리스트와 비
교합니다. 규칙은 파일에 표시된 순으로 검사됩니다. 일치하는 프로세스를 찾으면 규칙의 첫 번째 필드에 이름이
지정된 수퍼클래스에 프로세스가 지정됩니다. 그런 다음 프로세스가 지정될 서브클래스를 판별하는 방법과 같은
방식으로 수퍼클래스에 대한 규칙 파일을 확인합니다.
프로세스를 규칙 중 하나와 일치시키려면 각 속성은 규칙의 해당 필드와 일치해야 합니다. 다음은 속성의 값을
rules 파일의 필드에 있는 값과 일치시킬 것인지 여부를 판별하는 데 사용되는 기준의 리스트입니다.
• 규칙 파일의 필드에 하이픈(-) 값이 있으면 해당 프로세스 속성의 값이 일치합니다.
• type을 제외한 모든 속성의 경우, 프로세스 속성의 값이 제외되지 않은("!"가 앞에 옴) 규칙에서 목록의 값 중 하
나와 대응하면 일치가 발생한 것입니다.
• type 속성의 경우 규칙의 값 중 하나가 더하기(+)로 구분되는 두 개 이상의 값으로 구성되면 해당 특성이 모든
값과 일치하는 경우에만 프로세스가 일치합니다.
장치 관리 141
수퍼클래스와 서브클래스 레벨 둘 모두에서 WLM은 rules 파일에 나타나는 순서로 규칙을 통과하고, 프로세스
를 프로세스가 일치하는 첫 번째 규칙에 해당하는 클래스로 분류합니다. 그러므로 규칙 파일의 규칙 순서는 매우
중요합니다. 규칙 파일을 작성하거나 수정할 때 주의하십시오.
워크로드 관리자에서 수동 클래스 지정

프로세스 또는 프로세스 그룹은 SMIT 또는 wlmassign 명령을 사용하여 수퍼클래스 및/또는 서브클래스에 수
동으로 지정될 수 있습니다.
자세한 정보는 wlmassign을 참조하십시오. 애플리케이션은 wlm_assign API 함수를 통해 프로세스를 지정할
수 있습니다.
프로세스를 수동으로 클래스에 지정하거나 기존 수동 지정을 취소하려면 사용자에게 적절한 특권 레벨이 있어야
합니다. 수퍼클래스 레벨, 서브클래스 레벨 또는 둘 다에서 수동 지정을 따로 작성하거나 취소할 수 있습니다. 이
지정은 WLM 관리 도구에 사용되는 명령행 인터페이스의 옵션 세트와 프로그래밍 인터페이스의 플래그에 지정
됩니다. 그러므로 프로세스를 수퍼클래스에만, 서브클래스에만 또는 수퍼클래스와 해당 수퍼클래스의 서브클래
스에 수동으로 지정할 수 있습니다. 후자의 경우 이중 지정은 다른 사용자와 동시에(단일 명령 또는 API 호출을
사용하여) 또는 다른 시간에 수행될 수 있습니다.
지정은 매우 유연하지만 혼동스러울 수 있습니다. 다음은 가능한 경우에 대한 두 가지 예제입니다.
예제 1: 프로세스의 첫 번째 지정
시스템 관리자는 superclassA에서 superclassB(수퍼클래스 레벨만 지정)로 Process1을 수동으로 지정합니
다. superclassB의 서브클래스에 대한 자동 지정 규칙은 프로세스가 지정되는 서브클래스를 판별하기 위해
WLM에 사용됩니다. Process1은 superclassB.subclassA에 지정되고 "수퍼클래스만" 지정이 있는 것으로
지정됩니다.
적절한 특권이 있는 사용자는 현재 클래스 superclassA.subclassA에서 같은 수퍼클래스
superclassA.subclassB의 새 서브클래스로 Process2를 지정합니다. Process2가 새 서브클래스에 지정되고
"서브클래스만" 지정이 있는 것으로 지정됩니다.
superclassB에 대한 서브클래스의 WLM 관리자는 Process1을 superclassB의 다른 서브클래스인
subclassC에 재지정합니다. Process1은 superclassB.subclassC로 재분류되고 수퍼클래스와 서브클래스 레
벨 지정이 있는 것으로 지정됩니다.
예제 2: 재지정 또는 수동 지정 취소
서브클래스 레벨에서 재지정 및 수동 재지정 취소는 덜 복잡하고 서브클래스 레벨 지정에만 영향을 미칩니
다.
시스템 관리자가 Process2를 많은 자원이 있는 수퍼클래스에 넣고 Process2를 superclassC에 수동으로 지
정하려고 한다고 가정해보십시오. 예제 1에서 Process2는 "서브클래스만" 지정이 있는 superclassA의
subclassB에 수동으로 지정되었습니다. Process2가 다른 수퍼클래스에 지정되므로 이전 수동 지정은 의미
가 없어져서 취소됩니다. 이제, Process2에는 superclassC에 대한 "수퍼클래스만" 수동 지정이 있고 상속이
없으면 자동 지정 규칙을 사용하여 superclassC의 서브클래스에 지정됩니다.
이제, 시스템 관리자는 Process1에서 superclassB로의 수동 지정을 종료하기로 결정했습니다. Process1의
"수퍼클래스 레벨" 수동 지정이 취소되고 상속이 없는 경우 Process1은 상위 레벨 자동 지정 규칙을 사용하
여 수퍼클래스에 지정됩니다.
규칙이 변경되지 않으면 Process1은 superclassA에 지정되고 superclassB.subclassC에 대한 서브클래스
레벨 수동 지정은 의미가 없어지고 취소됩니다.
어떤 이유로 최상위 레벨 규칙이 Process1을 superclassB에 지정해도 superclassB.subclassC에 대한 서브
클래스 레벨 지정은 유효합니다. 이제, Process1에는 "서브클래스만" 수동 지정이 있습니다.
워크로드 관리자에 대한 갱신사항

wlmcntrl -u 명령을 사용하여 WLM이 갱신되면 갱신된 구성은 새 분류 규칙 세트를 로드할 수 있습니다.
이러한 경우 프로세스는 종종 새 규칙을 사용하여 재분류됩니다. WLM은 해당 클래스가 새 구성에 있는 한, 수동
으로 지정되거나 상속을 사용할 수 있는 클래스에 있는 프로세스를 재분류하지 않습니다.
워크로드 관리자에 대한 보안 고려사항

프로세스를 클래스에 지정하거나 이전 수동 지정을 취소하려면 사용자에게 프로세스와 목표 클래스에 대한 권한
이 있어야 합니다.

이러한 제한조건은 다음과 같은 규칙으로 변환됩니다.
• 루트 사용자는 모든 프로세스를 모든 클래스에 지정할 수 있습니다.
• 제공된 수퍼클래스의 서브클래스에 대한 관리 권한을 가진 사용자(즉, 사용자 또는 그룹 이름이 수퍼클래스의
adminuser와 admingroup 속성에 지정된 사용자 또는 그룹 이름과 일치함)는 이 수퍼클래스의 서브클래스
중 하나에서 수퍼클래스의 다른 서브클래스로 프로세스를 수동으로 재지정할 수 있습니다.
• 사용자는 수동 지정 권한이 있는 서브클래스에 자신의 프로세스(같은 실제 또는 유효 사용자 ID와 연관된 프로
세스)를 수동으로 지정할 수 있습니다(즉, 사용자 또는 그룹 이름이 수퍼클래스 또는 서브클래스의 authuser
와 authgroup 속성에 지정된 사용자 또는 그룹 이름과 일치함).
수동 지정을 수정하거나 종료하려면 사용자에게 최소한 최종 수동 지정을 발행한 사용자와 같은 레벨의 권한이
있어야 합니다.
워크로드 관리자를 사용한 자원 관리

WLM은 시스템에서 활성 상태의 스레드와 프로세스의 자원 사용량을 클래스별로 모니터링하고 조정합니다.
WLM이 관리하는 각 자원 유형의 클래스별 최소 또는 최대 제한과 각 자원의 클래스별 목표 값을 설정할 수 있습
니다.
이 목표는 클래스의 작업에 최적인 자원의 양을 표시합니다. 수퍼클래스 레벨의 공유와 제한은 시스템에서 사용
할 수 있는 각 자원의 전체 양을 나타냅니다. 서브클래스 레벨에서 공유와 제한은 서브클래스가 있는 수퍼클래스
(수퍼클래스 목표)에서 사용할 수 있도록 만드는 각 자원의 양을 나타냅니다. 클래스의 계층은 시스템 자원을 사
용자 그룹(수퍼클래스) 사이에 나누고 이 자원 공유의 관리를 수퍼클래스 관리자에게 위임하는 방법입니다. 각
수퍼클래스 관리자는 서브클래스를 작성하고 이러한 서브클래스에 대한 자원 인타이틀먼트를 정의하여 이 자원
의 양을 그룹의 사용자 사이에 재분배할 수 있습니다.
워크로드 관리자의 자원 유형
WLM은 소비량의 백분율에 따라 세 유형의 자원을 관리합니다.
항목 설명
클래스의 스레드 CPU 사용량 클래스의 모든 스레드가 사용하는 모든 CPU 순환의 합계입니다.
클래스의 프로세스에 대한 실제 클래스의 프로세스에 속한 모든 메모리 페이지의 합계입니다.
메모리 사용량
클래스의 디스크 입출력 대역폭 클래스가 액세스하는 각 디스크 장치에 있는 클래스의 스레드에 의해 시작된 모든
입출력의 대역폭(초당 512바이트 블록)입니다.
매초마다 WLM은 다음과 같이 마지막 초 동안 각 자원의 클래스별 사용량을 사용 가능한 총 자원의 백분율로 계
산합니다.
• CPU의 경우 초당 사용 가능한 총 CPU 시간은 시스템에 있는 CPU 수의 두 배인 1초입니다. 예를 들어, 8웨이
SMP에서 결합된 클래스의 모든 스레드가 마지막 초 동안 CPU 시간의 2초를 사용한 경우 2/8 = 25%로 표시됩
니다. WLM이 규정에 사용하는 백분율은 이 "동시" 초당 자원 사용량의 몇 초 동안 평균 이하입니다.
• 실제 메모리의 경우 지정된 시간에 프로세스에 사용 가능한 총 실제 메모리는 실제로 시스템에 있는 총 메모리
페이지 수에서 고정된 페이지 수를 뺀 것과 같습니다. 고정된 페이지는 클래스에서 스틸될 수 없고 메모리 사용
량을 규정하기 위해 다른 클래스에 제공될 수 없기 때문에 WLM이 관리하지 않습니다. 클래스의 메모리 사용량
은 클래스의 모든 프로세스가 소유한 고정되지 않은 메모리 페이지 수와 시스템에서 사용할 수 있는 페이지 수
의 비율을 백분율로 표시한 것입니다.
• 디스크 입출력의 경우 주요한 문제점은 장치에 사용할 수 있는 대역폭을 판별하는 것입니다. 디스크를 100%
사용 중이면 처리량(초당 블록)은 여러 애플리케이션이 임의 입출력을 생성하는 경우와 하나의 애플리케이션
이 순차 입출력을 수행하는 경우가 매우 다릅니다. 순차 입출력에 대해 측정한 최대 처리량(장치에 사용할 수
있는 입출력 대역폭의 값)만 사용하여 임의 입출력에서 장치 사용량의 백분율을 계산한 경우 실제로 장치 사용
량이 100%일 때 20%로 잘못 생각할 수 있습니다.
클래스별 디스크 사용량의 정확하고 신뢰할만한 백분율을 얻기 위해 WLM은 디스크 드라이버가 제공한 통계
(iostat 명령을 사용하여 표시)를 사용하여 각 디스크 장치에 마지막 초 동안 장치를 사용한 시간의 백분율을 제
공합니다. WLM은 장치에 액세스하는 모든 클래스가 마지막 초 동안 장치에서 읽거나 쓴 총 블록 수, 각 클래스가
읽거나 쓴 블록 수 및 장치 사용량의 백분율을 계산합니다. 그런 다음, WLM은 각 클래스가 사용한 디스크 처리량
의 백분율을 계산합니다.
장치 관리 143
예를 들어, 마지막 초 동안 읽거나 쓴 총 블록 수가 1000이고 장치의 70%를 사용했으면 100 블록을 읽거나 쓴
클래스는 디스크 대역폭의 7%를 사용한 것입니다. CPU 시간(다른 갱신 가능한 자원)과 마찬가지로 WLM이 디스
크 입출력 규정에 사용한 값은 몇 초 동안 이러한 초당 백분율의 평균 이하입니다.
디스크 입출력 자원의 경우 공유와 제한은 클래스에서 액세스하는 각 디스크 장치에 개별적으로 적용됩니다. 규
정은 장치별로 적용됩니다. 즉 클래스가 한 장치에 대한 인타이틀먼트를 제어하고 이 장치에 대한 입출력은 제한
을 받지만, 이 클래스는 다른 디스크의 제어를 받으며 다른 장치에 대한 입출력은 제한을 받지 않습니다.
WLM은 총 소비를 기초로 하여 자원의 사용통계와 규정을 지원합니다. 이 방식으로 규정할 수 있는 자원 유형에
는 총 클래스와 총 프로세스 등의 두 가지가 있습니다.
총 클래스
클래스의 프로세스, 스레드 및 로그인 세션 수에 대해 클래스별 제한을 지정할 수 있습니다. 이러한 제한은 언
제든지 클래스에 존재할 수 있는 각 자원의 절대 개수로 지정됩니다. 이러한 제한은 엄격하게 적용됩니다. 클
래스가 이러한 자원 중 하나에 대한 제한에 도달하면 자원의 다른 인스턴스를 작성하는 데 실패합니다. 클래
스가 자원에 지정한 제한 이하가 될 때까지 클래스의 프로세스에 대한 조작은 계속 실패합니다.
총 프로세스
총 CPU 시간, 디스크 입출력의 블록 및 로그인 세션의 연결 시간에 대해 프로세스별 제한을 지정할 수 있습니
다. 이러한 제한은 클래스 레벨에 지정되지만 클래스의 각 프로세스에 따로 적용됩니다(각 프로세스는 이 양
을 사용할 수 있음). 이러한 사용 값은 누적되므로 수명 기간 동안 프로세스에 사용된 각 특정 자원의 총 양을
표시합니다. 프로세스가 자원에 대한 총계 제한을 초과하면 프로세스가 종료됩니다. 프로세스에 SIGTERM
신호가 전송되고 이 신호를 받고 5초의 유예 기간 후 종료되지 않으면 SIGKILL 신호가 전송됩니다. 로그인
세션이 연결 시간 제한의 90%에 도달하면 사용자에게 세션이 곧 종료됨을 경고하는 경고 메시지가 제어 터
미널에 쓰여집니다.
워크로드 관리자의 목표 공유
클래스의 목표(또는 원하는) 자원 소비량 백분율은 특정 자원에 대한 공유 수에 의해 결정됩니다.
공유는 티어의 다른 클래스에 따라 클래스가 사용하는 특정 자원의 양을 표시합니다. 특정 자원에 대한 클래스의
목표 백분율은 티어의 활성 공유 수로 나눈 공유 수입니다. 제한도 사용되는 경우에는 목표가 범위[최소값, 소프
트 최대값]로 제한됩니다. 계산된 목표가 이 범위를 벗어나면 적절한 상위/하위 경계로 설정됩니다(자원 제한 참
조). 활성 공유 수는 클래스에 최소한 하나의 활성 프로세스가 있는 모든 클래스의 총 공유 수입니다. 활성 공유 수
는 동적이므로 목표가 됩니다. 클래스가 티어의 유일한 활성 클래스이면 목표는 티어에서 사용할 수 있는 자원량
의 100%가 됩니다.
예를 들어, 특정 자원 15, 10 및 5에 대해 공유가 있는 티어 0—A, B 및 C에 세 개의 활성 수퍼클래스 클래스가 있
으면 목표는 다음과 같습니다.
target(A) = 15/30 = 50%

target(B) = 10/30 = 33%
target(C) = 5/30 = 17%
나중에 클래스 B가 비활성화(활성 프로세스가 없음)되면 클래스 A와 C의 목표는 자동으로 조정됩니다.
target(A) = 15/20 = 75%

target(C) = 5/20 = 25%
공유는 활성/비활성화될 때 클래스에 할당된 자원을 다른 클래스에 고르게 분배하거나 다른 클래스에서 가져올
수 있는 자동 조정 백분율을 표시합니다.
높은 유연성을 위해 클래스의 공유 수는 1 - 65535가 될 수 있습니다. 공유는 수퍼클래스와 서브클래스에 지정
할 수 있습니다. 수퍼클래스의 경우 공유는 같은 티어의 다른 모든 활성 수퍼클래스와 상대적입니다. 서브클래스
의 경우 공유는 같은 티어의 같은 수퍼클래스에 있는 다른 모든 활성 서브클래스와 상대적입니다. 한 수퍼클래스
의 서브클래스에 대한 공유는 다른 수퍼클래스의 서브클래스에 대한 공유와 관련이 없습니다.
일부 경우에는 클래스의 목표를 활성 공유 수와 독립적으로 만드는 것이 바람직할 수 있습니다. 이를 위해 공유
수에 "-" 값을 지정할 수 있습니다. 이 경우 해당 자원에 대해 클래스가 규정되지 않으므로 공유가 없으며 목표는
활성 공유 수에 종속되지 않습니다. 목표는 티어에서 사용할 수 있는 자원(티어의 다른 모든 클래스에 대한 최소
의 합계)으로 설정됩니다. 이 목표 또는 실제 소비량(더 낮은 것으로 함)은 같은 티어의 다른 클래스에서 사용할
수 있는 목표나 소비량에서 가져옵니다.
예를 들어, 클래스 A, B, C 및 D에는 각각 특정 자원 "-", 200, 150 및 100에 대한 공유가 있습니다. 모든 클래스
는 활성화되며 클래스 A는 자원의 50%를 사용합니다.

target(A) = unregulated = 100%
target(B) = 200/450 * available = 44% * 50% = 22%
target(C) = 150/450 * available = 33% * 50% = 17%
target(D) = 100/450 * available = 22% * 50% = 11%
클래스 A가 규정되지 않고 사용 가능한 자원의 50%를 사용하면 다른 클래스는 50%만 사용할 수 있으며 목표는
이 백분율에 따라 계산됩니다. 클래스 A는 항상 목표(100%) 이하이므로 목표 이상인 같은 티어의 다른 모든 클
래스보다 우선순위가 항상 높습니다(자세한 정보는 147 페이지의 『워크로드 관리자의 클래스 우선순위 』 참
조).
참고: 자원에 대해 클래스를 규정하지 않는다는 것이 높은 티어에 배치하는 것은 아닙니다. 여기에 나열한 다음과
같은 작동은 규정되지 않은 클래스(같은 티어의)에 해당하고 클래스가 높은 티어에 있는 경우에는 해당되지 않습
니다.
• 공유가 자원별로 정의되므로 클래스는 하나 이상의 자원에 대해 규정되지 않고 다른 자원에 대해서는 규정될
수 있습니다.
• 같은 티어의 다른 클래스에 대한 최소 제한이 제공됩니다. 높은 티어는 낮은 티어에 지정된 최소를 제공하지 않
습니다.
• 공유가 있는 클래스의 최소 제한이 없어도 규정되지 않은 클래스의 소비량은 티어에서 사용할 수 있는 일부 자
원과 경합하기 때문에 공유가 있는 클래스에 어느 정도 종속적입니다. 제공된 워크로드에서의 작동을 보려면
약간의 실험이 필요합니다.
공유 수가 지정되지 않으면 디폴트 값 "-"이 사용되고 해당 자원에 대해 클래스가 규정되지 않습니다. WLM의 첫
번째 버전에서 디폴트 공유 값(지정되지 않은 경우)은 1입니다.
모든 자원 유형에 대해 클래스별 공유가 지정됩니다. 공유는 shares 파일의 스탠자에 지정됩니다. 예를 들어 다
음과 같습니다.
shares
classname:
CPU = 2
memory = 4
diskIO = 3
워크로드 관리자에서 자원 한계 지정
WLM은 공유를 사용하여 상대적인 자원 인타이틀먼트 부여를 정의하는 것 외에도 클래스의 자원 한계를 지정하
는 기능을 제공합니다. 관리자는 자원 한계를 통해 자원 할당을 보다 잘 제어할 수 있습니다. 이러한 한계는 백분
율로 지정되며 클래스가 있는 티어에 사용할 수 있는 자원의 양을 기준으로 합니다.
백분율 기반 규정에는 세 가지 유형의 한계가 있습니다.
최소값
클래스에 사용할 수 있는 최소 자원량입니다. 실제 클래스 소비량이 이 값보다 작으면 클래스에 자원에 대한
최고 우선순위 액세스가 부여됩니다. 가능한 값은 0 - 100이며 디폴트 값은 0입니다(지정되지 않은 경우).
소프트 최대값
자원에 대한 경합이 있을 경우 클래스가 사용할 수 있는 최대 자원량입니다. 클래스 소비량이 이 값을 초과하
면 티어의 클래스에 최저 우선순위가 지정됩니다. 자원에 대한 경합(같은 티어의 다른 클래스에서 요구됨)이
없으면 원하는 만큼 클래스를 사용할 수 있습니다. 가능한 값은 0 - 100이며 디폴트 값은 100입니다(지정되
지 않은 경우).
하드 최대값
경합이 없는 경우에도 클래스가 사용할 수 있는 최대 자원량입니다. 클래스가 이 한계에 도달하면 소비량 백
분율이 한계값 이하로 떨어질 때까지 추가 자원을 사용할 수 없습니다. 가능한 값은 0 - 100이며 디폴트 값은
100입니다(지정되지 않은 경우).
자원 한계 값은 각 클래스에 대한 스탠자 내의 자원 한계 파일에 자원 유형별로 지정됩니다. 한계 값은 최소값에
서 소프트 최대값까지이며 공백 없이 하이픈(-)으로 구분됩니다. 하드 최대값은 지정될 때 소프트 최대값을 따르
며 세미콜론(;)으로 구분됩니다. 각 한계 값의 뒤에는 퍼센트 부호(%)가 옵니다.
다음은 규칙 파일 사용에 대한 예제입니다.
• acct3 그룹의 사용자 joe가 /bin/vi를 실행하면 프로세스가 수퍼클래스 acctg에 배치됩니다.
장치 관리 145
• dev 그룹의 사용자 sue가 /bin/emacs를 실행하면 프로세스가 수퍼클래스 devlt(그룹 ID 일치)에 배치되지
만 사용자 sue가 해당 클래스에서 제외되었기 때문에 편집기 서브클래스로 분류되지 않습니다. 프로세스는
devlt로 이동합니다. 디폴트임.
• DB 관리자가 데이터베이스 DB1을 제공하기 위해 oracle의 사용자 ID와 dbm의 그룹 ID로 /usr/sbin/
oracle을 시작하면, 프로세스는 기본 수퍼클래스로 분류됩니다. 프로세스가 태그를 _DB1으로 설정할 경우
만 수퍼클래스 db1에 지정됩니다.
limits 파일의 스탠자에 모든 자원 유형에 대한 한계가 클래스별로 지정됩니다. 예를 들어 다음과 같습니다.
shares
classname:
CPU = 0%-50%;80%
memory = 10%-30%;50%
이 예제에서는 디스크 입출력에 대한 한계가 설정되어 있지 않는데 시스템 디폴트 값을 사용하면 다음과 같이 변
환됩니다.
diskIO = 0%-100%;100%
앞의 예제에서는 모두 수퍼클래스와 서브클래스의 상속 속성이 예로 설정되어 있지 않은 것으로 가정합니다. 그

렇지 않으면 새 프로세스는 상위로부터 수퍼클래스 또는 서브클래스를 상속받습니다.
다음은 자원 한계 값과 관련한 WLM 제한조건입니다.
• 최소값 한계는 소프트 최대값 한계 이하여야 합니다.
• 소프트 최대값 한계는 하드 최대값 한계 이하여야 합니다.
• 티어 내 모든 수퍼클래스의 최소값 합계는 100을 초과할 수 없습니다.
• 티어 내에 지정된 수퍼클래스의 모든 서브클래스의 최소값 합계는 100을 초과할 수 없습니다.
하드 메모리 제한이 있는 클래스가 이 제한에 도달하고 더 많은 페이지를 요청하면 VMM 페이지 교체 알고리즘
(LRU)이 시작되고 제한된 클래스에서 페이지를 "스틸"하여 페이지 수를 하드 최대값 이하로 낮춘 후 새 페이지를
분배합니다. 이 동작은 올바른 동작이지만 추가 페이징 활동은 사용 가능한 페이지가 많은 경우에도 발생할 수 있
기 때문에 시스템의 일반적인 성능에 영향을 미칩니다. 클래스에 대한 하드 메모리 최대값을 설정하기 전에 다른
클래스에 대한 최소 메모리 제한을 설정하는 것이 좋습니다.
최소값 이하의 클래스는 티어에서 우선순위가 가장 높으므로 최소값 합계는 같은 티어의 다른 클래스에 대한 자
원 요구량에 따라 적절한 레벨을 유지해야 합니다.
티어 내 최소값 합계가 100 이하여야 한다는 제한조건은 우선순위가 가장 높은 티어의 클래스는 항상 최소값 한
계까지 자원을 사용할 수 있음을 의미합니다. WLM은 클래스가 실제로 최소값 한계에 도달할지는 보장하지 않습
니다. 이는 클래스의 프로세스가 자원을 사용하는 방법 및 적용되는 다른 한계에 따라 다릅니다. 예를 들어, 메모
리가 충분하지 않는 클래스는 CPU 인타이틀먼트에 도달할 수 없습니다.
실제 메모리에 대해 최소 메모리 한계를 설정하면 클래스 프로세스의 메모리 페이지(최소한 최고 우선순위 티어
의 프로세스)가 일부 보호됩니다. 클래스는 최소값 한계 이하일 경우 페이지를 스틸하지 않습니다. 단 모든 활성
클래스가 최소값 한계 이하이고 이 클래스 중 하나가 추가 페이지를 요청하는 경우는 예외입니다. 가장 높은 티어
의 클래스는 최소값 이하일 경우 페이지를 스틸하지 않습니다. 대화식 작업의 클래스에 대해 최소 메모리 한계를
설정하면 메모리가 충분하지 않은 경우에도 연속 활성화 중간에 페이지가 모두 스틸되지 않으므로 응답 시간이
개선됩니다.
주의: 하드 최대값 한계를 사용하는 경우 이를 올바르게 사용되지 않으면 시스템 또는 애플리케이션에 큰
영향을 미칠 수 있습니다. 하드 한계를 설정하면 시스템 자원이 사용되지 않을 수 있기 때문에 대부분의
경우 소프트 최대값 한계를 사용하는 것이 좋습니다. 자원이 필요한 애플리케이션을 더 높은 티어에 넣는
것이 나을 수도 있지만, 하드 최대값 한계를 사용하여 높은 티어의 소비량을 제한함으로써 일부 자원을 낮
은 티어에서 사용할 수 있도록 할 수도 있습니다.
총계 한계는 다음 테이블에 요약된 값과 단위로 한계 파일에 지정될 수 있습니다.
표 9. 워크로드 관리자에 대한 자원 한계
자원 허용 단위 디폴트 단위 최대값 최소값
totalCPU s, m, h, d, w s 230 – 1s 10 s

표 9. 워크로드 관리자에 대한 자원 한계 (계속)
자원 허용 단위 디폴트 단위 최대값 최소값
totalDiskIO KB, MB, TB, PB, EB KB (263– 1) * 1MB
512/1024KB
totalConnectTime s, m, h, d, w s 263 – 1s 5m
totalProcesses – – 263 – 1 2
totalThreads – – 263 – 1 2
totalLogins – – 263 –1 1
참고: 단위 지정자는 대소문자를 구분하지 않습니다. s = 초, m = 분, h = 시간, d = 일, w = 주, KB = 킬로바이트,

MB = 메가바이트 등을 나타냅니다.
다음은 한계 스탠자에 대한 예제입니다.
BadUserClass:
totalCPU = 1m
totalConnectTime = 1h
총계 한계는 위 표에 표시된 값을 사용하여 지정할 수 있습니다. 단, 다음과 같은 제한사항이 적용됩니다.

• totalThreads의 값(지정된 경우)은 최소한 totalProcesses의 값이어야 합니다.
• totalThreads는 지정되고 totalProcesses는 지정되지 않은 경우 totalProcesses에 대한 한계는 totalThreads
의 값으로 설정됩니다.
총계 한계는 수퍼클래스와 서브클래스 레벨에서 지정할 수 있습니다. 한계를 확인할 때는 서브클래스 한계가 수
퍼클래스 한계보다 먼저 확인됩니다. 두 한계가 모두 지정된 경우에는 둘 중 더 낮은 한계가 적용됩니다. 지정된
서브클래스 한계가 연관된 수퍼클래스 한계보다 크면 구성이 로드될 때 경고가 표시되지만 구성은 로드됩니다.
이는 한계가 절대적(수퍼클래스에 상대적이 아님)이고 하나의 서브클래스가 수퍼클래스에 사용할 수 있는 모든
자원을 사용할 수 있기 때문에 클래스 총계 한계에 중요합니다. 모든 총계 한계의 디폴트 값은 지정되지 않은 경
우 한계가 없음을 의미하는 "-"입니다. 기본적으로 클래스와 프로세스 사용통계 총계 및 규정은 WLM이 실행 중
일 때 활성화됩니다. wlmcntrl 명령의 -T [class|proc] 옵션을 사용하면 사용통계 총계와 규정을 비활성화할
수 있습니다.
워크로드 관리자의 클래스 우선순위

WLM은 각 클래스에 각 자원에 대한 우선순위를 지정하여 자원을 클래스에 할당합니다.
클래스의 우선순위는 동적이며 클래스의 티어, 공유, 제한 및 현재 소비량을 기준으로 합니다. 지정된 시간에 우
선순위가 가장 높은 클래스에는 자원에 대한 우선 액세스가 부여됩니다. 최상위 레벨에서 티어는 클래스 우선순
위의 중첩되지 않는 범위를 표시합니다. 티어 0의 클래스는 하드 최대값 제한을 초과하지 않는 한, 항상 티어 1의
클래스보다 우선순위가 높습니다.
클래스 우선순위를 결정할 때 WLM은 다음 우선순위(최고 - 최저)에 대한 제한조건을 적용합니다.
하드 제한
클래스 소비량이 자원의 하드 최대값을 초과하면 클래스에 자원의 최저 우선순위가 지정되고 소비량이 이 제
한 이하로 떨어질 때까지 액세스가 거부됩니다.
티어
하드 제한이 없는 경우 클래스의 우선순위는 티어에 허용되는 최소 및 최대 우선순위로 제한됩니다.
소프트 제한
클래스 소비량이 자원의 소프트 최대값 한계의 최소량 이하이면 클래스에 티어의 최고 우선순위가 지정됩니
다. 클래스 소비량이 소프트 최대값을 초과하면 클래스에 티어의 최저 우선순위가 지정됩니다.
공유
각 자원에 대한 클래스 목표 소비량을 계산하는 데 사용됩니다. 클래스 우선순위는 클래스 소비량이 목표 이
하로 떨어지면 높아지고 목표 이상 올라가면 낮아집니다. 소프트 제한이 우선순위가 더 높으며 클래스의 우
선순위는 소프트 제한에 따라 결정됩니다.
장치 관리 147
공유와 제한 모두 각 클래스와 각 자원에 사용할 수 있지만 각 클래스에 하나씩만 사용할 때 결과에 대한 예측 가
능성이 더 높습니다.
독점 사용 프로세서 자원 세트
XRSET(독점 사용 프로세서 자원 세트)를 통해 관리자는 중요한 작업에 자원이 사용되도록 보장할 수 있습니다.
XRSET는 XRSET에 포함된 모든 CPU의 동작을 변경하는 이름 붙여진 자원 세트입니다. CPU가 배타적 CPU가 되
면 명시적으로 자신에게 지정된 프로그램만 실행합니다.
XRSET 작성
XRSET를 작성하려면 루트 사용자여야 합니다. mkrset 명령을 사용하여 sysxrset 이름 공간에 자원 세트
를 작성하십시오. 예를 들어, mkrset -c 1-3 sysxrset/set1 명령은 CPU 1, 2, 3에 XRSET를 작성합
니다. rs_registername() 서브루틴을 사용하여 XRSET를 작성할 수도 있습니다.
XRSET가 시스템에 정의되었는지 확인
lsrset -v -n sysxrset 명령은 시스템에 정의된 모든 XRSET를 표시합니다. 현재로서는 이를 수행할
프로그래밍 API가 없습니다.
XRSET 삭제
XRSET를 삭제하려면 루트 사용자여야 합니다. rmrset 명령으로 XRSET를 삭제할 수 있습니다.
rs_discardname() 서브루틴을 사용하여 XRSET를 삭제할 수도 있습니다.
시스템 재부팅
시스템을 재부트할 때, 설정되었던 XRSET가 레지스트리에서 제거되어 더 이상 효력을 발휘하지 않게 됩니
다.
XRSET에 대한 작업 지정
여러 가지 방법으로 작업이 독점 사용 프로세서를 사용할 자격이 있음을 표시할 수 있습니다. attachrset
과 execrset 명령을 사용하여 독점 사용 프로세서가 포함된 자원 세트를 지정할 수 있습니다. 독점 사용 프
로세서가 포함된 자원 세트를 WLM 클래스와 연결할 수 있습니다. 이러한 WLM 클래스로 분류된 작업은 자원
세트에 지정된 독점 사용 프로세서를 사용하게 됩니다.
Bindprocessor 및 _system_configuration.ncpus와 함께 XRSET 사용
독점 사용 프로세서에서 작업이 실행되도록 하기 위해 bindprocessor를 사용할 수 없습니다. 자원 세트를
기반으로 한 첨부만 독점 사용 프로세서에서 작업이 실행되도록 할 수 있습니다.
XRSET가 작성될 때, 시스템 구성의 CPU 수(_system_configuration.ncpus 필드)가 변경되지 않습니다. 시
스템에는 이전과 동일한 NCPU가 있습니다.
프로그램이 NCPU에 대한 bindprocessor 시스템 호출을 사용하면, XRSET의 CPU가 EINVAL 오류로 실
패합니다. bindprocessor 명령의 조회 옵션으로 리턴된 모든 ID에 바인드할 수 있습니다. 조회 옵션
(bindprocessor -q)은 배타적 CPU와 연결된 ID를 제외한, 유효한 바인드 ID만 리턴합니다.
예를 들어, 시스템에 온라인 CPU가 10개 있고 이 중 세 개가 XRSET에 있을 경우, 바인드 ID가 0-6인 CPU에
대한 bindprocessor만 성공합니다. 바인드 ID가 7-9인 CPU에 대한 bindprocessor는 EINVAL 오류
를 수신합니다.
동적 CPU 재구성 작업에 XRSET 사용
일반적으로, 동적 CPU 재구성은 독점 사용 프로세서의 영향을 받지 않습니다. 하지만 XRSET를 작성하고 이
들 프로세서에 작업을 지정하면서 CPU가 제거될 수 있습니다. 시스템에 동적으로 추가된 CPU는 일반적인
용도 또는 독점 사용 프로세서로 시스템에 나타날 수 있습니다. CPU가 시스템에 나타날 때 논리적 CPU ID가
포함된 XRSET가 있으면 CPU가 독점 사용으로 나타납니다.
워크로드 관리자의 자원 세트
WLM은 자원 세트(또는 rsets)를 사용하여 제공된 클래스의 프로세스를 시스템의 물리적 자원에 대한 서브세트
로 제한합니다. WLM에서 관리되는 물리적 자원은 메모리와 프로세서입니다. 유효한 자원 세트는 메모리와 최소
한 하나의 프로세서로 구성됩니다.
SMIT를 사용하면 시스템 관리자는 시스템에서 사용 가능한 자원의 서브세트를 포함하는 자원 세트를 정의하고
이름을 지정할 수 있습니다. 그러면 루트 사용자 또는 지정된 수퍼클래스 관리자는 WLM 관리 인터페이스를 통해

자원 세트의 이름을 WLM 클래스의 rset 속성으로 사용할 수 있습니다. 그때부터 이 WLM 클래스에 지정된 모든
프로세스는 자원 세트의 프로세서 중 하나에만 작업이 지정되어 CPU 자원의 워크로드를 효율적으로 분리합니
다.
모든 현재 시스템은 모든 자원 세트가 공유하는 메모리 도메인을 하나만 포함하므로 이 메소드는 실제로 메모리
의 워크로드를 분리하지 않습니다.
워크로드 관리자의 자원 세트 레지스트리

rset 레지스트리 서비스를 사용하면 시스템 관리자는 다른 사용자나 애플리케이션이 사용할 수 있도록 자원 세
트를 정의하고 이름을 지정할 수 있습니다.
이름 충돌을 줄이기 위해 레지스트리는 두 레벨의 이름 지정 규칙을 지원합니다. 자원 세트의 이름은
name_space/rset_name 양식입니다. name_space와 rset_name 둘 모두 각각 길이가 255자일 수 있고, 대소문
자를 구분하고, 대문자와 소문자, 숫자, 밑줄 및 마침표(.)만을 포함할 수 있습니다. sys의 name_space는 운영 체
제에 의해 예약되며 시스템의 자원을 표시하는 rset 정의에 사용됩니다.
rset 정의 이름은 레지스트리 이름 공간 내에서 고유합니다. 기존 rset 정의와 같은 이름을 사용하여 새 rset
정의를 레지스트리에 추가하면 기존 정의가 새 정의로 대체되고 적절한 권한과 특권이 부여됩니다. 루트만이 자
원 세트를 작성, 수정 및 삭제하고, SMIT를 사용하여 인코어 rset 데이터베이스를 갱신할 수 있습니다.
각 rset 정의에는 소유자(사용자 ID) 그룹(그룹 ID) 및 이 그룹과 연관된 액세스 권한이 있습니다. 이러한 정의는
rset 정의가 작성될 때 지정되며 액세스 제어를 위해 존재합니다. 파일의 경우처럼 소유자, 그룹에 대해 읽기
및/또는 쓰기 권한을 부여할 것인지 정의하는 별도의 액세스 권한이 있습니다. 읽기 권한은 rset 정의를 검색할
수 있게 해주고 쓰기 권한은 rset 정의를 수정하거나 제거할 수 있게 해줍니다.
시스템 관리자가 정의한 rset 정의는 /etc/rsets 스탠자 파일에 보관됩니다. 이 파일의 형식은 설명되지 않
고, 사용자는 파일 형식이 수정된 경우 나중에 잠재적인 호환성 문제점을 방지하기 위해 SMIT 인터페이스를 통
해 rset를 조작해야 합니다. WLM 클래스 정의의 경우처럼 rset 정의를 WLM에서 사용하려면 커널 데이터 구
조로 로드해야 합니다.
워크로드 관리자 설정
클래스 정의, 클래스 속성, 공유 및 한계 및 자동 클래스 지정 규칙은 SMIT 또는 WLM 명령행 인터페이스를 사용
하여 입력할 수 있습니다. 이러한 정의와 규칙은 텍스트 편집기를 사용하여 작성하거나 수정할 수도 있는 일반 텍
스트 파일에 보관됩니다.
이러한 파일(WLM 특성 파일이라고 함)은 /etc/wlm의 서브디렉토리에 보관됩니다. 수퍼클래스 및 해당 연관된
서브클래스를 설명하는 파일 세트는 WLM 구성을 정의합니다. WLM Config 구성에 대한 파일은 /etc/wlm/
Config에 있습니다. 이 디렉토리에는 수퍼클래스를 위한 WLM 매개변수의 정의가 포함됩니다. 파일은
description, classes, shares, limits 및 rules로 이름이 붙여집니다. 이 디렉토리는 서브클래스 정의
가 보관된 수퍼클래스의 이름이 있는 서브디렉토리를 포함할 수도 있습니다. 예를 들어, WLM 구성 Config의 수
퍼클래스 Super의 경우 /etc/wlm/Config/Super 디렉토리에는 수퍼클래스 Super의 서브클래스에 대한 특
성 파일이 들어 있습니다. 파일은 description, classes, shares, limits 및 rules로 이름이 붙여집니
다.
WLM 구성이 시스템 관리자에 의해 정의된 후에는 smit wlmmanage 단축 경로 또는 wlmcntrl 명령을 사용
하여 활성 구성이 될 수 있습니다.
특성 파일의 여러 세트를 정의하여 워크로드 관리의 다른 구성을 정의할 수 있습니다. 이러한 구성은 /etc/wlm
의 서브디렉토리에 있습니다. 기호 링크 /etc/wlm/current는 현재 구성 파일이 들어 있는 디렉토리를 가리
킵니다. 이 링크는 WLM이 구성 파일의 지정된 세트로 시작될 때 wlmcntrl 명령에 의해 갱신됩니다.
워크로드 관리자 구성에 대한 애플리케이션 요구사항

구성을 정의하는 첫 번째 단계에서는 시스템의 애플리케이션, 비즈니스의 자원 요구 및 요구사항(예: 중요한 태
스크 및 낮은 우선순위를 지정할 수 있는 태스크)뿐 아니라 사용자 및 계산 요구에 대해 이해해야 합니다. 이 이해
를 기반으로 수퍼클래스를 정의한 다음 서브클래스를 정의합니다.
우선순위 설정은 조직에서 WLM이 사용하는 기능에 종속됩니다. 서버 통합의 경우 애플리케이션, 사용자 및 자원
요구사항에 대해 이미 알고 있을 수도 있고 일부 단계를 생략하거나 단축할 수도 있습니다.
WLM을 사용하면 사용자, 그룹, 애플리케이션, 유형, 태그 또는 이러한 속성의 조합별로 프로세스를 분류할 수 있
습니다. WLM이 클래스의 자원 사용량을 제한하기 때문에 시스템 관리자는 같은 자원 사용량 패턴을 가진 애플리
장치 관리 149
케이션과 사용자를 같은 클래스로 그룹화해야 합니다. 예를 들어, CPU 시간을 거의 사용하지 않는 대화식 작업을
구분할 수 있지만 CPU와 메모리 사용이 많은 일괄처리 유형의 작업으로부터 빠른 응답 시간이 필요합니다. 이는
OLTP 유형의 트래픽을 데이터 마이닝의 강력한 조회(heavy-duty query)와 구분해야 하는 데이터베이스 환경에
도 해당됩니다.
이 단계는 SMIT 또는 명령행 인터페이스를 사용하여 수행됩니다. 처음 몇 번 동안에는 SMIT를 사용하여 수퍼클
래스 정의 및 해당 속성 설정 등과 같은 첫 번째 WLM 구성 작성 단계를 수행하는 것이 좋을 수도 있습니다. 첫 번
째 패스에서 일부 속성을 설정하고 다른 속성은 디폴트 값으로 유지할 수 있습니다. 이는 자원 공유와 제한에도
해당됩니다. 이러한 모든 클래스 특성은 나중에 동적으로 수정할 수 있습니다.
WLM을 수동 모드에서 시작한 후 분류를 확인하고 애플리케이션의 자원 사용량 패턴을 검토할 수 있습니다.
wlmcheck 명령 또는 해당하는 SMIT 메뉴를 사용하여 구성을 검증하십시오. 그런 다음, 새로 정의된 구성에 대
해 WLM을 수동 모드에서 시작하십시오. WLM은 기존의 모든 프로세스(및 해당 위치에서 작성된 모든 프로세스)
를 분류하고 여러 클래스의 CPU, 메모리 및 디스크 입출력 사용량에 대한 컴파일링 통계를 시작합니다. WLM은
이 자원 사용량을 규정하지 않습니다.
ps 명령의 -o 플래그를 사용하여 여러 프로세스가 시스템 관리자가 예상하는 대로 해당 클래스에 분류되는지 확
인하십시오. 일부 프로세스가 예상대로 분류되지 않으면 새 프로세스를 상위와 같은 클래스에 둘 경우 지정 규칙
을 수정하거나 일부 클래스에 대한 상속 비트를 설정하고 WLM을 갱신할 수 있습니다. 이 첫 번째 분류 레벨(수퍼
클래스)에 만족할 때까지 프로세스를 반복할 수 있습니다.
WLM을 수동 모드에서 실행하고 WLM을 수동 모드에서 항상 갱신하면 위험이 적고 오버헤드 조작이 낮아서 정상
적인 시스템 조작을 방해하지 않고 프로덕션 시스템에서 안전하게 수행할 수 있습니다. WLM을 활성화하고 새로
고치려면, 명령행 또는 SMIT에서 호출된 wlmcntrl 명령을 사용하십시오.
wlmstat 명령을 사용하여 WLM을 수동 모드에서 실행하고 통계를 축적하십시오. wlmstat 명령은 클래스별
자원 사용량을 수퍼클래스의 경우 사용 가능한 총 자원의 백분율로 표시하기 위해 주기적인 간격으로 사용될 수
있습니다. 그러면 오랫동안 시스템을 모니터링하여 주 애플리케이션의 자원 사용량을 검토할 수 있습니다.
워크로드 관리자의 티어, 공유 및 제한

WLM을 수동 모드에서 실행하여 축적한 데이터와 비즈니스 목적에 따라 모든 수퍼클래스에 제공된 티어 수와 여
러 클래스에 제공된 각 자원의 공유를 결정하십시오.
일부 클래스의 경우 최소 또는 최대 제한을 정의할 수 있습니다. 자원 할당 목적에 맞게 공유와 티어 수를 조정하
십시오. 공유로만 분석할 수 없는 경우에 대한 제한을 예약하십시오. 서브클래스를 추가할 수도 있습니다.
• 자원 사용량이 낮지만 외부 이벤트에 의해 활성화될 때 빠른 응답 시간이 필요한 응용프로그램에 대한 최소값
제한을 사용하십시오. 메모리가 가득 차게 되는 상황에서 대화식 작업에 발생하는 문제점 중 하나는 비활성 기
간 중에 페이지가 스틸된다는 점입니다. 최소 메모리 제한은 클래스가 티어 0에 있는 경우 대화식 작업의 일부
페이지를 보호하는 데 사용할 수 있습니다.
• 자원을 많이 사용하고 우선순위가 낮은 일부 작업을 포함하려면 최대 제한을 사용하십시오. 다른 이유에서 시
스템 자원을 분할하지 않는 한, 하드 최대값은 주로 메모리와 같은 갱신할 수 없는 자원에 적용됩니다. 그 이유
는 우선순위가 더 높은 클래스에 첫 번째 클래스가 사용하는 페이지가 필요한 경우 데이터를 페이징 공간에 쓰
는 데 걸리는 시간 때문입니다. CPU 사용량의 경우 티어 또는 소프트 최대값을 사용하여 우선순위가 높은 클래
스에 CPU 시간이 즉시 지정되는지 확인하십시오.
서브클래스의 매개변수를 작성하고 조정할 때, 시스템 작동에 만족할 때까지 다른 수퍼클래스에서 사용자와 애
플리케이션에 영향을 미치지 않는 주어진 수퍼클래스의 서브클래스의 WLM만을 갱신할 수 있습니다.
비즈니스의 요구에 따라 기타 구성을 다른 매개변수로 정의할 수도 있습니다. 그렇게 하면 기존 구성을 복사하고
수정하여 시간을 절약할 수 있습니다.
워크로드 관리자 구성 미세 조정
wlmstat 명령을 사용하여 시스템을 모니터하십시오. 또한 WLM에 의해 수행된 제어가 사용자의 목표에 부합하
는지와 일부 애플리케이션에서는 필요한 것보다 많은 자원을 사용하는 반면 자원이 꼭 필요한 다른 애플리케이
션에서는 자원을 사용하지 못하고 있지는 않은지를 확인하십시오. 이와 같은 경우에는 공유를 조정하고 WLM을
갱신하십시오.
공유, 한계 및 티어 수를 모니터링하고 조정할 때 수퍼클래스의 일부 또는 전부에 대한 서브클래스의 관리를 위임
할 것인지 여부를 결정하십시오. 그러면 관리자가 서브클래스 공유, 한계 및 티어 번호를 모니터하고 설정할 수
있습니다.

각 수퍼클래스의 관리자가 각 수퍼클래스의 서브클래스에 대해 이 프로세스를 반복할 수 있습니다. 서브클래스
레벨에서는 수동 모드로 WLM을 실행할 수 없다는 점만 다릅니다. 서브클래스 구성 및 조정 작업은 WLM을 활성
모드로 실행하여 수행해야 합니다. 수퍼클래스의 사용자와 애플리케이션에 영향을 주지 않으려면 서브클래스의
티어 번호, 공유 및 한계를 디폴트 값(공유는 '-'(하이픈), 최소는 0%, 소프트 및 하드 최대는 100%)에서 시작하
면 됩니다. 이렇게 설정하면 WLM이 서브클래스 간의 자원 할당을 제어하지 않습니다.
워크로드 관리자 문제점 해결

현재 구성에 대한 작동이 원하는 작동이 아니면 WLM 구성을 조정해야 합니다.
각 클래스의 소비 값은 wlmstat 명령을 사용하여 모니터링할 수 있습니다. 이 데이터는 구성에 대한 변경을 결
정하기 위해 수집하고 분석할 수 있습니다. 구성을 갱신한 후에는 wlmcntrl -u 명령을 사용하여 활성 WLM 구
성을 갱신하십시오.
다음 지침은 구성의 변경 방법을 결정하는 데 도움이 됩니다.
• 티어의 활성 공유 수가 시간이 지나면서 크게 달라지는 경우 활성 공유 수와는 별개인 목표 소비량을 포함하기
위해 클래스에 자원에 대한 공유를 제공할 수 없습니다. 이 기술은 자원에 대한 높은 우선순위 액세스가 필요한
중요한 클래스에 유용합니다.
• 자원의 특정량에 액세스하려면 최소 제한을 지정하십시오. 이 기술은 많은 자원을 사용하는 것은 아니지만 외
부 이벤트에 빨리 응답해야 하는 대화식 작업에 유용합니다.
• 자원에 대한 액세스를 제한하고 공유를 통해 충분히 제어되지 않는 경우 최대 제한을 지정하십시오. 대부분, 소
프트 최대값 한계로 충분하지만 엄격한 적용에는 하드 최대값을 사용할 수 있습니다. 하드 최대값 한계로 인해
시스템 자원이 소모될 수 있고 메모리 규정에 사용될 때 페이징 활동이 증가할 수 있으므로 하드 제한을 규정하
려면 다른 클래스의 최소 한계를 설정해야 합니다.
• 덜 중요한 작업이 더 중요한 작업을 방해하면 덜 중요한 작업을 낮은 티어에 넣으십시오. 이 기술은 덜 중요한
작업의 우선순위를 낮추고 더 중요한 작업이 실행되는 동안 사용 가능한 자원과 경합할 수 없도록 합니다.
• 클래스가 자원의 목표 소비량에 도달할 수 없으면 이 조건의 원인이 다른 자원의 경합 때문인지 확인하십시오.
만일 그렇다면 경합 하의 자원에 대한 클래스 할당을 변경하십시오.
• 클래스 내의 프로세스가 작동 또는 자원 소비량과 크게 다르면 추가 클래스를 작성하여 더 자세히 제어하십시
오. 중요한 각 애플리케이션에 대해 별도의 클래스를 작성할 수도 있습니다.
• 분석 결과, 하나의 클래스에 필요한 자원이 다른 클래스의 소비량에 종속적인 것으로 나타나면 그에 따라 자원
을 재할당하십시오. 예를 들어, ClassZ에 필요한 자원의 양이 ClassA가 처리할 수 있는 작업 요청 수에 종속적
이면 ClassA는 충분한 자원에 액세스하여 ClassZ에 필요한 것을 제공해야 합니다.
• 하나 이상의 애플리케이션이 적절히 수행할 수 있는 자원을 수신하지 못하면 시스템의 워크로드를 줄이는 것이
유일한 옵션입니다.
참고: 수퍼클래스에 대해 adminuser를 정의하여 WLM 관리자에게 필요한 작업의 양을 줄일 수 있습니다. 최상위
구성을 테스트하고 조정한 후에는 특정 요구에 맞게 수퍼클래스 adminuser가 계속해서 변경(서브클래스 작성
및 구성 포함)할 수 있습니다.
워크로드 관리자 API

애플리케이션은 /usr/lib/libwlm.a 라이브러리에 있는 루틴 세트 WLM API를 사용하여 WLM 관리자가
WLM 명령행 인터페이스를 사용하여 수행하는 모든 태스크를 수행할 수 있습니다.
다음이 포함됩니다.
• 클래스 작성, 수정 또는 삭제
• 클래스 속성, 자원 공유 및 제한 변경
• 클래스 제거
• 클래스에 수동으로 프로세스 지정
• WLM 통계 검색
API는 애플리케이션이 태그라는 애플리케이션 정의 분류 속성을 설정하도록 허용합니다. 시스템 관리자가 애플
리케이션 사용자 문서를 통해 제공한 값 세트를 사용하여 이 태그를 설정하면 샘플 애플리케이션의 여러 인스턴
스를 구별할 수 있습니다. 그러므로 다른 클래스를 다른 자원 인타이틀먼트으로 분류할 수 있습니다.
장치 관리 151
또한 wlm_set_tag 루틴은 애플리케이션이 애플리케이션 태그를 설정하고 이 태그가 fork 또는 exec에서 하위
프로세스에 의해 상속되어야 하는지 여부를 지정할 수 있도록 해줍니다. 스레드 또한 wlm_set_thread 태그와
함께 애플리케이션 태그에 지정될 수 있습니다. 스레드의 애플리케이션 태그는 fork, exec 또는
pthread_create 서브루틴에서 상속될 수 있습니다. 라이브러리는 다중 스레드 32비트 또는 64비트 애플리케이
션을 지원합니다.
애플리케이션 태그
애플리케이션 태그는 문자열이고 프로세스나 스레드의 자동 분류를 위해 분류 기준 중 하나로 사용됩니다
(rules 파일 사용). 이 태그는 기본적으로 시스템 정의 기준(예: user, group, application 및 type)뿐 아니라 애
플리케이션 정의 분류 기준도 제공합니다.
애플리케이션 프로세스 또는 스레드는 태그를 설정할 때 현재 활성 WLM 구성에 대한 수퍼클래스와 서브클래스
규칙을 사용하여 즉시 재분류됩니다. 그러면 WLM은 새 태그를 포함하여 모든 프로세스 속성을 사용하여 일치를
찾는 지정 규칙을 검토합니다.
이 태그가 적용되려면 하나 이상의 지정 규칙에 표시되어야 합니다. 각 애플리케이션별 여러 태그의 형식과 사용
은 애플리케이션의 관리 문서에 명확히 지정되어야 하며 WLM 관리자가 지정 규칙에서 태그의 여러 값을 사용하
여 같은 애플리케이션의 다른 인스턴스를 구별할 수 있도록 WLM 관리자에게 잘 알려져야 합니다.
다른 사용자가 해당 프로세스를 분류하는 데 사용할 애플리케이션 프로세스의 특성 세트에 관해 다른 요구사항
이 있을 수 있으므로 애플리케이션이 태그 빌드에 사용할 수 있는 실행시간 속성 또는 구성 세트를 제공하는 것이
좋습니다. 애플리케이션 관리자는 애플리케이션에 이 태그의 형식을 지정할 수 있습니다. WLM 태그의 형식을 지
정하기 위해 태그와 구문에 사용할 수 있는 속성은 애플리케이션마다 다르며 애플리케이션 공급자가 제공합니
다.
예를 들어, 데이터베이스 서버의 인스턴스는 지정된 사용자가 연결되는 TCP 포트(port_num)를 통해 이 인스턴
스가 작동 중인 데이터베이스(db_name)를 판별할 수 있습니다. 시스템 관리자의 우선순위는 다음과 같습니다.
• 다른 데이터베이스에 액세스하는 프로세스에 대해 다른 클래스를 작성하여 각 클래스에 다른 자원 인타이틀먼
트 지정
• 원격 요청을 사용하는 프로세스를 다른 오리진과 구분하고 포트 번호를 분류 속성으로 사용
• 각 데이터베이스에 하나의 수퍼클래스 작성 및 각 수퍼클래스의 포트 번호에 서브클래스 작성
이러한 여러 요구에 맞추는 한 가지 방법은 태그의 내용과 형식을 지정하는 것입니다. 이 예제에서는 WLM_TAG=
$db_name 또는 WLM_TAG=$db_name_$port_num과 같은 실행시간 매개변수 또는 구성 파일의 애플리케이
션으로 태그를 전달할 수 있는 것으로 가정합니다.
해당 태그를 설정할 때 애플리케이션은 이 태그가 애플리케이션의 특정 인스턴스가 작성한 모든 프로세스가 동
일한 클래스에 분류될 수 있도록 하위에 의해 상속되는지 여부를 지정할 수 있습니다. 태그 상속의 설정은 애플리
케이션 태그를 가장 일반적으로 사용하는 방법입니다.
다음 예제에서는 애플리케이션 태그의 사용 방법을 설명합니다. 이 예제에서 데이터베이스의 태그는 데이터베이
스 이름과 같습니다. 그러므로 두 개의 다른 데이터베이스에서 작동하는 서버의 두 인스턴스는 인스턴스 db1과
db2에 대해 다른 두 개의 태그를 설정합니다.
시스템 관리자는 두 개의 다른 클래스(dbserv1 및 dbserv2)를 작성하고 태그를 사용하여 이러한 클래스에 두
개의 데이터베이스 서버(태그 상속이 사용되는 경우 모든 하위)를 분류할 수 있습니다. 그러면 특정 비즈니스 목
적에 따라 각 클래스에 다른 자원 인타이틀먼트를 지정할 수 있습니다.
해당 지정 규칙은 다음과 같이 표시될 수 있습니다.
* class resvd user group application type tag
*
dbserv1 - - dbadm /usr/sbin/dbserv - db1
dbserv2 - - dbadm /usr/sbin/dbserv - db2
API(Application Programming Interface) 유형

워크로드 관리자(WLM) API 유형은 다음과 같습니다.
클래스 관리 API
WLM API는 애플리케이션에 다음과 같은 기능을 제공합니다.
• 지정된 WLM 구성의 기존 클래스에 대한 이름 및 특성 조회(wlm_read_classes)

• 지정된 WLM 구성에 대해 새 클래스 작성, 클래스의 여러 속성(예: 티어 및 상속) 값 정의, WLM이 관리하는
자원(예: CPU, 실제 메모리 및 블록 입출력)에 대한 공유 및 제한 정의(wlm_create_class)
• 클래스 속성, 자원 공유 및 제한을 포함하여 지정된 WLM 구성의 기존 클래스에 대한 특성 변경
(wlm_change_class)
• 지정된 구성의 기존 클래스 삭제(wlm_delete_class)
변경사항은 지정된 WLM 구성의 특성 파일에만 적용됩니다. 빈 문자열을 구성 이름으로 지정하여 활성 구성
상태가 즉시 갱신되도록 인코어 클래스에만 변경사항을 적용할 수도 있습니다.
API 호출은 호출자가 다음과 같이 SMIT 인터페이스 또는 명령행에 필요한 것과 동일한 레벨의 권한이 필요
합니다.
• 모든 사용자가 클래스 이름과 특성을 읽을 수 있음
• 루트 사용자만 수퍼클래스를 작성, 수정 또는 삭제할 수 있음
• 루트 사용자 또는 지정된 수퍼클래스 시스템 관리자(수퍼클래스 속성 adminuser 또는 admingroup)만
지정된 수퍼클래스의 서브클래스를 작성, 수정 또는 삭제할 수 있음
WLM 관리가 수행되면 WLM 관리자의 명령행과 관리 도구 및 애플리케이션의 API를 통해 일부 주의사항이
적용되어야 합니다. 두 인터페이스 모두 수퍼클래스와 서브클래스 이름에 대해 같은 이름 공간을 공유하며
총 수퍼클래스 수와 서브클래스 수를 공유합니다.
또한 API가 인코어 WLM 데이터를 직접 수정(예: 새 클래스 작성)하면 WLM 관리자는 관리자가 작성하지 않
은 클래스가 wlmstat 명령과 같은 명령의 출력에 표시될 때까지 이를 인식하지 못합니다. 시스템 관리자가
WLM을 갱신할 때 이 API를 사용하는 애플리케이션과의 충돌을 피하기 위해 WLM 특성 파일에 정의되지 않
은 API를 통해 작성된 클래스가 자동으로 인코어 데이터에서 제거됩니다. 이들은 wlm_delete_class 루
틴 또는 rmclass 명령의 호출(직접 호출되거나 시스템 관리자가 SMIT를 통해 호출)을 통해 명시적으로 제
거될 때까지 유효합니다.
또한 WLM API는 애플리케이션에 다음과 같은 기능을 제공합니다.
• wlm_set 함수를 사용하여 WLM의 조작 모드 조회 또는 변경
• WLM의 현재 상태 조회
• WLM 정지
• 활성 모드와 수동 모드 토글
• rset 바인딩 켬 및 끔
• wlm_load 루틴을 사용하여 현재 또는 대체 구성으로 WLM 시작 또는 갱신
• wlm_assign 루틴을 사용하여 프로세스 또는 프로세스 그룹을 클래스에 지정
API에는 해당 wlmcntrl과 wlmassign 명령과 같은 레벨의 특권이 필요합니다.
• 모든 사용자가 WLM의 상태를 조회할 수 있음
• 루트 사용자만 WLM의 조작 모드를 변경할 수 있음
• 루트 사용자만 전체 구성을 갱신할 수 있음
• 루트 또는 권한이 부여된 수퍼클래스 관리자(adminuser 또는 admingroup)가 지정된 수퍼클래스의 서
브클래스에 대해 WLM을 갱신할 수 있음
• 루트, 권한이 부여된 사용자(authuser 또는 authgroup) 또는 권한이 부여된 수퍼클래스 관리자
(adminuser 또는 admingroup)가 수퍼클래스 또는 서브클래스에 프로세스를 지정할 수 있음.
WLM 통계 API
WLM API 루틴과 wlm_get_bio_stats는 wlmstat 명령이 표시하는 WLM 통계에 대한 애플리케이션 액
세스를 제공합니다.
WLM 분류 API
wlm_check 루틴을 사용하여 사용자는 지정된 WLM 구성에 대한 클래스 정의와 지정 규칙을 확인할 수 있습
니다. API 루틴 wlm_classify를 사용하여 애플리케이션은 지정된 속성 세트가 있는 프로세스가 분류되는
클래스를 결정할 수 있습니다.
장치 관리 153
2진 호환성
나중에 데이터 구조에 대해 변경할 경우 2진 호환성을 제공하기 위해 각 API 호출이 버전 번호를 매개변수로 전
달합니다.
그러면 라이브러리는 애플리케이션이 빌드한 데이터 구조의 버전을 판별할 수 있습니다.
워크로드 관리자 분류, 규칙 및 제한에 대한 예제

프로세스를 분류하는 데에는 몇 가지 방법이 있으며 이 방법은 모두 동시에 작동합니다.
가장 엄격한 하향식 첫 번째 일치 알고리즘은 구성을 최대한 유연하게 하기 위해 사용됩니다. 프로세스 그룹화는
특정 이름을 가진 프로그램에 대한 특수한 경우의 사용자별, 특정 사용자에 대한 특수한 경우의 경로 이름별 또는
기타 배열별로 구성할 수 있습니다.
워크로드 관리자 지정 규칙에 대한 예제

이 예제에서는 구성 Config(/etc/wlm/Config/rules 파일)에 대한 최상위 rules 파일을 설명합니다.
* This file contains the rules used by WLM to

* assign a process to a superclass
*
db1 - - - /usr/bin/oracle* _DB1
db2 - - - /usr/bin/oracle* _DB2
devlt - - dev - - -
VPs - bob,ted - - - -
acctg - - acct* - - -
System - root - - - -
Default - - - - - -
다음은 /etc/wlm/Config/devlt/rules 파일의 devlt 수퍼클래스에 대한 rules 파일의 예제입니다.
* This file contains the rules used by WLM to

* assign a process to a subclass of the
* superclass devlt
*
hackers - jim,liz - - - -
hogs - - - - 64bit+plock -
editors - !sue - /bin/vi,/bin/emacs - -
build - - - /bin/make,/bin/cc - -
Default - - - - - -
참고: 별표(*)는 rules 파일에 사용되는 주석 문자입니다.

다음은 이 규칙 파일 사용에 대한 예제입니다. 다음 예제에서는 설명한 수퍼클래스와 서브클래스에 예로 설정된
상속 속성이 없는 것으로 가정합니다. 상속을 사용할 수 있는 경우 새 프로세스는 상위 프로세스로부터 수퍼클래
스 또는 서브클래스를 상속받습니다.
• acct3 그룹의 사용자 joe가 /bin/vi를 실행하면 프로세스가 수퍼클래스 acctg에 배치됩니다.
• dev 그룹의 사용자 sue가 /bin/emacs를 실행하면 프로세스가 수퍼클래스 devlt(그룹 ID 일치)에 배치되지
만 사용자 sue가 해당 클래스에서 제외되었기 때문에 편집기 서브클래스로 분류되지 않습니다. 프로세스는 기
본적으로 devlt로 이동합니다.
• 데이터베이스 관리자가 사용자 ID oracle과 그룹 ID dbm을 사용하여 /usr/sbin/oracle을 시작하여 DB1
데이터베이스를 서비스하면 프로세스가 Default 수퍼클래스로 분류됩니다. 프로세스가 태그를 _DB1으로 설
정할 경우만 수퍼클래스 db1에 지정됩니다.
공유 및 제한이 있는 워크로드 관리자 클래스에 대한 예제

이 예제에서는 클래스 A, B, C 및 D에 각각 3, 2, 1 및 1의 공유가 있는 것으로 간주합니다.
클래스 A, C 및 D가 활성화되면 계산된 목표는 다음과 같습니다.
target(A) = 3/5 = 60%

target(C) = 1/5 = 20%
target(D) = 1/5 = 20%
테스트 도중 클래스 A의 애플리케이션이 자원의 50%를 사용할 수 있을 때 적절히 수행되면 자원의 나머지 50%
를 다른 클래스에서 사용할 수 있게 하는 것이 좋습니다. 클래스 A에 이 자원의 소프트 최대값의 50%를 지정하면

됩니다. 현재 계산된 목표 60%가 이 제한을 초과하면 소프트 최대값 아래로 조정됩니다. 이러한 경우 사용 가능
한 자원량에서 클래스 A의 목표 또는 실제 소비량(더 낮은 것으로 함)을 뺍니다. 이 클래스의 목표는 클래스 한계
(및 공유는 제외)로 국한되므로 클래스에 대한 공유도 활성 공유 수에서 뺍니다. 클래스 A의 현재 소비량이 48%
이면 목표는 다음과 같습니다.
target(A) = 3/5 = 60%, softmax = 50, = 50%

target(C) = 1/2 * (100 - 48) = 26%
target(D) = 1/2 * (100 - 48) = 26%
잠시 후 모든 클래스가 활성화되고 목표가 자동으로 다시 조정됩니다.
target(A) = 3/7 = 42%

target(B) = 2/7 = 28%
target(C) = 1/7 = 14%
target(D) = 1/7 = 14%
CPU 제한이 있는 워크로드 관리자 클래스에 대한 예제

이 예제에서는 각 클래스가 제공된 모든 CPU를 사용할 수 있는 것으로 가정하고 CPU 할당을 설명합니다.
A와 B의 두 클래스는 같은 티어에 있습니다. A의 CPU 제한은 [30% - 100%]입니다. B의 CPU 제한은 [20% -
100%]입니다. 두 클래스 모두 실행 중이고 충분한 CPU를 사용할 경우 WLM은 먼저 두 클래스 모두 최소 백분율
(평균 수 초)에 이르렀는지 확인합니다. 그런 다음, WLM은 나머지 CPU 순환을 CPU 목표 공유 값에 따라 분배합
니다.
A와 B의 CPU 목표 공유가 각각 60%와 40%이면 A와 B의 CPU 사용량은 각각 60%와 40%에서 안정됩니다.
세 번째 클래스 C가 추가됩니다. 이 클래스는 CPU 바운드 작업의 그룹으로, 사용 가능한 CPU의 절반(그 이상) 정
도에서 실행됩니다. 클래스 C의 제한은 [20% - 100%]이고 CPU 목표 공유는 100%입니다. C가 A 및 B와 같은
티어에 있으면 C가 시작될 때 A와 B의 CPU 할당은 크게 감소하고 세 클래스는 각각 30%, 20% 및 50%에서 안
정화됩니다. 이 경우 목표는 A와 B의 최소가 되기도 합니다.
시스템 관리자는 우선순위가 더 높은 다른 작업이 실행될 때에도 일괄처리 작업에 CPU의 50%가 사용되지 않도
록 할 수 있습니다. 이전 예제와 같은 상황에서 C는 낮은 우선순위 티어에 놓입니다. 그러면 C는 A와 B가 자신의
요구를 수신한 후 남아 있는 CPU를 수신합니다. 위의 예제에서 C는 A와 B가 각각 CPU의 100%를 사용할 수 있
으므로 CPU 시간을 수신하지 않습니다. 그러나 대부분의 경우 우선순위가 높은 티어에 있는 A와 B는 항상 CPU
를 전부 사용하지 않는 대화식 또는 트랜잭션 지향 작업으로 구성됩니다. C는 같거나 더 낮은 티어의 다른 클래스
와 경합하는 CPU의 일부 공유를 수신합니다.
메모리 제한이 있는 워크로드 관리자 클래스에 대한 예제

이 예제에서는 메모리 목표가 다른 프로세스 그룹에 대한 메모리 할당을 설명합니다.
세 그룹의 프로세스, 즉 사용될 때마다 실행해야 하는 대화식 프로세스 그룹(PEOPLE), 항상 백그라운드에서 실
행되는 일괄처리 작업(BATCH1), 밤마다 실행되는 중요한 두 번째 일괄처리 작업(BATCH0)이 실행되어야 합니
다.
PEOPLE의 지정된 최소 메모리는 20%이고 목표 메모리는 50 공유이고 클래스 티어 값은 1입니다. 최소값 제한
20%는 사용자가 키보드를 누를 때 이 클래스의 데스크탑 애플리케이션이 매우 빨리 재개되도록 합니다.
BATCH1의 최소 메모리는 50%이고 목표 메모리는 50 공유이고 티어 값은 3입니다.
BATCH0의 최소 메모리는 80%이고 목표 메모리는 50 공유이고 티어 값은 2입니다.
클래스 PEOPLE과 BATCH1의 총 최소 메모리 제한은 70입니다. 정상적인 조작(BATCH0가 실행되지 않는 경우)
에서 이러한 두 클래스는 모든 예약 메모리를 가져올 수 있습니다. 클래스는 다른 티어에 있어도 시스템에 남아
있는 메모리를 등분하여 공유합니다. BATCH0가 자정에 시작되면 총 최소 메모리는 150이 됩니다. WLM은 상위
티어의 프로세스가 종료될 때까지 최저 티어에 대한 최소 요구사항을 무시합니다. BATCH0는 BATCH1 50% 예
약에서 메모리를 가져오지만 PEOPLE 20% 예약에서는 가져오지 않습니다. BATCH0가 완료되면 티어 3 프로세
스의 메모리 예약이 다시 제공되고 시스템은 정상적인 메모리 밸런스를 회복합니다.
워크로드 관리자 명령
WLM은 시스템 관리자가 다양한 기능을 수행할 수 있게 해주는 명령을 제공합니다.
다음이 포함됩니다.
장치 관리 155
• mkclass, chclass 및 rmclass 명령을 사용하여 수퍼클래스 및 서브클래스를 작성, 수정 및 삭제합니다. 이
러한 명령은 파일의 classes, shares 및 limits를 갱신합니다.
• wlmcntrl 명령을 사용하여 WLM을 시작, 정지 및 갱신합니다.
• wlmcheck 명령을 사용하여 WLM 특성 파일에서 지정된 구성 확인 및 속성 세트가 있는 프로세스가 지정된 클
래스(수퍼클래스 및 서브클래스)를 판별합니다.
• wlmstat(ASCII) 명령을 사용하여 클래스별 자원 사용량을 모니터링합니다. 대부분의 성능 분석 도구(예:
svmon 및 topas 명령으로 시작됨)에는 새 명령행 옵션을 사용하여 WLM 클래스를 고려하고 클래스 및 티어
별 통계를 제공하는 확장자가 있습니다.
• ps 명령의 플래그를 사용하여 사용자는 프로세스와 해당 애플리케이션 태그가 있는 클래스를 표시할 수 있습
니다. 또한 사용자는 ps 명령을 사용하여 지정된 수퍼클래스 또는 서브클래스에 속한 모든 프로세스를 나열할
수 있습니다.
• 지정 규칙을 관리할 명령행 인터페이스는 없습니다. SMIT 관리 도구 또는 텍스트 편집기를 사용해야 합니다.
장치 노드
장치는 노드라고 하는 클러스터로 구성됩니다. 각 노드는 장치들로 구성된 논리적 서브시스템입니다. 노드에서
는 낮은 레벨 장치가 상위 레벨 장치에 하위-상위 관계로 종속되어 있습니다.
예를 들어, 시스템 노드는 모든 노드 중 최상위 노드이며 시스템에 있는 모든 물리적 장치로 이루어집니다. 시스
템 장치가 이 노드의 최상위 장치가 되고 이 아래에는 상위 레벨 시스템 장치에 종속된 버스와 어댑터가 있습니
다. 이 계층의 맨 아래에는 다른 어떤 장치도 연결되어 있지 않은 장치가 놓입니다. 이들 장치는 계층에서 자신보
다 상위에 있는 모든 장치에 종속됩니다.
시작 시, 이러한 상위-하위 종속관계를 기준으로 노드를 구성하는 모든 장치가 구성됩니다. 맨 위에서부터 아래
쪽으로 장치가 구성되며 상위 레벨 장치에 종속된 장치는 상위 레벨 장치가 모두 구성되기 전까지는 구성되지 않
습니다.
AIX 운영 체제는 다중 경로 입출력(MPIO) 기능을 지원합니다. 장치에 MPIO 호환 장치 드라이버가 있으면 이 계
층 내에서 두 개 이상의 상위를 가질 수 있습니다. 따라서 장치와 지정한 시스템 또는 시스템 내의 논리적 파티션
간에 여러 개의 동시 통신 경로가 만들어질 수 있습니다.
장치 클래스
장치를 관리하려면 운영 체제에서 어떤 장치 연결을 허용하는가를 파악해야 합니다. 운영 체제는 계층적 구조의
세 그룹으로 장치를 분류합니다.
이 세 그룹은 다음과 같습니다.
• 기능 클래스
• 기능 서브클래스
• 장치 유형
기능 클래스는 동일한 기능을 수행하는 장치들로 구성됩니다. 예를 들어, 프린터는 기능 클래스로 구성됩니다. 기
능 클래스는 장치들이 지닌 유사함을 기준으로 서브클래스로 그룹화됩니다. 직렬 인터페이스를 사용하는 프린터
와 병렬 인터페이스를 사용하는 프린터를 예로 들 수 있습니다. 이 경우, 직렬 프린터가 하나의 서브클래스가 되
고 병렬 프린터가 또 다른 하나의 서브클래스가 됩니다. 장치 유형은 장치 모델과 제조업체에 따라 분류됩니다.
장치 클래스는 운영 체제에서 인식할 수 있는 유효한 상위-하위 연결 관계를 정의합니다. 이 계층은 각각의 가능
한 하위 연결 위치에 연결될 수 있는 서브클래스를 정의합니다. 예를 들어, RS-232 8-포트 어댑터는 RS-232 서
브클래스에 속하는 장치만 이 어댑터의 8개 포트에 연결될 수 있음을 지정합니다.
장치 클래스와 해당 계층적 종속 관계는 오브젝트 데이터 관리자(ODM) 장치 구성 데이터베이스에 유지됩니다.
장치 구성 데이터베이스 및 장치 관리
장치 정보는 장치 구성 데이터베이스를 구성하는 사전 정의된 데이터베이스 또는 사용자 조정된 데이터베이스에
포함됩니다.
사전 정의된 데이터베이스에는 시스템에서 지원하는 모든 장치에 대한 구성 데이터가 포함됩니다. 계층적 장치
클래스 정보가 바로 이 데이터베이스에 포함됩니다. 사용자 조정된 데이터베이스에는 시스템에 현재 정의되고

구성된 모든 장치에 대한 구성 데이터가 포함됩니다. 현재 사용자 시스템에 연결되어 있는 각 장치에 대한 레코드
가 보관됩니다.
구성 관리자는 시스템을 시작하고 실행하는 동안 시스템의 장치를 자동으로 구성하는 프로그램입니다. 구성 관
리자는 사전 정의된 데이터베이스 및 사용자 조정된 데이터베이스의 정보를 사용하여 장치를 자동으로 구성하며
이후에 사용자 조정된 데이터베이스를 갱신합니다.
다중 경로 입출력 기능은 이 기능이 발견된 경로에 상관없이, 각 MPIO-가능한 장치를 식별하기 위해 고유 장치
ID(UDID)를 사용합니다. UDID는 장치 구성 데이터베이스에 저장됩니다. 장치가 발견되면, 이 장치가 새로운 장
치인지 또는 기존 장치에 대한 또 다른 경로인지 여부를 결정하기 위해 이 데이터베이스에 있는 장치 UDID가 확
인됩니다. 하나의 장치에 대해 다중 경로가 발견되면 장치 드라이버 또는 경로 제어 관리자 커널 확장이 특정 요
청에 사용할 경로를 결정합니다.
SMIT 또는 운영 체제 명령을 사용하여 장치 삭제, 추가 또는 구성 등과 같은 장치 관리 태스크를 수행할 수 있습
니다.
장치 상태
시스템에 연결된 장치의 상태는 네 가지입니다.
시스템에 연결된 장치의 상태는 다음 네 가지 중 하나입니다.
항목 설명
미정의 시스템에서 장치를 인식하지 못합니다.
정의 구체적인 장치 정보가 사용자 조정된 데이터베이스에 기록되지만 시스템에서 장치를 사용할
수 없습니다.
사용 가능함 정의된 장치가 운영 체제에 연결되거나 구성됩니다.
정지 장치를 사용할 수 없지만 장치 드라이버에서는 장치를 인식합니다.
tty 장치와 프린터가 동일한 tty 커넥터를 번갈아 사용할 경우, tty 장치와 프린터 모두 장치 구성 데이터베이스의
동일한 상위 및 포트에 정의됩니다. 이들 장치는 한 번에 하나씩만 구성될 수 있습니다. tty 커넥터가 구성된 경우,
프린터가 다시 구성될 때까지 프린터 고유의 설정 정보가 유지됩니다. 장치가 제거되지는 않습니다. 장치는 정의
상태로 유지됩니다. 정의 상태로 장치를 유지하면 현재 사용되지 않는 장치가 처음 사용 가능 상태가 되기 전에
또는 시스템에서 임시로 제거되어 있는 동안 장치에 대한 조정된 정보가 유지됩니다.
장치의 장치 드라이버가 있을 경우, 장치 드라이버를 통해 장치를 사용 가능하게 만들 수 있습니다.
TCP/IP 의사 장치와 같은 일부 장치는 정지 상태에 있어야 합니다.
장치 위치 코드
위치 코드는 CPU 드로어나 시스템 장치가 어댑터, 신호 케이블 및 비동기 분배 상자(있는 경우)를 경유하여 장치
나 워크스테이션으로 가는 경로입니다. 이 코드를 통해서도 물리적 장치를 식별할 수 있습니다.
위치 코드는 장치 유형에 따라 최대 4개의 정보 필드로 구성됩니다. 이들 필드는 드로어, 슬롯, 커넥터 및 포트를
나타냅니다. 각 필드는 두 개의 문자로 구성됩니다.
드로어의 위치 필드는 드로어 필드로만 구성되며 두 문자로 된 단순한 코드입니다. 어댑터의 위치 코드는 드로어
와 슬롯 필드로 구성되며 AA-BB 형식입니다. 여기서 AA는 드로어 위치에 해당하고 BB는 어댑터가 포함된 버스
와 슬롯을 나타냅니다. 이와 다른 장치의 위치 코드 형식은 AA-BB-CC 또는 AA-BB-CC-DD입니다. 여기서 AA-
BB는 장치가 연결된 어댑터의 위치 코드이고 CC는 장치가 연결된 어댑터의 커넥터에 해당하며 DD는 포트 번호
또는 SCSI 장치 주소에 해당합니다.
어댑터 위치 코드
어댑터 위치 코드는 AA-BB 형식의 두 자리 숫자 쌍으로 이루어집니다. AA는 어댑터가 포함된 드로어의 위치 코
드를 식별하고 BB는 입출력 버스와 카드가 포함된 슬롯을 식별합니다.
AA 필드의 값이 00이면 시스템 유형에 따라 어댑터가 CPU 드로어 또는 시스템 장치에 있음을 의미합니다. AA
필드의 값이 이외의 값이면 카드가 입출력 확장 드로어에 있음을 나타냅니다. 이 경우, AA 값은 비동기 확장 어댑
터가 포함된 CPU 드로어의 입출력 버스와 슬롯 번호를 식별합니다. 첫 번째 숫자는 표준 입출력 버스에 해당하는
장치 관리 157
0과 선택적 입출력 버스에 해당하는 1을 사용하여 입출력 버스를 식별합니다. 두 번째 숫자는 표시된 입출력 버
스에 있는 슬롯 번호를 식별합니다.
BB 필드의 첫 번째 숫자는 어댑터 카드가 포함된 입출력 장치를 식별합니다. 카드가 CPU 드로어나 시스템 장치
에 있을 경우, 이 숫자는 표준 입출력 버스일 경우 0이고 선택적 입출력 버스일 경우 1입니다. 카드가 입출력 확장
드로어에 있으면 이 숫자가 0입니다. 두 번째 숫자는 표시된 입출력 버스에서 카드가 포함된 슬롯 번호를 식별합
니다.
위치 코드 00-00은 표준 입출력 장치를 식별하는 데 사용됩니다.
예를 들어, 다음과 같습니다.
항목 설명
00-05 표준 입출력 장치의 슬롯 5에 있으며, 시스템 유형에 따라 CPU 드로어 또는 시스템 장치에 있는 어댑
터 카드를 식별합니다.
00-12 선택적 입출력 버스의 슬롯 2에 있으며 CPU 드로어에 있는 어댑터를 식별합니다.
18-05 입출력 확장 드로어의 슬롯 5에 있는 어댑터 카드를 식별합니다. 드로어는 CPU 드로어에서 선택적 입
출력 버스의 슬롯 8에 있는 비동기 확장 어댑터에 연결됩니다.
프린터 및 플로터 위치 코드
위치 코드 00-00-S1-00 또는 00-00-S2-00은 프린터, 플로터 또는 tty 장치가 표준 입출력 장치 직렬 포트
s1 또는 s2에 연결되어 있음을 나타냅니다. 위치 코드 00-00-0P-00은 병렬 프린터가 표준 입출력 장치 병렬
포트에 연결되어 있음을 나타냅니다.
이외 다른 위치 코드는 프린터, 플로터 또는 tty 장치가 표준 입출력 장치 이외의 어댑터 카드에 연결되어 있음을
나타냅니다. 이러한 프린터, 플로터 및 tty 장치의 위치 코드는 AA-BB-CC-DD 형식입니다. 여기서 AA-BB는 제어
어댑터의 위치 코드를 나타냅니다.
항 설명
목
AA AA 필드의 값이 00이면 시스템 유형에 따라 어댑터 카드가 CPU 드로어 또는 시스템 장치에 있음을 나타
냅니다. AA 필드의 값이 이외의 다른 값이면 카드가 입출력 확장 드로어 안에 있음을 나타냅니다. 이 경우,
첫 번째 숫자는 입출력 버스를 식별하고 두 번째 숫자는 CPU 드로어에서 입출력 확장 드로어가 연결된 비
동기 확장 어댑터가 포함된 버스의 슬롯 번호를 식별합니다.
BB BB 필드의 첫 번째 숫자는 어댑터 카드가 포함된 입출력 버스를 식별합니다. 카드가 CPU 드로어나 시스
템 장치에 있을 경우, 이 숫자는 표준 입출력 버스일 경우 0이고 선택적 입출력 버스일 경우 1입니다. 카드
가 입출력 확장 드로어에 있으면 이 숫자가 0입니다. 두 번째 숫자는 카드가 포함된 입출력 버스의 슬롯 번
호 또는 입출력 확장 드로어의 슬롯 번호를 식별합니다.
CC CC 필드는 비동기 분배 상자가 연결된 어댑터 카드에 있는 커넥터를 식별합니다. 가능한 값은 01, 02, 03
및 04입니다.
DD DD 필드는 프린터, 플로터 또는 tty 장치가 연결된 비동기 분배 상자의 포트 번호를 식별합니다.
tty 위치 코드
위치 코드 00-00-S1-00 또는 00-00-S2-00은 tty 장치가 표준 입출력 장치 직렬 포트 s1 또는 s2에 연결되어
있음을 나타냅니다.
이외 다른 위치 코드는 tty 장치가 표준 입출력 장치 이외의 어댑터 카드에 연결되어 있음을 나타냅니다. 이러한
tty 장치의 위치 코드는 AA-BB-CC-DD 형식입니다. 여기서 AA-BB는 제어 어댑터 카드의 위치 코드를 나타냅니
다.

항 설명
목
AA AA 필드의 값이 00이면 시스템 유형에 따라 어댑터 카드가 CPU 드로어 또는 시스템 장치에 있음을 나타
냅니다.AA 필드의 값이 이외의 값이면 카드가 입출력 확장 드로어에 있음을 나타냅니다. 이 경우, 첫 번째
숫자는 입출력 버스를 식별하고 두 번째 숫자는 CPU 드로어에서 입출력 확장 드로어가 연결된 비동기 확
장 어댑터가 포함된 버스의 슬롯 번호를 식별합니다.
BB BB 필드의 첫 번째 숫자는 어댑터 카드가 포함된 입출력 버스를 식별합니다. 카드가 CPU 드로어나 시스
템 장치에 있을 경우, 이 숫자는 표준 입출력 버스일 경우 0이고 선택적 입출력 버스일 경우 1입니다. 카드
가 입출력 확장 드로어에 있으면 이 숫자가 0입니다. 두 번째 숫자는 카드가 포함된 입출력 버스의 슬롯 번
호 또는 입출력 확장 드로어의 슬롯 번호를 식별합니다.
CC CC 필드는 비동기 분배 상자가 연결된 어댑터 카드에 있는 커넥터를 식별합니다. 가능한 값은 01, 02, 03
및 04입니다.
DD DD 필드는 tty 장치가 연결된 비동기 분배 상자의 포트 번호를 식별합니다.
SCSI 장치 위치 코드
다음은 SCSI 장치의 위치 코드입니다.
이 위치 코드는 다음을 비롯한 모든 SCSI 장치에 적용됩니다.
• CD-ROMs
• 디스크
• 개시자 장치
• 읽기/쓰기 광 드라이브
• 테이프
• 대상 모드
위치 코드 형식(화)은 AA-BB-CC-S,L입니다. AA-BB 필드는 SCSI 장치를 제어하는 SCSI 어댑터의 위치 코드
를 식별합니다.
항목 설명
AA AA 필드의 값이 00이면 시스템 유형에 따라 제어 어댑터 카드가 CPU 드로어 또는 시스템 장치에 있음
을 나타냅니다.
BB BB 필드는 입출력 버스와 카드가 포함된 슬롯을 식별합니다. 첫 번째 숫자는 입출력 버스를 식별합니다.
표준 입출력 버스일 경우 0이고 선택적 입출력 버스일 경우 1입니다. 두 번째 숫자는 카드가 포함된, 표
시된 입출력 버스에 있는 슬롯입니다. BB 필드의 값이 00이면 표준 SCSI 제어기를 나타냅니다.
CC CC 필드는 장치가 연결된 카드의 SCSI 버스를 식별합니다. 단일 SCSI 버스만 제공하는 카드는 이 필드
가 00으로 설정됩니다. 그렇지 않을 경우, 00은 카드의 내부 SCSI 버스에 연결된 장치를 나타내고 01은
카드의 외부 SCSI 버스에 연결된 장치를 나타냅니다.
S,L S,L 필드는 SCSI ID와 SCSI 장치의 LUN(논리적 장치 번호)을 식별합니다. S 값은 SCSI ID를 나타내고
L 값은 LUN을 나타냅니다.
Dials/LPFKeys 위치 코드
그래픽 입력 어댑터에 연결된 Dials/LPFKeys 장치의 위치 코드 형식은 AA-BB-CC입니다.
개별 필드의 의미는 다음과 같습니다.
항 설명
목
AA AA 필드의 값이 00이면 시스템 유형에 따라 제어 어댑터 카드가 CPU 드로어 또는 시스템 장치에 있음을
나타냅니다.
장치 관리 159
항 설명
목
표준 입출력 버스일 경우 0이고 선택적 입출력 버스일 경우 1입니다. 두 번째 숫자는 카드가 포함된, 표시
된 입출력 버스에 있는 슬롯입니다.
CC CC 필드는 장치가 연결된 카드 커넥터를 나타냅니다. 이 값은 연결된 장치가 카드의 포트 1에 있는지 또는
포트 2에 있는지에 따라서 01 또는 02입니다.
참고: 직렬로 연결된 Dials/LPFKeys 장치에는 위치 코드가 표시되지 않습니다. 이러한 장치는 tty 장치에 연결된
것으로 간주되기 때문입니다. tty 장치는 사용자가 Dials/LPFKeys를 정의하는 동안 지정합니다.
멀티프로토콜 포트 위치 코드
멀티프로토콜 포트의 위치 코드는 AA-BB-CC-DD 형식입니다. 여기서 AA-BB는 멀티프로토콜 어댑터 카드의 위
치 코드를 나타냅니다.
개별 필드의 의미는 다음과 같습니다.
항 설명
목
AA AA 필드의 값이 00이면 시스템 유형에 따라 멀티프로토콜 어댑터 카드가 CPU 드로어 또는 시스템 장치
에 있음을 나타냅니다.
표준 입출력 버스일 경우 0이고 선택적 입출력 버스일 경우 1입니다. 두 번째 숫자는 카드가 포함된, 표시
된 입출력 버스에 있는 슬롯입니다.
CC CC 필드는 멀티프로토콜 분배 상자가 연결된 어댑터 카드에 있는 커넥터를 식별합니다. 이 값은 항상 01
입니다.
DD DD 필드는 멀티프로토콜 분배 상자의 물리적 포트 번호를 식별합니다. 가능한 값은 00, 01, 02 및 03입니
다.
AIX 장치 드라이버
많은 컴퓨터 프로그램은 몇가지 방식으로 컴퓨터에 연결된 장치에 대해 작업하기 위한 것입니다. 예를 들어 일부
프로그램은 제어 문자를 프린터로 전송하고, 일부 프로그램은 콘솔로부터 문자를 수신하고, 일부 프로그램은 테
이프에서 데이터를 읽습니다. 이러한 각각의 프로그램은 장치로부터의 입력 또는 장치로의 출력만을 처리하기
위한 것이므로 장치 드라이버 프로그램입니다. 이러한 프로그램은 컴퓨터 운영 체제의 일부 또는 확장입니다.
AIX 운영 체제와 같은 다중 태스크 처리를 지원하는 운영 체제는 다른 프로그램이 이미 액세스 중인 장치에 한 프
로그램이 데이터를 기록하지 못하도록 하거나 장치의 상태를 변경하지 못하도록 하는 메커니즘이 필요합니다.
그러므로 다중 태스크 처리 운영 체제는 특권있는 지시사항 실행과 특권없는 지시사항 실행을 구분하는 컴퓨터
프로세서에 따라 달라집니다. 그러므로 특권 있는 모드(커널 모드)에서 실행되는 프로그램과 사용자 모드에서 실
행되는 프로그램 사이를 구분해야 합니다. AIX 커널은 커널 모드에서 실행되는 모든 소프트웨어 프로그램으로
구성됩니다.
네트워크 어댑터 또는 USB 포트에 연결되는 장치와 같이 사용자 모드에서 실행되는 일부 AIX 프로그램은 장치
드라이버 프로그램에 액세스할 수 있습니다. 그러나 이러한 AIX 프로그램은 커널의 일부인 소프트웨어를 사용해
서만 장치 드라이버 프로그램에 액세스할 수 있습니다. 커널 장치 드라이버는 사용자 모드에서 실행되는 장치 드
라이버보다 더 복잡하므로, 장치 드라이버 용어는 프로그램이 커널 모드에서 실행될 때 장치를 제어하는 소프트
웨어를 말합니다.
장치 드라이버 프로그램의 루틴은 C로 작성되고 컴파일되어 하나 이상의 확장된 오브젝트 파일 형식(XCOFF 또
는 XCOFF64) 오브젝트 파일을 생성합니다. AIX 버전 6.1부터 모든 장치 드라이버 프로그램은 64비트
(XCOFF64)입니다. 32비트 장치 드라이버 프로그램은 지원되지 않습니다. 커널 로더가 커널 기호를 해석할 수
있도록 오브젝트 파일이 링크됩니다. 오브젝트 파일이 링크되면 커널에서 반입하는 기호 리스트로 커널 로더 섹
션을 업데이트합니다. 커널 기호는 /lib/kernex.exp 파일에 있습니다. 이 링크는 실행을 시작하기 위한 디폴
트 시작점으로서 장치 드라이버의 구성 루틴을 설정합니다.

AIX 장치 드라이버 프로그램에 대한 자세한 정보는 AIX 장치 드라이버 프로그램 작성을 참조하십시오. 이 문서
에서는 다음 항목에 대해 설명합니다.
• AIX 장치 드라이버, 시작점 및 유형의 개요
• PCI 어댑터를 위한 프로그래밍된 입출력 조작 및 직접 메모리 액세스(DMA)
• 인터럽트 및 인터럽트 처리
• 메모리 관리.
• 직렬화 및 동기화, 잠금 및 타이머
• 장치 구성 메소드
PCI/PCIe 어댑터용 ODM에 대한 정보는 AIX PCI/PCIe 어댑터용 ODM 조정을 참조하십시오.
iSCSI 오프로드 어댑터 설정

iSCSI 오프로드 어댑터 설정에는 어댑터 구성, 대상 추가 또는 업데이트가 포함됩니다. 이 지시사항은 iSCSI 오프
로드 어댑터에만 적용됩니다. iSCSI 소프트웨어 개시자 구성에 대한 정보는 iSCSI 소프트웨어 개시자 및 소프트
웨어 대상을 참조하십시오.
AIX 에서 iSCSI 어댑터 구성

iSCSI 어댑터를 구성하는 태스크는 아주 간단하고 쉽습니다.
1. AIX 명령 프롬프트에서 smit iscsi를 입력하십시오.
iSCSI 화면이 표시됩니다.
2. iSCSI 화면에서 iSCSI Adapter를 선택하십시오.
iSCSI 어댑터 화면이 표시됩니다.
3. iSCSI 어댑터 화면에서 iSCSI 어댑터의 특성 변경/표시를 선택하십시오.
iSCSI 어댑터 화면의 특성 변경/표시 화면이 표시됩니다.
4. 구성할 iSCSI 어댑터를 리스트에서 선택하십시오.
다음 예제와 유사한 구성 화면이 표시됩니다.
[Entry Fields]
iSCSI Adapter ics0
Description iSCSI Adapter
Status Available
Location 10-60
Max. number of commands to queue to adapter [200] + +#
Maximum Transfer Size [0x100000] +
Discovery Filename [/etc/iscsi/targetshw]

Discovery Policy [file]
Automatic Discovery Secrets Filename [/etc/iscsi/autosecret]
Adapter IP Address [10.1.4.187]
Adapter Subnet Mask [255.255.255.0]
Adapter Gateway Address [10.1.4.1]
Apply change to DATABASE only no +
참고: 특정 필드의 용도를 잘 모르는 경우에는 필드에 커서를 놓고 F1을 눌러 도움말을 보십시오.
플랫 파일 검색을 사용하려면 Discovery Policy 필드에 file을 입력하십시오. ODM 검색을 사용하려면 검색 정
책 필드에 odm을 입력하십시오. DHCP 검색 iSCSI 대상을 사용하려면 검색 정책 필드에 slp를 입력하십시오.
iSCSI 목표의 플랫 파일 갱신
플랫 파일은 iSCSI 목표를 구성하는 데 사용되는 정적 구성 파일입니다. 디폴트 파일 이름은 /etc/iscsi/
targetshw입니다.
관련된 모든 iSCSI 목표 전개 특성을 플랫 파일에 명시적으로 지정해야 합니다.
장치 관리 161
관련 정보
목표 파일
정적으로 검색된 iSCSI 목표를 ODM에 추가

iSCSI 어댑터 또는 iSCSI 소프트웨어 개시자에 대해 ODM 발견 정책을 사용 중인 경우 iSCSI 드라이버는 ODM에
서 iSCSI 목표 설명을 확보합니다.
AIX 명령이나 SMIT를 사용하여 ODM의 iSCSI 대상 정보를 조작할 수 있습니다. chiscsi, lsiscsi, mkiscsi
및 rmiscsi 명령은 ODM의 iSCSI 대상 정보를 변경, 표시, 추가 및 제거합니다.
정적으로 검색된 한 iSCSI 대상을 SMIT를 사용하여 ODM에 추가하려면 다음을 수행하십시오.
2. iSCSI 화면에서 ODM의 iSCSI 목표 장치 매개변수를 선택하십시오.
ODM의 iSCSI 목표 장치 매개변수 화면이 표시됩니다.
3. iSCSI 화면에서 ODM에 iSCSI 목표 장치 추가를 선택하십시오.
ODM에 iSCSI 목표 장치 추가 화면이 표시됩니다.
4. 리스트에서 구성하려는 iSCSI 장치를 선택하십시오. 리스트에는 iSCSI 오프로드 어댑터("ics"로 시작하는 장
치) 및 iSCSI 소프트웨어 개시자("iscsi"로 시작하는 장치) 모두가 포함됩니다.
5. 리스트에서 구성하려는 iSCSI 장치를 선택하십시오. 리스트에는 iSCSI 오프로드 어댑터("ics"로 시작하는 장
치) 및 iSCSI 소프트웨어 개시자("iscsi"로 시작하는 장치) 모두가 포함됩니다.
6. 필드에 적절한 정보를 입력하십시오.
다음은 예제입니다.
[Entry Fields]
iSCSI Adapter ics0

iSCSI Target Name [iqn.com.ibm.tgt:0]
IP Address of iSCSI Target [10.1.4.25]
Port Number of iSCSI Target [3260]
Password [my password]
User Name [user name]
플랫 파일에서 정적으로 검색된 iSCSI 목표를 ODM에 추가

SMIT를 사용하여 플랫 파일의 정보를 ODM으로 반입할 수 있습니다.
2. iSCSI 화면에서 ODM의 iSCSI 목표 장치 매개변수를 선택하십시오.
ODM의 iSCSI 목표 장치 매개변수 화면이 표시됩니다.
3. iSCSI 화면에서 ODM에 iSCSI 목표 장치 추가를 선택하십시오.
ODM에 iSCSI 목표 장치 추가 화면이 표시됩니다.
4. iSCSI 화면에서 ODM에 파일의 iSCSI 목표 장치 데이터 추가를 선택하십시오.
ODM에 파일의 iSCSI 목표 장치 데이터 추가 화면이 표시됩니다.
5. 구성할 iSCSI 어댑터를 리스트에서 선택하십시오.
선택한 iSCSI 어댑터에 대해 ODM에 파일의 iSCSI 목표 장치 데이터 추가 화면이 표시됩니다.
6. 필드에 적절한 정보를 입력하십시오.
다음은 예제입니다.
[Entry Fields]
iSCSI Protocol Device iscsi3
iSCSI Group [static] +
Filename of iSCSI Targets [/etc/iscsi/targetshw] +

PCI 핫 플러그 관리
운영 체제가 실행되는 동안, 사용 가능한 PCI 슬롯에 새 PCI 핫 플러그 어댑터를 삽입할 수 있습니다.
현재 설치된 것과 같은 유형의 또 다른 어댑터이거나 다른 유형의 PCI 어댑터일 수 있습니다. 운영 체제를 재시작
하지 않아도 운영 체제와 애플리케이션에서 새로운 자원을 사용할 수 있습니다. 핫 플러그 어댑터를 추가하는 이
유는 다음과 같습니다.
• 기존 하드웨어 및 펌웨어에 추가 기능 또는 용량을 추가하는 경우
• PCI 어댑터가 제공하는 기능이 더 이상 필요하지 않은 시스템에서 다른 곳으로 어댑터 이주하는 경우
• PCI 어댑터를 비롯한 선택적 하드웨어 서브시스템의 초기 구성, 운영 체제 설치 및 시작 후 어댑터 카드를 사용
할 수 있게 되는 새 시스템을 설치하는 경우
참고: PCI 핫 플러그 대체나 추가 작업을 통해 또는 동적 논리적 파티션을 통해 어댑터를 추가할 경우,
bootlist 명령에 어댑터와 어댑터의 하위 장치를 부트 장치로 지정할 수 없을 수도 있습니다. 사용될 수 있는
모든 부트 장치를 운영 체제에서 인식할 수 있도록 하려면 시스템을 재시작해야 할 수도 있습니다. 부트 리스트에
이미 나열되어 동일한 유형의 다른 어댑터로 대체된 어댑터는 유효한 부트 장치입니다.
또한 시스템을 종료하거나 전원을 끄지 않고도, 결함이 있거나 오류가 발생하는 PCI 핫 플러그 어댑터를 제거하
거나 동일한 유형의 다른 어댑터로 교환할 수도 있습니다. 어댑터를 교환할 경우, 새 어댑터가 기존 어댑터와 유
형이 동일하므로 기존 장치 드라이버가 새 어댑터를 지원합니다. 어댑터 아래의 장치 구성 및 장치 구성 정보도
대체된 장치에 그대로 적용됩니다. 어댑터를 대체하는 이유는 다음과 같습니다.
• 문제를 식별하거나 오류가 발생하는 FRU를 알아내는 데 도움이 되도록 임시로 카드를 대체하는 경우
• 결함이 있거나, 오류가 발생하거나, 간헐적으로 오류가 발생하는 어댑터를 기능 카드로 대체하는 경우
• HACMP 또는 다중 경로 입출력 구성에서 오류가 발생하는 중복 어댑터를 대체하는 경우
핫 플러그 어댑터를 제거할 경우, 어댑터가 제공하는 자원을 운영 체제와 애플리케이션에서 사용할 수 없게 됩니
다. 어댑터를 제거하는 이유는 대체로 다음과 같습니다.
• 기존 입출력 서브시스템을 제거하는 경우
• 더 이상 필요하지 않거나 오류가 발생하며 대체 카드를 사용할 수 없는 어댑터를 제거하는 경우
• 해당 시스템에서 어댑터가 더 이상 필요하지 않아서 다른 시스템으로 이주하는 경우
핫 플러그 장치를 제거하거나 대체하려면 먼저 장치 구성을 해제해야 합니다. 연관된 장치 드라이버에서는 이 장
치에 할당한 모든 시스템 자원을 해제해야 합니다. 메모리 고정 취소 및 해제, 인터럽트 및 EPOW 핸들러 정의 취
소, DMA 및 타이머 자원 해제 및 기타 필요한 단계 등이 시스템 자원 해제에 포함됩니다. 또한 해당 장치에서 인
터럽트, 버스 메모리, 버스 입출력을 사용할 수 없도록 해야 합니다.
시스템 관리자는 어댑터 제거 전후에 다음 태스크를 수행해야 합니다.
• 장치를 사용하는 애플리케이션, 디먼 또는 프로세스를 종료하고 복원합니다.
• 파일 시스템을 마운트 해제하고 다시 마운트합니다.
• 장치 정의를 제거하고 다시 작성하며 사용 중인 장치를 해제하는 데 필요한 다른 작업을 수행합니다.
• 시스템을 서비스를 받을 수 있는 안전한 상태로 만듭니다.
• 필요한 장치 드라이버를 구해서 설치합니다.
식별된 슬롯에 연결된 장치의 구성이 해제되어 정의된 상태에 있지 않으면 제거 및 대체 작업에 실패합니다.
rmdev 명령으로 이 작업을 수행할 수 있습니다. 어댑터를 정의된 상태에 놓기 전에 이 어댑터를 사용 중인 모든
애플리케이션을 닫으십시오. 그렇지 않으면 이 명령이 실패합니다. rmdev 명령에 대한 자세한 정보는 rmdev를
참조하십시오.
몇몇 경우에는 다음 태스크도 수행해야 합니다.
• 삽입, 제거 또는 대체할 수 있도록 PCI 핫 플러그 어댑터를 준비합니다.
• 핫 플러그 작업과 관련된 슬롯 또는 PCI 어댑터를 식별합니다.
• PCI 핫 플러그 어댑터를 제거하거나 삽입합니다.
장치 관리 163
참고: 핫 플러그 조작 동안 오브젝트 데이터 관리자(ODM)가 잠긴 상태로 남아 있습니다. 그러므로, ODM을 필요
로 하는 다른 태스크는 정지하거나 실패할 수 있습니다. 다른 노드에 의해 초기화되는 클러스터 전체 구성 변경사
항은 클러스터에서 정지하거나 실패할 수도 있습니다. 그러므로, 핫 플러그 조작이 완료될 때까지 이러한 태스크
를 수행하지 않도록 하십시오.
주의: PCI 핫 플러그 관리를 사용할 경우 시스템 전원을 끄거나 운영 체제를 재시작하지 않고도 PCI 어댑
터를 추가, 제거 및 대체할 수는 있지만 핫 플러그 슬롯에 있는 일부 장치는 이런 방식으로 관리할 수 없습
니다. 예를 들어, rootvg 볼륨 그룹을 구성하는 하드 디스크나, 장치가 연결된 입출력 제어기는 시스템 전
원을 끄지 않고는 제거하거나 대체할 수 없는데, 이는 운영 체제를 실행하려면 이러한 장치가 반드시 필요
하기 때문입니다. rootvg 볼륨 그룹이 미러된 경우, chpv 명령으로 디스크를 오프라인 상태로 만들 수 있
습니다. MPIO(다중 경로 입출력)가 사용 가능하며 여러 개의 입출력 제어기로 연결된 하나 이상의 디스
크에 rootvg 볼륨 그룹이 상주할 경우, 시스템을 재부트하지 않고도 이러한 입출력 제어기 중 하나를 제거
하거나 대체할 수 있습니다. 이와 같은 경우에는 어댑터에 rmdev -R 명령을 사용하여, 제거하거나 대체
할 입출력 제어기의 모든 경로의 구성을 해제해야 합니다. 그러면 경로와 어댑터의 구성이 해제됩니다. 그
러면 핫 플러그 관리 작업을 계속할 수 있습니다. PCI 핫 플러그 어댑터를 제거하거나 삽입하기 전에 핫
플러그를 지원하는 시스템 장치와 함께 제공되는 PCI Adapter Placement Reference를 참조하여 시스템
가동 중에 어댑터를 교체할 수 있는지 여부를 확인하십시오. 어댑터 설치 또는 제거에 대한 지시사항은 시
스템 장치 문서를 참조하십시오.
PCI 핫 플러그 슬롯 정보 표시
핫 플러그 어댑터를 추가, 제거 또는 대체하기 전에 시스템의 PCI 핫 플러그 슬롯에 대한 정보를 표시할 수 있습
니다.
표시할 수 있는 정보는 다음과 같습니다.
• 시스템에 있는 모든 PCI 핫 플러그 슬롯의 리스트
• 슬롯이 사용 가능한지, 즉 비어 있는지 여부
• 현재 사용 중인 슬롯
• 슬롯 이름, 설명, 커넥터 유형 및 연결된 장치 이름과 같은 특정 슬롯의 특성
SMIT 또는 시스템 명령을 사용할 수 있습니다. 이러한 태스크를 수행하려면 루트 사용자로 로그인해야 합니다.
SMIT 단축 경로 프로시저
1. 시스템 프롬프트에 smit devdrpci를 입력한 다음 Enter를 누르십시오.
2. SMIT 대화상자를 사용하여 태스크를 완료하십시오.
태스크를 완료하는 데 필요한 추가 정보를 보려면 SMIT 대화상자에서 F1 도움말 키를 선택하십시오.
명령 프로시저
다음 명령을 사용하여 핫 플러그 슬롯 및 연결된 장치에 대한 정보를 표시할 수 있습니다.
• lsslot 명령은 모든 PCI 핫 플러그 슬롯과 해당 특성의 리스트를 표시합니다.
• lsdev 명령은 시스템에 설치된 모든 장치의 현재 상태를 표시합니다.
PCI 통신 어댑터 구성 해제
다음 내용은 PCI 통신 어댑터의 구성을 해제하는 절차를 간략하게 보여 줍니다. 이러한 어댑터에는 이더넷, 토큰
링, FDDI 및 ATM 어댑터가 포함됩니다.
애플리케이션에 TCP/IP 프로토콜을 사용할 경우, 어댑터를 정의된 상태로 만들려면 먼저 네트워크 인터페이스
리스트에서 어댑터의 TCP/IP 인터페이스를 제거해야 합니다. netstat 명령을 사용하여, 어댑터가 TCP/IP용으
로 구성되었는지 확인하고 어댑터의 활성 네트워크 인터페이스를 확인하십시오. netstat 명령에 대한 자세한
정보는 netstat을 참조하십시오.
이더넷 어댑터는 표준 이더넷(enX) 또는 IEEE 802.3(etX)이라는 두 개의 인터페이스를 사용할 수 있습니다. X는
entX 어댑터 이름에서와 동일한 숫자입니다. 한 번에 한 인터페이스만 TCP/IP를 사용할 수 있습니다. 예를 들어,
이더넷 어댑터 ent0이 en0과 et0이라는 인터페이스를 사용할 수 있습니다.
토큰 링 어댑터는 토큰 링 (trX)라는 인터페이스 하나만 사용할 수 있습니다. X는 tokX 어댑터 이름에서와 동일
한 숫자입니다. 예를 들어, 토큰 링 어댑터 tok0이 tr0이라는 인터페이스를 사용할 수 있습니다.

ATM 어댑터는 ATM (atX)라는 ATM 인터페이스 하나만 사용할 수 있습니다. X는 atmX 어댑터 이름에서와 동일
한 숫자입니다. 예를 들어, ATM 어댑터 atm0이 at0이라는 인터페이스를 사용할 수 있습니다. 하지만 ATM 어댑
터의 경우, 단일 어댑터에서 여러 개의 에뮬레이트된 클라이언트를 실행할 수 있습니다.
ifconfig 명령은 네트워크에서 인터페이스를 제거합니다. rmdev 명령은 사용자 조정된 장치 오브젝트 클래스
에 장치 정의는 그대로 유지하면서 PCI 장치의 구성을 해제합니다. 어댑터 상태가 정의된 상태가 되면 drslot
명령을 사용하여 어댑터를 제거할 수 있습니다.
사용자 조정된 장치 오브젝트 클래스에 장치 정의는 그대로 유지하면서 PCI 버스 pci1의 하위와 이들 아래에 있
는 다른 모든 장치의 구성을 해제하려면 다음을 입력하십시오.
rmdev -p pci1
시스템이 다음과 유사한 메시지를 표시합니다.

rmt0 Defined
hdisk1 Defined
scsi1 Defined
ent0 Defined
PCI 핫 플러그 어댑터 제거 또는 대체

운영 체제를 종료하거나 시스템 전원을 끄지 않고도 시스템에서 PCI 핫 플러그 어댑터를 제거하거나 대체할 수
있습니다. 어댑터를 제거하면, 어댑터가 제공하던 자원을 운영 체제나 애플리케이션에서 사용할 수 없게 됩니다.
어댑터를 제거하려면 먼저 어댑터의 구성을 해제해야 합니다.
다음은 PCI 핫 플러그 어댑터를 제거하는 절차입니다. SMIT 또는 시스템 명령으로 이러한 태스크를 완료할 수
있습니다. 이러한 태스크를 수행하려면 루트 사용자로 로그인해야 합니다.
유형이 같은 다른 어댑터로 어댑터를 대체하면 이전 어댑터의 구성 정보가 그대로 유지되고 새로 대체된 카드의
정보와 비교됩니다. 이전 어댑터의 장치 드라이버가 새로 대체된 어댑터를 지원할 수 있어야 합니다.
명령 프로시저
다음 명령을 사용하여 PCI 핫 플러그 슬롯 및 연결된 장치에 대한 정보를 표시하고 PCI 핫 플러그 어댑터를 제거
• lsslot 명령은 모든 PCI 핫 플러그 슬롯과 해당 특성의 리스트를 표시합니다.
• drslot 명령은 핫 플러그 어댑터 제거를 위해 핫 플러그 슬롯을 준비합니다.
PCI 핫 플러그 어댑터 추가

시스템 장치의 사용 가능한 슬롯에 PCI 핫 플러그 어댑터를 추가하여, 운영 체제를 재부트하지 않고도 운영 체제
와 애플리케이션에서 새로운 자원을 사용할 수 있게 만들 수 있습니다. 현재 설치된 어댑터와 유형이 동일한 다른
어댑터나 유형이 다른 어댑터를 추가할 수 있습니다.
다음은 새 PCI 핫 플러그 어댑터를 추가하는 절차입니다.
주의: PCI 핫 플러그 어댑터를 추가하기 전에 핫 플러그를 지원하는 시스템 장치와 함께 제공되는 PCI
Adapter Placement Reference를 참조하여 시스템 가동 중에 어댑터를 교체할 수 있는지 여부를 확인하
십시오. 어댑터 설치 또는 제거에 대한 지시사항은 시스템 장치 문서를 참조하십시오.
새 PCI 핫 플러그 어댑터를 추가하는 작업에는 다음 태스크가 포함됩니다.
• 시스템의 사용 가능한 슬롯 찾기 및 식별
• 어댑터 구성을 위해 슬롯 준비
장치 관리 165
• 장치 드라이버 설치(필요한 경우)
• 새 어댑터 구성
SMIT 또는 시스템 명령을 사용할 수 있습니다. 이러한 태스크를 수행하려면 루트 사용자로 로그인해야 합니다.
참고: 시스템에 핫 플러그 어댑터를 추가할 경우, bootlist 명령에 어댑터와 어댑터의 하위 장치를 부트 장치로
지정할 수 없을 수도 있습니다. 사용될 수 있는 모든 부트 장치를 운영 체제에서 인식할 수 있도록 하려면 시스템
을 재부트해야 할 수도 있습니다.
명령 프로시저
다음 명령을 사용하여 PCI 핫 플러그 슬롯 및 연결된 장치에 대한 정보를 표시하고 PCI 핫 플러그 어댑터를 추가
• lsslot 명령은 모든 핫 플러그 슬롯과 해당 특성의 리스트를 표시합니다.
• drslot 명령은 핫 플러그 어댑터 추가 또는 제거를 위해 핫 플러그 슬롯을 준비합니다.
다중 경로 입출력
MPIO(다중 경로 입출력)를 사용하는 장치는 하나 이상의 물리적 연결 또는 경로를 통해 고유하게 검색할 수 있습
니다.
PCM(경로 제어 모듈)은 경로 관리 기능을 제공합니다.
MPIO 호환 장치 드라이버는 두 개 이상의 멀티부트 유형을 제어할 수 있습니다. PCM은 하나 이상의 특정 장치를
지원할 수 있습니다. 따라서 여러 개의 PCM에 하나의 장치 드라이브를 접속시켜 각 멀티부트에 대한 경로에서 이
루어지는 입출력을 제어할 수 있습니다.

그림 13. MPIO 구성요소 상호작용
장치에 MPIO를 사용할 수 있으려면 먼저 다중 경로의 검색, 구성 및 관리를 지원하도록, 장치 드라이버, 메소드
및 오브젝트 데이터 관리자(ODM)에 사전정의된 속성을 수정해야 합니다. 병렬 SCSI 및 광 채널 디스크 장치 드
라이버와 해당 장치 메소드는 MPIO 디스크 장치를 지원합니다. iSCSI 디스크 장치는 MPIO 장치로서 지원됩니
다. 파이버 채널 테이프 장치 드라이버 및 해당 장치 메소드는 MPIO 테이프 장치를 지원합니다. 뿐만 아니라
ODM에 사전정의된 몇몇 장치의 속성도 MPIO를 지원하도록 수정되었습니다.
AIX PCM은 PCM RTL 구성 모듈과 PCM KE 커널 확장으로 구성됩니다. PCM RTL은 장치 메소드가 PCM KE에 필
요한 PCM KE 장치 고유의 추가 속성 또는 경로 ODM 속성을 발견할 수 있게 해 줍니다. PCM RTL은 장치 메소드
에 의해 로드됩니다. 그런 다음 PM KE 변수를 초기화하거나 수정하는 특정 작업을 수행하기 위해 PCM RTL 내에
있는 하나 이상의 루틴이 액세스됩니다.
PCM KE는 MPIO 인터페이스를 지원하는 모든 장치 드라이버에 경로 제어 관리 기능을 제공합니다. PCM KE는
경로를 발견하고 이 정보를 장치 드라이버에 전달하기 위해 장치 구성을 사용합니다. 각각의 MPIO 호환 장치 드
장치 관리 167
라이버는 바로 한 레벨 위의 상위로부터의 경로를 장치에 추가합니다. 다양한 경로에서 이루어지는 입출력의 유
지 및 스케줄링은 PCM KE에 의해 수행되며 MPIO 호환 장치 드라이버는 이를 인식하지 못합니다.
PCM KE는 두 개 이상의 라우팅 알고리즘을 제공하며 이러한 알고리즘은 사용자가 선택할 수 있습니다. 뿐만 아
니라 PCM KE는 모든 입출력 요청에 대한 최적의 경로를 결정하고 선택하는 데 사용할 수 있는 정보를 수집하는
데도 유용합니다. PCM KE는 로드 밸런싱, 연결 속도, 연결 실패 등의 다양한 기준을 바탕으로 최적의 경로를 선
택할 수 있습니다.
AIX PCM에는 다음을 수행하는 데 사용할 수 있는 건강성 검사 기능이 있습니다.
• 경로를 확인하고 입출력을 전송하는 데 현재 사용할 수 있는 경로가 어떤 것인지 결정합니다.
• 임시 경로 오류(예: 장치 케이블이 제거된 다음 다시 연결된 경우)로 인해 이전에 실패한 것으로 표시된 경로를
다시 사용 가능하게 만듭니다.
• 현재는 사용되지 않지만 실패가 발생할 경우 사용될 수 있는 경로를 확인합니다. 예를 들어, 알고리즘 속성값이
failover일 경우, 건강성 검사가 대체 경로를 테스트할 수 있습니다.
AIX 디폴트 PCM을 사용하여 발견하고 구성할 수 없는 디스크 장치와 테이프 장치도 있습니다. AIX 디폴트 PCM
은 두 개의 경로 제어 모듈로 구성됩니다. 하나는 디스크 장치를 관리하고 다른 하나는 테이프 장치를 관리합니
다. 장치가 검색되지 않으면 장치 공급업체에 문의하여 장치에 PCM을 사용할 수 있는지 확인하십시오.
MPIO 사용 가능 장치 관리
다중 경로 입출력(MPIO) 기능은 실패 복구 시 사용될 장치에 대한 대체 경로를 정의하는 데 사용할 수 있습니다.
실패 복구는 장치의 안정성과 가용성을 개선하는 장치 관리 알고리즘입니다. 시스템에서는 한 입출력 경로에서
오류가 발생할 경우 대체 경로를 통해 입출력을 다시 라우트하기 때문입니다. 모든 SCSI SCSD 디스크 드라이브
는 자동으로 MPIO 장치로 구성되고 파이버 채널 디스크 드라이브의 선택 번호를 MPIO 기타 디스크로 구성할 수
있습니다. 장치 드라이버가 AIX 에 구현된 MPIO와 호환되기만 하면 이외의 다른 장치도 지원됩니다.
MPIO는 BOS 설치 중 설치 및 구성됩니다. 추가 구성이 필요하지 않지만 SMIT 또는 명령행 인터페이스를 사용하
여 장치(또는 장치 경로)를 추가, 제거, 재구성, 사용으로 설정 및 사용 안함으로 설정할 수 있습니다. MPIO 경로
를 관리하는 데 사용할 수 있는 명령은 다음과 같습니다.
mkpath
목표 장치에 대한 경로를 추가합니다.
rmpath
목표 장치에 대한 경로를 제거합니다.
chpath
목표 장치에 대한 경로의 속성 또는 작동 상태를 변경합니다.
lsmpio
MPIO(MultiPath I/O) 스토리지 장치에 대한 상태, 구성 및 통계와 같은 정보를 표시합니다.
lspath
목표 장치에 대한 경로 정보를 표시합니다.
다중 경로 I/O(MPIO)와 같은 다중 포트를 가진 디스크에 BOS 설치 또는 mksysb 설치를 수행하는 경우, 포트는
실치 도중 활성 상태를 유지해야 합니다.
SCSI 장치를 MPIO 장치로 케이블링

MPIO 사용 가능 장치로 구성될 경우 SCSI 장치 한 개에 최대 두 개의 어댑터가 지원될 수 있습니다.
병렬 SCSI 장치를 MPIO 장치로 케이블하려면 다음과 같은 단순한 구성을 예로 사용하십시오. 다음은 필요한 최
소 구성이며, 사용할 장치에 따라 추가 구성이 필요할 수도 있습니다.
1. 전원을 차단한 상태에서 두 개의 SCSI 어댑터를 설치하십시오.
2. 두 SCSI 어댑터 모두에 장치를 케이블하십시오.
3. 시스템 전원을 켜십시오.
4. 두 어댑터 중 하나의 설정값을 고유 SCSI ID로 변경하십시오. 디폴트로, SCSI 어댑터의 SCSI ID는 7입니다.
각 ID가 고유해야 하므로 두 어댑터 중 하나의 ID를 6과 같은 다른 번호로 변경하십시오.
5. cfgmgr 명령을 실행하십시오.
6. 구성을 확인하려면 명령행에 다음을 입력하십시오.

lspath -l hdiskX
여기서 X는 새로 구성된 장치의 논리적 번호입니다. 명령 출력에는 두 개의 경로와 경로의 상태가 표시되어야
합니다.
그림 14. MPIO SCSI 장치용 케이블 구성
다음 그림은 두 개의 SCSI 어댑터를 동일한 장치에 케이블하는 것을 보여 줍니다.
광 채널 장치를 MPIO 장치로 케이블링

광 채널 장치를 여러 개의 어댑터에 케이블할 수 있습니다. 소프트웨어 내에서는 어댑터 수에 제한을 받지 않습니
다.
광 채널 장치를 MPIO 장치로 케이블하려면 다음과 같은 단순한 구성을 예로 사용하십시오. 다음은 필요한 최소
구성이며, 사용할 장치에 따라 추가 구성이 필요할 수도 있습니다.
1. 전원을 차단한 상태에서 두 개의 광 채널 어댑터를 설치하십시오.
2. 스위치 또는 허브에 어댑터를 케이블하십시오.
3. 스위치 또는 허브에 장치를 케이블하십시오.
4. 시스템의 전원을 켜십시오.
5. 구성을 확인하려면 명령행에 다음을 입력하십시오.
lspath -l hdiskX
여기서 X는 새로 구성된 장치의 논리적 번호입니다. 명령 출력에는 사용자가 설치한 각 어댑터에 대해 하나의
경로와 함께 각 경로의 상태가 표시되어야 합니다.
그림 15. MPIO 광 채널 장치용 케이블 구성
MPIO 장치 구성
MPIO 호환 장치는 비 MPIO 장치와 동일한 명령을 사용합니다.
장치 관리 169
cfgmgr, mkdev, chdev, rmdev 및 lsdev 명령은 MPIO 장치 인스턴스 관리를 지원하고 해당 속성을 표시합니
다. MPIO 장치 인스턴스에는 연관된 경로 인스턴스도 있습니다. mkpath, chpath, rmpath 및 lspath 명령으
로 경로 인스턴스를 관리하고 해당 속성을 표시할 수 있습니다.
경로 인스턴스는 구성 해제 중인 장치 없이 MPIO 장치에 추가되거나 제거할 수 없습니다.
MPIO 장치가 추가 속성을 가질 수도 있지만 모든 MPIO 장치가 지원해야 하는 필수 속성은 reserve_policy
와 algorithm입니다. reserve_policy 속성은 장치가 열릴 때 장치 드라이버그 구현할 예약 방법의 유형을
결정하며, 동일한 시스템에 있거나 다른 시스템에 있는 다른 어댑터로부터의 장치 액세스를 제한하는 데 사용할
수 있습니다. algorithm 속성은 장치에 구성된 여러 경로에서 이루어지는 입출력을 관리하기 위해 PCM이 사
용하는 방법을 정의합니다.
지원되는 다중 경로 장치
AIX 디폴트 PCM은 devices.common.IBM.mpio.rte 파일 세트에 정의된 디스크 장치 및 테이프 장치 세트
를 지원합니다.
AIX 디스크 PCM 또는 테이프 PCM이 지원되지 않는 장치의 경우, 장치 벤더에서 ODM에 사전정의된 속성, PCM
및 장치를 MPIO 호환 장치로 인식하는 데 필요한 기타 지원 코드를 제공해야 합니다.
AIX 디스크 PCM이 지원되는 디스크 장치가 어떤 것인지 확인하려면 다음 스크립트를 실행하십시오.
odmget -qDvDr=aixdiskpcmke PdDv | grep uniquetype | while read line
do
utype=ècho $line | cut -d'"' -f2`
dvc=òdmget -q"uniquetype=$utype AND attribute=dvc_support" PdAt`
echo $dvc | grep values | cut -d'"' -f2
done
AIX 디스크 PCM이 지원되는 테이프 장치가 어떤 것인지 확인하려면 다음 스크립트를 실행하십시오.
odmget -qDvDr=aixtapepcmke PdDv | grep uniquetype | while read line
do
utype=ècho $line | cut -d'"' -f2`
dvc=òdmget -q"uniquetype=$utype AND attribute=dvc_support" PdAt`
echo $dvc | grep values | cut -d'"' -f2
done
스크립트 출력에는 AIX 디폴트 PCM이 지원되는 개별 장치 유형의 리스트가 표시됩니다. AIX 디스크 PCM이 지
원되는 세 가지 장치 유형은 자동 구성 병렬 SCSI 디스크(disk/scsi/scsd), MPIO 기타 FC 디스크
(disk/fcp/mpioosdisk), 그리고 MPIO 기타 iSCI(disk/iscsi/mpioosdisk)입니다. AIX 테이프 PCM이
지원되는 장치 유형은 MPIO 기타 FC 테이프(tape/fcp/mpioost)입니다.
MPIO 기타 FC 디스크와 MPIO 기타 FC 테이프 장치는 각각 기타 광 채널 디스크와 광 채널 테이프의 서브세트입
니다. 벤더가 제공한 ODM 사전 정의 속성이 없고, AIX 디폴트 PCM 중 하나와 작동하도록 장치가 인증된 경우에
만 장치가 MPIO 기타 FC 장치로 지원됩니다. 장치가 MPIO 기타 FC 장치로 인증되었다 하더라도, MPIO 기타 FC
장치로 구성될 경우 모든 장치 기능이 지원되는 것은 아닙니다.
MPIO 기타 iSCSI 디스크는 다른 iSCSI 디스크의 서브세트입니다. 벤더가 제공한 ODM 사전 정의 속성이 없고,
AIX PCM 중 하나와 작동하도록 장치가 인증된 경우에만 장치가 MPIO 기타 iSCSI 디스크로 지원됩니다. 장치가
MPIO 기타 iSCSI 장치로 인증되었다 하더라도, MPIO 기타 iSCSI 디스크로 구성될 경우 모든 장치 기능이 지원
되는 것은 아닙니다.
MPIO 기타 FC 디스크로 지원되는 장치가 어떤 것인지 확인하려면 다음 스크립트를 실행하십시오.
odmget –quniquetype=disk/fcp/mpioosdisk PdAt | grep deflt | cut -d'"' -f2
MPIO 기타 FC 테이프로 지원되는 장치가 어떤 것인지 확인하려면 다음 스크립트를 실행하십시오.

odmget -q "uniquetype=tape/fcp/mpioosdisk AND attribute=mpio_model_map PdAt | grep deflt | cut -d'"' -f2
MPIO 기타 iSCSI 디스크로 지원되는 장치가 어떤 것인지 확인하려면 다음 스크립트를 실행하십시오.
odmget –quniquetype=disk/iscsi/mpioosdisk PdAt | grep deflt | cut -d'"' -f2
스크립트 출력에는 장치 벤더와 모델이 포함된 조회 데이터의 리스트가 표시됩니다.

시스템에 설치된 모든 MPIO 가능 장치를 표시하려면 다음 스크립트를 실행하십시오.
odmget -qattribute=unique_id PdAt | grep uniquetype | cut -d'"' -f2
스크립트 출력에는 AIX 디폴트 PCM 및 벤더에서 제공한 PCM이 지원되는 개별 MPIO 호환 장치 유형의 리스트
가 표시됩니다.
MPIO 장치 속성
다음 속성은 다중 경로 장치에 의해서만 지원됩니다. 속성은 SMIT 또는 명령(특히 lsattr 및 chdev 명령)을 사
용하여 표시되거나 변경될 수 있습니다.
다중 경로 입출력(MPIO) 장치 속성의 일부는 속성의 동시 갱신을 위해 사용으로 설정됩니다. 디스크가 열려 있고
사용 중인 동안에 속성값을 갱신할 수 있고, 새 값이 즉시 적용됩니다. 일부 속성의 경우, 특히
reserve_policy 속성의 경우, 속성을 변경할 수 있는 시기나 속성이 승인할 수 있는 새 값에 대해 제한사항이
있을 수 있습니다. 예를 들어 디스크가 열려 있고 현재 클러스터 저장소 디스크로서 사용 중인 경우, AIX 운영 체
제는 디스크에서 예약 정책을 설정하지 못하도록 차단합니다. 이로 인해 저장소에 대한 다른 클러스터 노드의 액
세스가 유실됩니다.
모든 MPIO 장치가 지원해야 하는 필수 장치 속성은 reserve_policy입니다. 일반적으로 다중 경로 장치에는
PR_key_value 장치 속성이 있습니다. 다중 경로 장치에는 추가로 장치 특성 속성이 있을 수 있습니다. 다른 장
치 특성 속성은 다음과 같습니다.
FC3_REC
장치가 파이버 채널 클래스 3을 사용하는 오류 복구를 켜야 하는지 여부를 나타냅니다. 이 기능을 사용으로
설정하면 파이버 채널과 관련된 Fabric 오류의 특정 유형에 대해 오류 발견과 오류 복구가 향상됩니다. 이 속
성은 장치의 제한된 세트에서만 사용 가능합니다. 이 속성에는 다음 값이 사용될 수 있습니다.
true
파이버 채널 클래스 3을 사용하는 오류 복구를 사용합니다.
false
파이버 채널 클래스 3 오류 복구를 사용하는 오류 복구를 사용 안함으로 설정합니다.
reserve_policy
장치가 열릴 때 예약 방법이 사용되는지 여부를 정의합니다. 값은 다음과 같습니다.
no_reserve
장치에 예약 방법을 적용하지 않습니다. 다른 호스트 시스템에 있을 수도 있는 다른 개시자가 장치에 액
세스할 수 있습니다.
single_path
예약을 실행한 개시자만 장치에 액세스할 수 있음을 의미하는 SCSI2 예약 방법을 장치에 적용합니다. 이
정책은 동일한 호스트 또는 다른 호스트에 있는 다른 개시자가 장치에 액세스하지 못하게 합니다. 이 정
책은 SCSI2 예약을 사용하여 단일 개시자(경로)로만 장치를 잠그므로 다른 경로를 통해 라우트된 명령이
있으면 예약 충돌이 발생하게 됩니다.
여러 경로로 명령을 번갈아 사용하는 경로 선택 알고리즘을 사용할 경우, single_path 값이 선택되면
혼선이 생깁니다. 예를 들어, 장치 고유 PCM의 필수 속성이 여러 경로에 걸쳐 입출력을 분배하는 값으로
설정되어 있다고 가정해 보십시오. single_path가 사용될 경우, 디스크 드라이버가 버스 장치 재설정
(BDR)을 실행한 후 다음 명령 전송 시 새로운 경로를 사용하여 예약을 실행함으로써 이전 예약을 취소해
야 합니다. 다른 경로가 선택될 때마다 혼선이 발생하게 되고, 멀티부트로 BDR을 전송하고 예약을 실행
하는 오버헤드로 인해 성능이 저하됩니다. AIX PCM을 사용할 경우, 이러한 혼선을 야기시킬 수 있는 알
고리즘은 선택할 수 없습니다.
PR_exclusive
장치가 열릴 때 SCSI3 영구 예약, 독점 호스트 방법을 적용합니다. PR_key_value 속성값은 호스트 시
스템마다 고유해야 합니다. PR_key_value 속성은 다른 호스트 시스템의 개시자가 장치에 액세스하지
못하도록 하는 데 사용됩니다.
PR_shared
장치가 열릴 때 SCSI3 영구 예약, 공유 호스트 방법을 적용합니다. PR_key_value 값은 호스트 시스템
마다 고유해야 합니다. 다른 호스트 시스템의 개시자가 장치에 액세스하려면 먼저 등록해야 합니다.
장치 관리 171
PR_key_value
장치가 영구 예약 정책(PR_exclusive 또는 PR_shared)을 지원하는 경우에만 필수입니다.
rw_timeout 및 min_rw_to
rw_timeout 속성은 스토리지 장치에서 명령을 실행할 때마다 SCSI 명령을 완료하도록 허용되는 시간(초)
을 지정합니다. MPIO 환경에서 명령은 다른 경로로 재시도되므로 둘 이상의 시간종료를 경험할 수 있습니
다.
파이버 채널 접속 디스크의 AIX에 포함되는 디스크 ODM에서는 rw_timeout에 대해 디폴트 값 30초를 사
용합니다. 일부 장치의 경우 AIX에서는 rw_timeout 속성을 1초 정도로 낮게 설정할 수 있습니다.
AIX에서는 일부 MPIO FC 접속 디스크에 대해 고유한 특수 유형 disk/fcp/mpioosdisk를 사용합니다.
이 고유 유형은 다양한 스토리지 장치 모델에 사용되며, rw_timeout 속성에 대해 허용되는 최소 값의 경우
요구사항이 다를 수 있습니다. 결과적으로 이러한 유형의 디스크에서는 해당 특정 디스크의 실제 최소 시간
종료 값을 지정하는 min_rw_to 속성이 있습니다.
예를 들어 lsattr -Rl hdisk5 -a rw_timeout 명령은 hdisk5에서 rw_timeout 값으로 10초가
허용됨을 표시할 수 있습니다. 그러나 min_rw_to 속성 값은 rw_timeout 속성에 대해 다른 높은 최소 값
을 제공할 수 있습니다. IBM 이외의 벤더가 제공하는 스토리지 장치를 사용 중인 경우 스토리지 벤더로부터
ODM 패키지를 확보하여 설치하십시오. 스토리지 벤더의 ODM 패키지에는 rw_timeout 속성에 대해 허용
되는 것과 다른 범위의 값이 있을 수 있습니다.
rw_max_time
이 속성은 각 입출력 조작을 완료하기 위해 MPIO 장치에 소요되는 대략적인 최대 시간(초)을 지정합니다. 시
간은 입출력 요청이 디스크 드라이버에 발행될 때부터 디스크 드라이버가 호출 프로세스에 대해 입출력 요청
을 리턴할 때까지 측정됩니다. 이 속성은 디스크가 논리적 볼륨 관리자(LVM) 미러링 구성과 같은 불필요한
구성의 일부인 경우 사용될 수 있습니다. 이 속성이 설정되고 입출력 조작에서 명령 시간종료와 같은 오류가
발견되면 정상적인 재시도 조작 모두를 완료하기 전에 입출력 조작이 실패할 수 있습니다. 그러므로 이 속성
에서는 보다 빠른 중복성을 제공합니다.
이 속성이 디폴트 값 0으로 설정되면, 디스크 드라이버 및 PCM(Path Control Module)은 재시도 카운터의 임
계값에 도달할 때까지 입출력 조작을 재시도합니다. 재시도 입출력 조작에서는 오류 수 및 디스크 구성에 따
라 시간이 다소 소요될 수 있습니다. rw_max_time 속성이 0이 아닌 값으로 설정되고 io_thrshld_tmr
속성을 제공하는 파이버 채널 어댑터를 사용하는 경우 최고의 결과를 위해서는 io_thrshld_tmr 속성을
yes로 설정하십시오.
io_thrshld_tmr
io_thrshld_tmr 속성은 FC 드라이버의 오류 복구를 위한 임계치 타이머입니다. 이 파이버 채널(FC) 입출
력 속성은 명령 시간종료 처리를 통해 FC 장치 드라이버 제어를 개선합니다. 이 속성에 대해 유효한 값은 다
음과 같습니다.
예
입출력 임계치 속성을 사용으로 설정합니다. 이 속성을 사용으로 설정하면, FC 장치 드라이버의 보류 큐
에서 입출력 조작을 모니터하는 임계치 타이머가 FC 장치 드라이버에서 시작됩니다. rw_timeout 초
(SCSI 장치 드라이버에서 지정한 최대 읽기/쓰기 시간종료) 이상 입출력 조작이 보류 중이면 FC 장치 드
라이버는 SCSI 장치 드라이버에 필요한 상태로 해당 입출력 조작을 완료합니다. SCSI 장치 드라이버는
SCSI 장치 드라이버가 FC 장치 드라이버로 전송 중인 각 입출력 조작에 대한 rw_timeout 속성을 제어
합니다.
no
입출력 임계치 속성을 사용 안함으로 설정합니다. 이것이 기본값입니다.
FC SCSI 장치의 오류 복구를 사용으로 설정하려면 다음 명령을 입력하십시오.
# chdev -U -l fscsi0 -a io_thrshld_tmr=yes
여기서 FC SCSI 장치 인스턴스는 fscsi0입니다.

FC SCSI 장치의 오류 복구를 사용 안함으로 설정하려면 다음 명령을 입력하십시오.
# chdev -U -l fscsi0 -a io_thrshld_tmr=no
여기서 파이버 채널 SCSI 장치 인스턴스는 fscsi0입니다.

io_thrshld_tmr 속성은 FC SCSI 장치 인스턴스 fscsi0이 열려 있고 사용 중인 동안 속성을 업데이트할
수 있음을 의미하는 동시 업데이트를 지원합니다.
경로 제어 모듈 속성
AIX 디폴트 경로 제어 모듈(PCM) 외에도 장치 공급업체에서 장치 고유의 PCM을 제공할 수 있습니다. 사용자가
변경할 수 있는 속성 세트는 장치 벤더에서 정의합니다. 장치 고유 PCM은 장치 및 경로 속성을 가질 수 있습니다.
다음은 AIX 디폴트 PCM의 장치 속성입니다.
algorithm
장치의 여러 경로 간에 입출력이 분배되는 방법을 결정합니다. 이 알고리즘 속성의 값은 다음과 같습니다.
참고: 일부 장치는 이러한 값의 서브세트만을 지원합니다.
fail_over
모든 I/O 조작을 단일 경로로 보냅니다. 경로가 실패나 사용 안함으로 표시되는 경우, 모든 I/O 조작을 전
송하기 위해 사용 가능한 다음 경로가 선택됩니다. 이 알고리즘은 경로 우선순위 속성의 오름차순 값을
기반으로 정렬된 목록에서 사용 가능한 모든 경로를 유지보수합니다. 가장 낮은 경로 우선순위 값이 있는
유효한 경로가 각 I/O 조작을 위해 선택됩니다.
round_robin
I/O 조작을 여러 사용 가능한 경로에 분배합니다. 활성 또는 수동 경로 또는 선호 또는 비선호 경로가 있
는 장치의 경우 경로의 서브세트만이 I/O 조작에 사용됩니다. 경로가 실패나 사용 안함으로 표시되는 경
우, 더 이상 I/O 조작을 전송하는 데 사용되지 않습니다. I/O 조작은 경로 우선순위 속성을 기반으로 분배
됩니다. 더 높은 경로 우선순위가 있는 경로가 I/O 조작의 더 많은 비중을 수신합니다.
shortest_queue
I/O 조작을 여러 사용 가능한 경로에 분배합니다. 활성 또는 수동 경로 또는 선호 또는 비선호 경로가 있
는 장치의 경우 경로의 서브세트만이 I/O 조작에 사용됩니다. 이 알고리즘은 round_robin 알고리즘과
유사합니다. 그러나, shortest_queue 알고리즘은 각 경로에서 보류 중인 I/O 조작의 수를 기반으로
I/O 조작을 분배합니다. 현재 보류 중인 I/O 조작 수가 가장 적은 경로가 다음 조작을 위해 선택됩니다. 경
로 우선순위 속성은 알고리즘이 shortest_queue로 설정될 때 무시됩니다.
hcheck_mode
건강성 검사 기능이 사용될 때 어떤 경로를 검사해야 하는지를 판별합니다. 속성은 다음 모드를 지원합니다.
enabled
사용 가능한 상태가 있는 경로를 통해 healthcheck 명령을 전송합니다. 모드는 사용 안함이거나 누락
된 상태인 경로를 통해서는 healthcheck 명령을 전송하지 않습니다.
failed
실패한 상태가 있는 경로를 통해 healthcheck 명령을 전송합니다. 모드는 사용, 사용 안함 또는 누락
된 상태에 있는 경로를 통해서는 healthcheck 명령을 전송하지 않습니다.
nonactive
(디폴트) 실패 또는 사용 상태인 경로를 포함하여 활성 I/O가 없는 경로를 통해서 장치에 healthcheck
명령을 전송합니다. 모드는 사용 안함이거나 누락된 상태인 경로를 통해서는 healthcheck 명령을 전
송하지 않습니다.
hcheck_interval
장치의 경로에서 건강성 검사가 수행될 간격을 정의합니다. 속성은 범위 0 - 3600초를 지원합니다. 0을 선택
하면 건강성 검사가 사용되지 않습니다.
참고: 디스크가 일부 프로세스에 의해 열리고 아직 닫히지 않은 경우에만 건강성 검사를 수행합니다. 엔터티
에 열린 디스크가 없는 경우에는 경로 제어 모듈은 해당 장치의 hcheck_interval 속성이 0이 아닌 값으로 설
정되더라도 경로를 검사하지 않습니다.
dist_tw_width
"시간 창"의 지속 기간을 정의합니다. 이는 분배된 오류 검출 알고리즘이 오류를 리턴하는 I/O를 계산하는 동
안의 시간 프레임입니다. dist_tw_width 속성의 측정 단위는 밀리초입니다. 이 속성값을 줄이면 각 샘플을
사용하는 기간이 줄어들고 알고리즘 민감도가 작은 입출력 오류 분할로 줄어듭니다. 이 속성값을 늘리면 알
고리즘 민감도가 작은 오류 분할로 늘어나고 경로가 실패할 가능성이 늘어납니다.
장치 관리 173
dist_err_percent
성능 저하로 인해 경로에서 실패가 발생하기 전까지 경로에 허용되는 "시간 창"의 오류 발생 비율을 정의합니
다. dist_err_percent은 범위 0 - 100이 있습니다. 분배된 오류 검출 알고리즘은 속성이 영(0)으로 설정
되면 사용 안함으로 설정됩니다. 기본 설정은 0입니다. 분배된 오류 검출 알고리즘은 장치를 오류 때문에 어
댑터에 연결하는 Fabric을 샘플링합니다. 알고리즘은 오류가 있는 샘플의 백분율을 계산하고 계산된 값이
dist_err_percent 속성값보다 큰 경우 경로가 실패합니다.
다음은 AIX PCM의 경로 속성입니다.
경로 우선순위
알고리즘이 경로 리스트에서 작용하는 방식을 수정합니다.
알고리즘 속성값이 fail_over인 경우 경로는 리스트에서 유지됩니다. 이 리스트의 순서는 어떤 경로가 먼저
선택되는지와, 경로가 실패한 경우 어떤 경로를 다음에 선택할지를 판별합니다. 순서는 경로 우선순위 속성
의 값으로 판별됩니다. 가장 높은 우선순위는 1입니다. 여러 개의 경로가 동일한 우선순위 값을 가질 수는 있
지만 모든 경로의 값이 동일할 경우, 각 경로가 구성된 시점을 기준으로 경로가 선택됩니다.
알고리즘 속성값이 round_robin이면, 경로 우선순위 알고리즘이 각 경로에 우선순위 값을 지정합니다. 경
로는 경로 우선순위에 비례하여 I/O 조작을 위해 선택됩니다. 그러므로 우선순위 값이 높은 경로는 더 많은
I/O 조작을 위해 선택됩니다. 모든 경로 우선순위가 같으면 경로가 동일하게 선택됩니다.
cntl_hcheck_int
제어기 건강성 검사 순서는 스토리지 Fabric 전송 실패가 발견된 후에 시작됩니다. cntl_delay_time 속
성은 제어기 건강성 검사 순서가 활성일 때 최대 지속 시간(초)을 판별합니다. 제어기 건강성 검사 명령이 성
공적으로 완료되어 사용 가능한 경로를 발견한 다음에는 I/O가 재개하도록 허용하는 제어기 건강성 검사 순
서가 종료됩니다. 제어기 건강성 검사 순서가 종료된 후에, 어떤 경로도 양호한 것으로 발견되지 않은 경우에
는 모든 보류 중 및 장치에 대한 후속 I/O는 장치 건강성 검사기가 실패한 경로가 리턴됨을 발견할 때까지 실
패합니다.
제어기 건강성 검사 순서가 활성인 동안에는, cntl_hcheck_interval 속성은 다음 번 세트 제어기 건강
성 검사 명령이 발행될 때의 기간(초)입니다. cntl_hcheck_interval 속성은 0 또는 사용 안함으로 설정
되는 경우가 아니면 cntl_delay_time 미만이어야 합니다. cntl_delay_time 또는
cntl_hcheck_interval이 0으로 설정된 경우 기능은 사용 안함으로 설정됩니다.
cntl_delay_time
제어기 건강성 검사 순서는 스토리지 Fabric 전송 실패가 발견된 후에 시작됩니다. cntl_delay_time 속
성은 제어기 건강성 검사 순서가 활성일 때 최대 지속 시간(초)을 판별합니다. 제어기 건강성 검사 명령이 성
공적으로 완료되어 사용 가능한 경로를 발견한 다음에는 I/O가 재개하도록 허용하면서 제어기 건강성 검사
순서가 종료됩니다. 제어기 건강성 검사 순서가 종료된 후에, 어떤 경로도 양호한 것으로 발견되지 않은 경우
에는 모든 보류 중 및 장치에 대한 후속 I/O는 장치 건강성 검사기가 실패한 경로가 리턴됨을 발견할 때까지
실패합니다.
제어기 건강성 검사 순서가 활성인 동안에는, cntl_hcheck_interval 속성은 다음 번 세트 제어기 건강성 검
사 명령이 발행될 때의 기간(초)입니다. cntl_hcheck_interval 속성은 0으로 설정되거나 사용 안함으로 설
정되지 않는 한 cntl_delay_time 미만이어야 합니다. cntl_delay_time 또는 cntl_hcheck_interval이 0으
로 설정된 경우 기능은 사용 안함으로 설정됩니다.
timeout_policy
명령 시간종료와 전송 오류로 인해 PCM의 작동을 조정합니다. timeout_policy가 fail_path 또는
disable_path로 설정된 경우, 장치에 대한 일부 경로에서 다중 경로 입출력(MPIO) 장치에 간헐적 스토리지
영역 네트워크(SAN) Fabric 문제가 발생할 때 성능 저하가 발생할 수도 있습니다. timeout_policy 속성에는
다음 값이 있습니다.
retry_path
경로에서 명령 시간종료의 첫 번째 발생은 즉각적인 경로 실패를 초래하지 않습니다. 전송 문제점으로 인
해 실패한 경로가 건강성 검사에 의해 복구되면 복구된 경로는 즉시 사용할 수 있습니다.
fail_path
경로 그룹에서 마지막 경로가 아니라고 가정할 때 경로가 명령 시간종료의 첫 번째 발생 시에 실패합니
다. 전송 문제점으로 인해 실패한 경로가 복구하는 경우, 해당 경로에서 기간이 실패 없이 만료될 때까지
경로는 읽기 또는 쓰기 I/O 조작에 사용되지 않습니다. 이 기능이 사용 가능하면 읽기 또는 쓰기 I/O가 전
송 오류로부터 복구된 경로로 라우팅되기 전까지 지연이 발생할 수도 있습니다.

fail_ctrl
이 설정을 사용하면 MPIO가 선호 제어기에서 비선호 제어기로 더 빨리 전환됩니다. 이 설정을 사용하지
않으면 MPIO가 선호 제어기에서 비선호 제어기로 전환하기 전에 선호 제어기에 대한 모든 경로가 실패
합니다. 이 설정을 사용하면 선호 제어기에 대한 두 경로에 오류가 있을 때 MPIO가 전환됩니다. 이 설정
은 fail_path 설정과 유사합니다.
disable_path
경로 그룹에서 마지막 경로가 아니라고 가정할 때 경로가 명령 시간종료의 첫 번째 발생 시에 실패합니
다. 전송 문제점으로 인해 실패한 경로가 복구하는 경우, 해당 경로에서 기간이 실패 없이 만료될 때까지
경로는 읽기 또는 쓰기 I/O 조작에 사용되지 않습니다. 이 경로가 기간 동안 계속해서 여러 명령 시간종료
를 경험하는 경우 이는 사용 안함으로 설정될 수도 있습니다. 사용 안함으로 설정된 경로는 다음 조치 중
하나를 수행할 때까지 사용 안함(또는 사용할 수 없는) 상태로 남아 있습니다. chpath 명령을 실행하여
사용 안함으로 설정된 경로를 사용으로 설정하기, 영향 받은 디스크를 재구성하기 또는 시스템 재부팅하
기.
SAN 복제 속성
AIX 다중 경로 입출력(MPIO)가 설치되어야 하고 장치는 AIX 경로 제어 모듈(PCM)을 사용 중이어야 합니다. 이
러한 속성은 스토리지 서브시스템이 제공하는 설정과 기능에 대해 종속성이 있습니다.
다음 AIX 속성은 스토리지 서브시스템을 통해 복제되는 논리 장치 번호(LUN)의 작동과 관련됩니다. 모든 스토리
지 서브시스템 또는 마이크로코드 레벨이 이러한 속성을 지원하지 않을 수도 있습니다. PowerHA SystemMirror
과 같은 고가용성 소프트웨어 또는 클러스터링이 클러스터에서 노드 간에 스토리지 영역 네트워크(SAN) 복제의
관리를 조정하기 위해 설치되었습니다. 다음 속성은 Virtual I/O Server(VIOS)에서 변경할 수 없습니다.
san_rep_cfg
피어 투 피어 원격 복사(PPRC)를 사용 중인 동기 장치가 AIX 운영 체제에 정의되고 구성되는 방법을 판별합
니다. 디스크 인스턴스의 unique_id 값은 이 속성의 영향을 받고 속성값이 변경되는 경우 변경될 수도 있습
니다. san_rep_cfg 속성은 스토리지 서브시스템에서 PPRC 장치의 상태를 변경하지 않습니다. 속성에는 다
음 값이 있습니다.
none [Default]
PPRC를 별도의 논리적 디스크 인스턴스로 사용 중인 동기 장치에서 LUN을 구성합니다.
new
PPRC를 단일 논리적 인스턴스로서 사용 중인 동기 장치를 정의하고 구성합니다. 장치는 기존 디스크 인
스턴스가 PPRC 장치에서 LUN과 일치하지 않는 경우에만 정의되고 구성됩니다.
new_and_existing
PPRC를 단일 논리적 인스턴스로서 사용 중인 동기 장치를 정의하고 구성합니다. 논리적 디스크 인스턴
스가 PPRC 장치를 나타내지 않는 경우에는 새 디스크 인스턴스가 정의됩니다.
migrate_disk
PPRC를 단일 hdisk 인스턴스로서 사용 중인 동기 장치를 정의 및 구성하고 해당 장치에 선택된 논리적
디스크 인스턴스를 사용합니다. 조작은 san_rep_device 속성이 지원됨 또는 발견됨으로 설정된 장치에
서만 지원됩니다. 대상 장치에 san_rep_device 속성이 지원되는 것으로 설정된 경우에는 조작은 디스
크가 마지막으로 구성된 후에 SAN 복제가 스토리지에서 설정된 경우에만 작동합니다. 이 조작은 장치가
클러스터 내에서 저장소 디스크로서 사용되지 않는 경우 열려 있고 AIX 운영 체제에 의해 사용 중인 디스
크에서 지원됩니다. 영향 받은 디스크의 unique_id 값은 PPRC 장치의 ID를 반영하기 위해 갱신됩니
다.
revert_disk
PPRC 논리적 디스크 인스턴스를 사용 중인 기존 동기 장치를 비PPRC 장치 hdisk 인스턴스로 구성합니
다. 이 조작은 san_rep_device 속성이 예로 설정된 장치에서만 지원됩니다. 논리적 장치 이름 및 목표
디스크 인스턴스의 특수 파일은 변경되지 않고 남아 있습니다. SAN 복제 장치의 1차(소스) LUN은 복귀
된 hdisk 인스턴스에 사용됩니다. 1차(소스) LUN을 찾을 수 없거나 호스트에 알려지지 않은 경우에는 2
차(대상) LUN이 복귀된 hdisk 인스턴스에 사용됩니다. 이 조작은 장치가 클러스터 내에서 저장소 디스크
로서 사용되지 않는 경우 열려 있고 AIX 운영 체제에 의해 사용 중인 디스크에서 지원됩니다. 영향 받은
디스크의 unique_id 값은 LUN ID를 반영하기 위해 갱신됩니다.
none, new 및 new_and_existing 값은 동일한 ODM(Object Data Manager) 고유 유형의 모든 장치의 작동
을 갱신함을 의미합니다. chdef 명령은 none, new 및 new_and_existing 값을 설정하는 데 사용됩니다.
chdef 명령은 지정된 ODM 고유 유형의 모든 장치에 대한 속성의 디폴트 값을 갱신합니다. chdef 명령은
장치 관리 175
또한 이미 정의된 기존 장치 인스턴스의 속성값을 갱신합니다. chdef 명령이 실행 중일 때 이미 구성된 장치
의 경우, 변경사항은 시스템이 재부트하거나 이러한 장치가 구성 해제된 후 재구성될 때까지 적용되지 않습
니다. chdef 명령에는 클래스, 서브클래스 및 속성의 유형이 필요합니다. san_rep_cfg 속성의 ODM 고유
유형을 판별하려면 lsattr –l hdisk# -F class,subclass,type 명령을 사용하십시오. 예를 들어
다음과 같습니다.
lsdev –l hdisk0 –F class,subclass,type

disk,fcp,aixmpiods8k
chdef –a san_rep_cfg=none –c disk –s fcp –t aixmpiods8k
chdef –a san_rep_cfg=new –c disk –s fcp –t aixmpiods8k
chdef –a san_rep_cfg=new_and_existing –c disk –s fcp –t aixmpiods8k
migrate_disk 및 revert_disk 값은 단일 및 지정된 장치 인스턴스의 작동을 갱신하기 위한 것입니다.

chdev 명령은 지정된 장치에 대해 migrate_disk 또는 revert_disk 값을 설정하는 데 사용되어야 합니다.
chdev 명령은 지정된 장치의 값만을 갱신합니다. 예를 들어 다음과 같습니다.
chdev -a san_rep_cfg=migrate_disk -l hdisk0

chdev -a san_rep_cfg=revert_disk -l hdisk0
san_rep_device
논리적 디스크 인스턴스가 SAN 복제 장치로서 정의됨을 나타냅니다. 이 속성은 디스크 구성 동안에 설정되
고, 장치의 상태가 디스크가 구성된 이후로 변경된 경우 효력이 상실될 수도 있습니다. 속성에는 다음 값이 있
습니다.
no
장치가 AIX 운영 체제에서 SAN 복제 장치로서 구성되지 않았습니다. 이 장치가 SAN 복제 장치로서 구성
되기 위한 요구사항을 충족하지 않습니다.
지원됨
장치가 AIX 운영 체제에서 SAN 복제 장치로서 구성되지 않았습니다. 이 장치가 SAN 복제 장치로서 구성
되기 위한 요구사항을 충족합니다. 그러나 현재 스토리지 서브시스템에서 SAN 복제 장치로서 설정되지
않았습니다.
발견됨
장치가 AIX 운영 체제에서 SAN 복제 장치로서 구성되지 않았습니다. AIX 운영 체제가 이 장치가 SAN 복
제 장치로서 구성되기 위한 요구사항을 충족하고 현재 스토리지 서브시스템에서 SAN 복제 장치로서 설
정되었음을 발견했습니다.
예
장치가 AIX 운영 체제에서 SAN 복제 장치로서 구성되었습니다.
통신 어댑터 제거
핫 플러그 어댑터를 제거하거나 대체하려면 먼저 어댑터 구성을 해제해야 합니다.
통신 어댑터 구성을 해제하는 작업에는 다음 태스크가 포함됩니다.
• 제거하거나 대체할 어댑터를 사용 중인 모든 애플리케이션 닫기
• 어댑터에 연결된 모든 장치가 식별되어 정지되었는지 확인
• 현재 사용 중인 모든 슬롯 또는 특정 어댑터가 삽입된 슬롯 나열
• 어댑터의 슬롯 위치 식별
• 네트워크 인터페이스 리스트에서 인터페이스 정보 표시 및 제거
• 어댑터를 사용 불가능하게 만들기
다음 프로시저로 통신 어댑터를 구성 해제하려면 루트로 로그인해야 합니다.
이더넷, 토큰 링, FDDI 및 ATM 어댑터 구성 해제

이더넷, 토큰 링, FDDI 또는 ATM 어댑터의 구성을 해제하려면 다음 단계를 수행하십시오.
1. lsslot -c pci를 입력하여 시스템에 있는 모든 핫 플러그 슬롯을 나열하고 슬롯의 특성을 표시하십시오.
2. 다음 예제와 같이 적절한 SMIT 명령을 입력하여 설치된 어댑터를 나열하고 시스템 장치에 있는 모든 장치의
현재 상태를 표시하십시오.

항목 설명
smit lsdenet 이더넷 어댑터를 나열합니다.
smit lsdtok 토큰 링 어댑터를 나열합니다.
smit ls_atm ATM 어댑터를 나열합니다.
어댑터 유형에 따라 다음과 같은 이름 붙이기 규칙이 사용됩니다.
항목 설명
이름 어댑터 유형
atm0, atm1, ... ATM 어댑터
ent0, ent1, ... 이더넷 어댑터
tok0, tok1, ... 토큰 링 어댑터
3. 구성을 해제할 어댑터를 사용 중인 모든 애플리케이션을 닫으십시오.
이 절차를 계속하려면 시스템에서 네트워크 덤프 위치를 사용할 수 없어야 합니다. 네트워크 덤프 위치를 찾
아서 사용 불가능하게 만들려면 다음을 수행하십시오.
a) 명령행에서 다음을 입력하십시오.
smit dump
b) 현재 덤프 장치 표시를 선택하십시오.
c) 구성된 덤프 장치에 네트워크 위치가 표시되는지 확인하십시오.
네트워크 위치가 표시되지 않으면 SMIT를 종료하십시오. 이제 4단계를 수행할 준비가 되었습니다. 덤프
장치를 로컬 위치로 변경하려면 취소를 선택하거나 F3 키를 눌러 다음 단계를 계속하십시오.
d) 1차 덤프 장치에 네트워크 위치가 표시되면, 1차 덤프 장치 변경을 선택하고 1차 덤프 장치 필드에 로컬 위
치를 입력하여 로컬 위치로 변경하십시오.
e) 2차 덤프 장치에 네트워크 위치가 표시되면, 2차 덤프 장치 변경을 선택하고 2차 덤프 장치 필드에 로컬 위
f) 완료되면, 확인을 누르거나 Enter를 누르십시오.
4. netstat -i를 입력하여 구성된 모든 인터페이스 리스트를 표시하고 TCP/IP에 맞게 어댑터가 구성되었는
지 확인하십시오. 다음과 같은 출력이 표시됩니다.
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16896 link#1 076 0 118 0 0
lo0 16896 127 127.0.0.1 076 0 118 0 0
lo0 16896 ::1 076 0 118 0 0
tr0 1492 link#2 8.0.5a.b8.b.ec 151 0 405 11 0
tr0 1492 19.13.97 19.13.97.106 151 0 405 11 0
at0 9180 link#3 0.4.ac.ad.e0.ad 0 0 0 0 0
at0 9180 6.6.6 6.6.6.5 0 0 0 0 0
en0 1500 link#5 0.11.0.66.11.1 212 0 1 0 0
en0 1500 8.8.8 8.8.8.106 212 0 1 0 0
토큰 링 어댑터는 인터페이스를 하나만 사용할 수 있습니다. 이더넷 어댑터는 인터페이스를 두 개 사용할 수

있습니다. ATM 어댑터는 인터페이스를 여러 개 사용할 수 있습니다.
5. 다음 예제와 같이 적절한 ifconfig 명령을 입력하여 네트워크 인터페이스 리스트에서 인터페이스를 제거
하십시오.
항목 설명
ifconfig en0 detach 표준 이더넷 인터페이스를 제거합니다.
ifconfig et0 detach IEEE 802.3 이더넷 인터페이스를 제거합니다.
ifconfig tr0 detach 토큰 링 인터페이스를 제거합니다.
ifconfig at0 detach ATM 인터페이스를 제거합니다.
장치 관리 177
6. 다음 예제와 같이 적절한 rmdev 명령을 입력하여 어댑터 구성을 해제하고 사용자 조정된 장치 오브젝트 클래
스에 있는 해당 장치 정의는 그대로 보관하십시오.
항목 설명
rmdev -l ent0 이더넷 어댑터의 구성을 해제합니다.
rmdev -l tok1 토큰 링 어댑터의 구성을 해제합니다.
rmdev -l atm1 ATM 어댑터의 구성을 해제합니다.
rmdev -p pci1 사용자 조정된 장치 오브젝트 클래스에 장치 정의는 그대로 유지하면서 PCI
버스의 하위와 이들 아래에 있는 다른 모든 장치의 구성을 해제합니다.
참고: 어댑터의 구성을 해제하고 사용자 조정된 장치 오브젝트 클래스에 있는 장치 정의를 제거하려면 -d 플
래그와 함께 rmdev 명령을 사용하십시오.
주의: 어댑터를 대체하는 것이 아니라 제거하는 것이 목표인 경우가 아니면, 시스템 가동 중 어댑터 교
체 작업을 수행할 경우 rmdev 명령에 -d 플래그를 사용하지 마십시오.
WAN 어댑터 구성 해제
WAN 어댑터의 구성을 해제할 수 있습니다.
WAN 어댑터의 구성을 해제하려면 다음을 수행하십시오.
2. 다음 예제와 같이 적절한 SMIT 명령을 입력하여 설치된 어댑터를 나열하고 시스템 장치에 있는 모든 장치의
현재 상태를 표시하십시오.
항목 설명
smit 331121b9_ls 2-Port Multiprotocol WAN 어댑터를 나열합니다.
smit riciophx_ls ARTIC WAN 어댑터를 나열합니다.
어댑터 유형에 따라 다음과 같은 이름 붙이기 규칙이 사용됩니다.
이름 어댑터 유형
dpmpa 2-포트 멀티프로토콜 어댑터
riciop ARTIC960 어댑터
smit dump
네트워크 위치가 표시되지 않으면 SMIT를 종료하십시오. 이제 아래의 5단계를 수행할 준비가 되었습니
다. 덤프 장치를 로컬 위치로 변경하려면 취소를 선택하거나 F3 키를 눌러 다음 단계를 계속하십시오.
4. 다음 표에 나오는 명령을 사용하여 이들 어댑터의 장치 드라이버와 에뮬레이터 포트의 구성을 해제하고 제거
하십시오.

이름 2-포트 멀티프로토콜 어댑터
smit rmhdlcdpmpdd 장치 구성을 해제합니다.
smit rmsdlcscied SDLC COMIO 구성을 해제합니다.
이름 ARTIC960Hx PCI 어댑터

smit rmtsdd 장치 드라이버의 구성을 해제합니다.
smit rmtsdports MPQP COMIO 에뮬레이션 포트를 제거합니다.
IBM 4-Port 10/100 Base-TX 이더넷 PCI 어댑터 구성 해제

4-Port 10/100 Base-TX 이더넷 PCI 어댑터는 4개의 이더넷 포트를 사용합니다. 어댑터를 제거하려면 먼저 각
포트의 구성을 해제해야 합니다.
2. smit lsdenet을 입력하여 PCI 서브클래스에 있는 모든 장치를 나열하십시오.
다음과 유사한 메시지가 표시됩니다.
ent1 Available 1N-00 IBM 4-Port 10/100 Base-TX Ethernet PCI Adapter (23100020) (Port 1)

smit dump
4. netstat -i를 입력하여 구성된 모든 인터페이스 리스트를 표시하고 TCP/IP에 맞게 어댑터가 구성되었는
지 확인하십시오.
다음과 같은 출력이 표시됩니다.
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lo0 16896 link#1 076 0 118 0 0
lo0 16896 127 127.0.0.1 076 0 118 0 0
lo0 16896 ::1 076 0 118 0 0
tr0 1492 link#2 8.0.5a.b8.b.ec 151 0 405 11 0
tr0 1492 19.13.97 19.13.97.106 151 0 405 11 0
at0 9180 link#3 0.4.ac.ad.e0.ad 0 0 0 0 0
at0 9180 6.6.6 6.6.6.5 0 0 0 0 0
en0 1500 link#5 0.11.0.66.11.1 212 0 1 0 0
en0 1500 8.8.8 8.8.8.106 212 0 1 0 0
이더넷 어댑터는 인터페이스를 두 개 사용할 수 있습니다. 예를 들어, et0과 en0이라는 두 개의 인터페이스

를 사용할 수 있습니다.
5. ifconfig 명령을 사용하여 네트워크 인터페이스 리스트에서 각 인터페이스를 제거하십시오.
장치 관리 179
예를 들어, 표준 이더넷 인터페이스를 제거하려면 iconfig en0 detach를 입력하고, IEEE 802.3 인터페
이스를 제거하려면 iconfig et0을 입력하십시오.
6. rmdev 명령을 사용하여 어댑터의 구성을 해제하고 장치 정의는 사용자 조정된 장치 오브젝트 클래스에 그대
로 유지하십시오.
예를 들어, rmdev -l ent0을 입력하십시오.
참고: 어댑터의 구성을 해제하고 사용자 조정된 장치 오브젝트 클래스에 있는 장치 정의를 제거하려면 -d 플
래그와 함께 rmdev 명령을 사용하십시오.
주의: 어댑터를 대체하는 것이 아니라 제거하는 것이 목표인 경우가 아니면, 시스템 가동 중 어댑터 교
체 작업을 수행할 경우 rmdev 명령에 -d 플래그를 사용하지 마십시오.
ATM 어댑터 구성 해제
어댑터를 제거하려면 먼저 LAN 에뮬레이트된 각 장치의 구성을 해제해야 합니다.
기존의 IP 및 LAN 에뮬레이션 프로토콜은 ATM 어댑터에서 실행될 수 있습니다. LAN 에뮬레이션 프로토콜을 이
용하면 ATM 네트워크에 에뮬레이트된 LAN을 구현할 수 있습니다. 에뮬레이트된 LAN은 이더넷/IEEE 802.3, 토
큰 링/IEEE 802.5 및 MPOA(MultiProtocol Over ATM)입니다.
LAN 인터페이스를 제거하려면 다음을 수행하십시오.
1. lsslot -c pci를 입력하여 시스템에 있는 모든 핫 플러그 슬롯을 나열하고 슬롯의 특성을 표시하십시
오.
2. smit ls_atm을 입력하여 모든 ATM 어댑터를 나열하십시오.
.
.
atm0 Available 04-04 IBM PCI 155 Mbps ATM Adapter (14107c00)
atm1 Available 04-06 IBM PCI 155 Mbps ATM Adapter (14104e00)
3. smit listall_atmle를 입력하여 어댑터의 LAN 에뮬레이트된 클라이언트를 모두 나열하십시오.

ent1 Available ATM LAN Emulation Client (Ethernet)
tok1 Available ATM LAN Emulation Client (Token Ring)
tok2 Available ATM LAN Emulation Client (Token Ring)
모든 ATM 어댑터에서 여러 개의 에뮬레이트된 클라이언트가 실행될 수 있습니다.

4. smit listall_mpoa를 입력하여 어댑터의 LAN 에뮬레이트된 클라이언트를 모두 나열하십시오.
mpc0 Available ATM LAN Emulation MPOA Client
atm0과 atm1은 물리적 ATM 어댑터입니다. mpc0은 MPOA 에뮬레이트된 클라이언트입니다. ent1, ent2,
ent3, tok1 및 tok2는 LAN 에뮬레이트된 클라이언트입니다.
5. entstat을 입력하여 클라이언트가 실행되고 있는 어댑터를 확인하십시오.
-------------------------------------------------------------
ETHERNET STATISTICS (ent1) :
Device Type: ATM LAN EmulationATM Hardware Address: 00:04:ac:ad:e0:ad
.
.
.
ATM LAN Emulation Specific Statistics:
--------------------------------------
Emulated LAN Name: ETHelan3
Local ATM Device Name: atm0
Local LAN MAC Address:
.
.

smit dump
d) 1차 덤프 장치에 네트워크 위치가 표시되면, 1차 덤프 장치 변경을 선택하고 1차 덤프 장치 필드에 로컬
위치를 입력하여 로컬 위치로 변경하십시오.
e) 2차 덤프 장치에 네트워크 위치가 표시되면, 2차 덤프 장치 변경을 선택하고 2차 덤프 장치 필드에 로컬
위치를 입력하여 로컬 위치로 변경하십시오.
7. rmdev -l device 명령을 사용하여 다음 순서대로 인터페이스의 구성을 해제하십시오.
• 에뮬레이트된 인터페이스 = en1, et1, en2, et2, tr1, tr2 ...
• 에뮬레이트된 인터페이스 = ent1, ent2, tok1, tok2 ...
• MPOA(Multiprotocol Over ATM) = mpc0
• ATM 어댑터 = atm0
8. 사용자 조정된 장치 오브젝트 클래스에 장치 정의는 그대로 유지하면서 SCSI 어댑터 scsi1과 모든 하위 어
댑터의 구성을 해제하려면 다음을 입력하십시오.
rmdev -R scsi1

rmt0 Defined
hdisk1 Defined
scsi1 Defined
9. 사용자 조정된 장치 오브젝트 클래스에 장치 정의는 그대로 유지하면서 SCSI 어댑터 scsi1의 하위 어댑터
만 구성을 해제하려면 다음을 입력하십시오.
rmdev -p scsi1

rmt0 Defined
hdisk1 Defined
10. 사용자 조정된 장치 오브젝트 클래스에 장치 정의는 그대로 유지하면서 PCI 버스 pci1의 하위와 이들 아래
에 있는 다른 모든 장치의 구성을 해제하려면 다음을 입력하십시오.
rmdev -p pci1

rmt0 Defined
hdisk1 Defined
scsi1 Defined
ent0 Defined
스토리지 어댑터 구성 해제
스토리지 어댑터를 제거 또는 교체하기 전에 먼저 해당 어댑터를 구성 해제해야 합니다.
이러한 태스크를 수행하려면 루트 사용자로 로그인해야 합니다.
장치 관리 181
다음 단계는 SCSI 및 파이버 채널 스토리지 어댑터를 구성 해제합니다.
스토리지 어댑터 구성 해제에는 다음 태스크가 포함됩니다.
• 제거하거나 대체하거나 이동할 어댑터를 사용 중인 모든 애플리케이션 닫기
• 파일 시스템 마운트 해제
• 상위 및 하위 장치를 사용 불가능하게 만들기
SAS, SCSI, NVMe 및 파이버 채널 어댑터 구성 해제
스토리지 어댑터는 일반적으로 디스크 또는 테이프 드라이브와 같은 미디어 장치의 상위 장치입니다. 상위 장치
를 제거하려면 상위 장치에 연결된 모든 하위 장치를 제거하거나 정의된 상태로 만들어야 합니다.
SCSI와 파이버 채널 어댑터를 구성 해제하려면 다음 단계를 수행하십시오.
2. lsslot-c pci를 입력하여 시스템 장치의 모든 핫 플러그 슬롯을 나열하고 해당 특성을 표시하십시오.
3. lsdev -C를 입력하여 시스템에 있는 모든 장치의 현재 상태를 나열하십시오.
4. umount를 입력하여 이 어댑터를 사용 중인, 이전에 마운트된 파일 시스템, 디렉토리 또는 파일을 마운트 해
제하십시오. 자세한 정보는 JFS 또는 JFS2 마운트를 참조하십시오.
5. rmdev -l adapter -R을 입력하여 어댑터를 사용 불가능하게 만드십시오.
주의: 시스템 가동 중 어댑터 교체 작업을 수행할 경우 rmdev 명령에 -d 플래그를 사용하지 마십시오.
이 플래그를 사용하면 구성이 제거됩니다.
비동기 어댑터 구성 해제
비동기 어댑터의 구성을 해제할 수 있습니다.
이러한 태스크를 수행하려면 루트 사용자로 로그인해야 합니다.
다음은 비동기 어댑터의 구성을 해제하는 단계입니다.
비동기 어댑터를 제거하거나 대체하려면 먼저 어댑터 구성을 해제해야 합니다. 비동기 어댑터 구성을 해제하는
작업에는 다음 태스크가 포함됩니다.
• 제거하거나 대체하거나 이동할 어댑터를 사용 중인 모든 애플리케이션 닫기
• 상위 및 하위 장치를 사용 불가능하게 만들기
프로시저
비동기 어댑터를 대체하거나 제거하려면 먼저 어댑터 및 어댑터가 제어하는 모든 장치의 구성을 해제해야 합니
다. 장치 구성을 해제하려면 해당 장치를 사용 중인 모든 프로세스를 종료해야 합니다. 다음 단계를 수행하십시
오.
2. lsslot-c pci를 입력하여 시스템 장치의 모든 핫 플러그 슬롯을 나열하고 해당 특성을 표시하십시오.
3. lsdev -C -c tty를 입력하여 시스템 장치에서 사용 가능한 모든 tty 장치와 모든 장치의 현재 상태를 나
열하십시오.
4. lsdev -C -c printer를 입력하여 어댑터에 연결된 모든 프린터 및 플로터 장치를 나열하십시오.

5. rmdev 명령을 사용하여 어댑터를 사용 불가능하게 만드십시오.
주의: 시스템 가동 중 어댑터 교체 작업을 수행할 경우 rmdev 명령에 -d 플래그를 사용하지 마십시오.
이 플래그를 사용하면 구성이 제거됩니다.
입출력 장치 문제점 해결
장치 문제가 발생하는 원인을 확인할 수 있습니다.
장치 소프트웨어 확인
다음을 수행하여 장치 소프트웨어 문제를 정정하십시오.
• 오류 로그 확인
• 모든 장치 나열
• 장치 상태 확인
• 장치 속성 확인
• 장치 속성 변경
• 다른 애플리케이션에서 장치 사용
• 신규 장치 정의
오류 로그 확인
오류 로그를 확인하여 장치, 장치 어댑터 또는 장치를 사용하는 애플리케이션에 대해 오류가 기록되었는지 확인
하십시오. 이 확인 작업을 수행하는 것에 대한 자세한 정보를 보려면 오류 로깅 기능으로 이동하십시오. 프로시저
를 완료한 후 이 단계로 돌아오십시오.
장치 문제가 해결되었는지 확인하십시오.
앞의 방법으로 문제를 해결할 수 없는 경우, 다음 단계인 장치 나열로 이동하여 모든 장치를 나열하십시오.
장치 나열
lsdev -C 명령을 사용하여, 정의되거나 사용 가능한 모든 장치를 나열하십시오. 이 명령은 시스템에 있는 모든
장치의 특성을 보여 줍니다.
장치가 장치 리스트에 있으면 다음 단계인 장치 상태 확인으로 이동하여 장치 상태를 확인하십시오.
장치가 장치 리스트에 없으면 아래의 신규 장치 정의를 참조하여 신규 장치를 정의하십시오.
장치 상태 확인
lsdev -C 명령으로 생성된 리스트에서 장치를 찾으십시오. 장치가 Available 상태인지 확인하십시오.
장치가 Available 상태이면 다음 단계인 장치 속성 확인으로 이동하여 장치 속성을 확인하십시오.
장치가 Available 상태가 아니면 아래의 신규 장치 정의를 참조하여 신규 장치를 정의하십시오.
장치 속성 확인
lsattr -E -l DeviceName 명령을 사용하여 장치의 속성을 나열하십시오.
lsattr 명령은 시스템에 있는 장치에 사용할 수 있는 값과 장치의 속성을 보여 줍니다. 특정 장치의 설정값이 올
바른지 확인하려면 장치 관련 문서를 참조하십시오.
장치 속성이 올바르게 설정되어 있으면 아래의 다른 애플리케이션에서 장치 사용을 참조하십시오.
장치 속성이 올바르게 설정되어 있지 않으면 다음 단계인 장치 속성 변경으로 이동하십시오.
장치 속성 변경
chdev -l Name -a Attribute=Value 명령을 사용하여 장치 속성을 변경하십시오.
장치 관리 183
chdev 명령은 사용자가 -l Name 플래그로 지정한 장치의 특성을 변경합니다.
속성을 변경한 후에도 문제가 해결되지 않으면 다음 단계인 다른 애플리케이션에서 장치 사용으로 이동하십시
오.
다른 애플리케이션에서 장치 사용
다른 애플리케이션에서 장치를 사용해 보십시오. 다른 애플리케이션에서는 장치가 올바르게 작동할 경우, 처음
사용했던 애플리케이션에 문제가 있을 수 있습니다.
다른 애플리케이션에서는 장치가 올바르게 작동할 경우, 처음 사용했던 애플리케이션에 문제가 있을 수 있습니
다. 소프트웨어 서비스 담당자에게 문제를 보고하십시오.
다른 애플리케이션에서도 장치가 올바르게 작동하지 않으면 다음 단계인 신규 장치 정의로 이동하십시오.
신규 장치 정의
참고: mkdev 명령을 사용하려면 루트 사용자 권한을 가지고 있거나 보안 그룹의 멤버여야 합니다.
mkdev 명령을 사용하여 시스템에 장치를 추가하십시오.
mkdev 명령은 신규 장치를 정의 및 사용 가능하게 만들거나 이미 정의된 장치를 사용 가능하게 만들 수 있습니
다. -c, -s 및 -t 플래그를 조합하여, 사전 정의된 장치를 고유하게 식별할 수 있습니다.
장치를 정의한 후에도 문제가 해결되지 않으면 장치를 정치하고 서비스 담당자에게 문제를 보고하거나 진단 프
로그램을 사용하여 장치를 테스트할 수 있습니다.
장치 연결 상태 확인
장치 연결 상태를 확인하려면 다음 단계를 수행하십시오.
1. 콘센트에 전원이 들어오는지 확인하십시오.
2. 장치 전원 케이블에 장치 및 콘센트에 올바르게 연결되어 있는지 확인하십시오.
3. 장치 신호 케이블이 장치 및 시스템 장치의 올바른 연결 위치에 올바르게 연결되어 있는지 확인하십시오.
4. SCSI 장치의 경우, SCSI 터미네이터가 올바르게 연결되어 있고 SCSI 주소 설정이 올바른지 확인하십시오.
5. 통신 장치의 경우, 장치가 통신 회선에 올바르게 연결되어 있는지 확인하십시오.
6. 장치가 켜져 있는지 확인하십시오.
특정 장치의 케이블 연결 및 구성 절차와 추가 문제점 해결 정보는 관련 문서를 참조하십시오.
이 주제의 단계에서 문제점이 해결되지 않으면 다음 단계로 이동하십시오.
어댑터 제거 문제 해결
어댑터 구성을 해제하기 위해 rmdev 명령을 사용할 때 어댑터가 열려 있으면 오류 메시지가 표시될 수 있습니다.
어댑터 구성을 해제하기 위해 rmdev 명령을 사용할 때 다음 유형의 메시지가 표시될 경우, 제거하거나 대체하려
고 하는 어댑터에 응용프로그램이 계속해서 액세스하려고 하여 장치가 열려 있음을 나타냅니다.
#rmdev -l ent0
Method error (/usr/lib/methods/ucfgent):
0514-062
Cannot perform the requested function because the
specified device is busy.
이 문제를 해결하려면 이 어댑터를 사용하려고 하는 애플리케이션을 찾아서 애플리케이션을 닫아야 합니다. 다

음과 같은 애플리케이션이 포함될 수 있습니다.
• TCP/IP
• SNA
• OSI
• IPX/SPX
• Novell NetWare
• Streams

• GDLC(일반 데이터 링크 제어)
– IEEE 이더넷 DLC
– 토큰 링 DLC
– FDDI DLC
SNA(Systems Network Architecture) 애플리케이션
어댑터를 사용 중일 수 있는 SNA 애플리케이션은 다음과 같습니다.
• DB2®
• TXSeries®(CICS® & Encina)
• DirectTalk
• MQSeries®
• HCON
• ADSM
스트림 애플리케이션
어댑터를 사용 중일 수 있는 스트림 기반 애플리케이션은 다음과 같습니다.
• IPX/SPX
• Novell NetWare V4 및 Novell NetWare Services 4.1
• 이 운영 체제용 연결 및 NetBios
WAN 어댑터에서 실행 중인 애플리케이션
WAN 어댑터를 사용 중일 수 있는 애플리케이션은 다음과 같습니다.
• SDLC
• Bisync
• ISDN
TCP/IP 애플리케이션
인터페이스 레이어를 사용 중인 모든 TCP/IP 애플리케이션은 ifconfig 명령으로 검색할 수 있습니다. 이 명령
은 TCP/IP를 사용 중인 애플리케이션이 시간종료되도록 하고 인터페이스가 작동 중지되었음을 사용자에게 알립
니다. 어댑터를 추가하거나 대체한 후 ifconfig 명령을 사용하여 인터페이스를 연결하면 애플리케이션이 다시
시작됩니다.
장치의 준비 상태 확인
장치가 준비 상태에 있는지 확인할 수 있습니다.
장치가 준비 상태에 있는지 확인하려면 다음을 수행하십시오.
1. 장치의 준비 표시기가 켜져 있는지 확인하십시오.
2. 테이프, 디스켓 및 광 장치와 같은 이동식 매체가 올바르게 삽입되어 있는지 확인하십시오.
3. 프린터 및 플로터의 리본, 용지 공급 장치 및 토너 공급 장치를 확인하십시오.
4. 장치에 쓰려는 경우, 쓰기 미디어가 쓰기 가능 상태인지 확인하십시오.
장치의 준비 상태를 확인한 후 문제가 해결되었는지 확인하십시오. 장치의 준비 상태를 확인해도 문제점이 정정
되지 않으면 다음 단계로 이동하십시오.
장치 진단 프로그램
장치에 결함이 있는지 확인하려면 하드웨어 진단 프로그램을 실행하십시오.
실행 중인 하드웨어 진단 프로그램이 장치의 문제점을 찾지 못하면 장치 소프트웨어를 확인하십시오. 장치가 진
단 테스트에 통과할 경우, 장치와 시스템 소프트웨어 간의 상호 작동 방식에 문제가 있을 수도 있습니다. 이와 같
은 가능성이 있는 경우에는 소프트웨어 서비스 부서에 이 문제를 보고하십시오.
장치 관리 185
목표 디바이스 구성
cfgmgr 명령은 입출력 디바이스의 목표 구성의 제한된 범위에 대한 연결 옵션으로서 -c 플래그와 함께 사용될
수 있습니다.
FC와 FCoE 장치의 대상 구성

cfgmgr -c 옵션은 대상 구성에 파이버 채널(FC) 및 FCoE(Fibre Channel over Ethernet) 어댑터와 함께 사용됩
니다.
cfgmgr 명령은 장치 구성의 제한된 범위에 대한 연결 옵션으로서 -c 플래그와 함께 사용될 수 있습니다. FC 및
FCoE 어댑터의 경우 구문은 다음과 같습니다.
cfgmgr -l fscsi0 -c "parameter=val[,parameter=val,...]"
연결 필터 문자열을 사용하여 하나 이상의 다음 매개변수를 사용하여 장치 발견의 범위를 제한할 수 있습니다.
표 10. cfgmgr -c 플래그의 매개변수
매개변수 이름 설명
ww_name 목표 장치 월드 와이드 포트 이름
node_name 목표 장치 월드 와이드 노드 이름
scsi_id FCP(Fibre Channel Protocol) 스토리지 장치를 위해 SCSI(Small Computer System
Interface) ID에 맵핑되는 목표 장치 N_Port ID입니다.
lun_id 논리적 장치 번호(LUN)
예를 들어, 다음 명령은 월드 와이드 포트 이름 0x5001738000330191이 있는 스토리지 대상 포트에서

lun_id 0x1000000000000의 단일 LUN을 구성합니다.
# cfgmgr -l fscsi0 -c "ww_name=0x5001738000330191,lun_id=0x1000000000000"
이 스캔은 fscsi0 호스트 어댑터 포트에서만 발생합니다.

참고:
• 매개변수 값에서 선행 문자 0x는 선택사항입니다.
• 모든 매개변수는 16진 숫자로 표시되어야 합니다.
다음 예에서는 단 하나의 매개변수만이 지정됩니다.
# cfgmgr -l fscsi0 -c "lun_id=0x1000000000000"
이 명령은 스토리지 영역 네트워크(SAN)에서 모든 스토리지 장치 포트를 스캔하고 이 LUN이 존재하는 모든 SAN

대상 포트에 대해 이 단일 논리 장치를 구성합니다.
연결 필터 매개변수를 위한 지침 및 규칙
연결 필터 매개변수를 사용할 때 다음 사항을 고려하십시오.
• FC 및 FCoE 장치의 대상 구성은 스위치 연결 환경에만 적용됩니다. 대상 포트에 직접 연결되는 연결 문자열을
지정하는 경우에는 연결은 하위 장치를 찾을 수 없다는 메시지와 함께 실패합니다.
• -c 플래그는 명령의 범위를 한 번에 하나의 fscsiX 장치로만 제한하는 cfgmgr 명령의 -l 플래그와 함께할
때에만 지원됩니다.
• -?를 -v 플래그와 함께 cfgmgr 명령의 -c 플래그에 대한 연결 문자열로서 지정하는 경우 사용 정보가 표시됩
니다.
• 중복 매개변수를 지정하는 경우(예를 들어, 두 번 나열된 lun_id), 오류가 발생합니다. 장치가 발견되지 않습
니다.

• lun_id, scsi_id, ww_name 및 node_name 매개변수의 어떤 조합도 허용되지만 중복은 제외합니다. 구성
할 LUN, 대상 또는 스토리지 노드를 고유하게 식별하려면 하나 또는 되도록이면 두 개의 매개변수를 지정해야
합니다(더 많은 수도 허용되긴 함). 다음 리스트는 LUN, 대상 또는 스토리지 노드를 고유하게 식별하기 위해 필
요한 매개변수 또는 매개변수의 조합을 지정합니다.
– ww_name 및 lun_id 매개변수는 구성할 대상 포트에서 LUN을 고유하게 식별합니다.
– scsi_id 및 lun_id 매개변수는 구성할 대상 포트에서 LUN을 고유하게 식별합니다.
– node_name 및 lun_id 매개변수는 특정 스토리지 노드에 대해 모든 대상 포트의 LUN을 구성합니다. 이러
한 매개변수는 모든 대상 포트에 동일한 node_name 매개변수가 있는 경우에만(일부 스토리지 장치에서는
참일 수 있음) 대상 포트를 구성할 수 있습니다.
– ww_name 매개변수는 특정 대상에 대해 모든 LUN을 구성합니다.
– node_name 매개변수는 모든 대상 포트에 동일한 node_name 매개변수가 있는 경우에만(일부 스토리지
장치에서는 참일 수 있음) 특정 스토리지 노드에 대해 모든 대상 포트를 구성할 수 있습니다.
– lun_id 매개변수는 해당 fscsi 장치에서 표시되는 모든 대상 포트에 LUN을 구성합니다.
• 둘 이상의 매개변수가 지정된 경우에는 장치 구성 코드는 장치 위치의 유효성을 검증하기 위해 이 추가 정보를
사용합니다. 지정된 매개변수 값이 SAN에서 보고된 값과 충돌하면 명령은 실패하고 장치가 구성되지 않습니
다.
테이프 드라이브
다음은 테이프 드라이브와 관련된 시스템 관리 기능에 대한 설명입니다.
이러한 여러 기능은 시스템의 장치에 대한 정보가 들어 있는 장치 구성 데이터베이스에서 정보를 변경하거나 가
져옵니다. 장치 구성 데이터베이스는 시스템에 지원되는 모든 유형의 장치에 대한 정보가 들어 있는 사전 정의된
구성 데이터베이스 및 현재 시스템의 특정 장치에 대한 정보가 들어 있는 사용자 조정 구성 데이터베이스로 구성
됩니다. 테이프 드라이브 또는 기타 장치를 사용하는 운영 시스템의 경우 장치는 사용자 조정 구성 데이터베이스
에 정의되어야 하며 장치 유형은 사전 정의된 구성 데이터베이스에 정의되어야 합니다.
테이프 드라이브 속성
다음과 같은 테이프 드라이브 속성을 시스템의 요구에 맞게 조정할 수 있습니다.
속성은 SMIT 또는 명령을 사용하여 표시하거나 변경할 수 있습니다(특히, lsattr 및 chdev 명령).
테이프 드라이브의 각 유형은 모든 속성의 일부분만 사용합니다.
각 속성에 대한 일반 정보
블록 크기
블록 크기 속성은 테이프를 읽거나 쓸 때 사용할 블록 크기를 나타냅니다. 데이터는 블록 사이에 레코드 간 간
격이 있는 데이터 블록으로 테이프에 기록됩니다. 형식화되지 않은 테이프에 쓸 경우 테이프에서 레코드 간
간격이 줄어들어 더 많은 데이터를 기록할 수 있기 때문에 대용량 레코드가 유용합니다. 값 0은 가변 길이 블
록을 나타냅니다. 허용되는 값과 디폴트 값은 테이프 드라이브에 따라 다릅니다.
장치 버퍼
chdev 명령을 사용하여 장치 버퍼 속성을 mode=yes로 설정하면 데이터가 테이프 드라이브의 데이터 버퍼
로 전송된 후 애플리케이션에 쓰기 완료를 통지하지만 실제로 데이터가 테이프에 기록된 후에 항상 통지하는
것은 아닙니다. mode=no를 지정하면 실제로 데이터가 테이프에 기록된 후에만 애플리케이션에 쓰기 완료
를 통지합니다. 이 속성을 mode=no 값으로 설정하면 읽기 또는 쓰기 시 스트리밍 모드를 유지할 수 없습니
다. 디폴트 값은 mode=yes입니다.
mode=no 값으로 설정하면 테이프 드라이브는 느려지지만 정전 또는 시스템 장애 시 완전한 데이터가 더 많
으므로 미디어 끝 조건을 더 잘 처리할 수 있습니다.
확장된 파일 표시
확장된 파일 표시 속성(chdev 명령의 경우 extfm 속성)을 no 값으로 설정하면 파일 표시가 기록될 때마다
정규 파일 표시가 테이프에 기록됩니다. 이 속성을 yes 값으로 설정하면 확장 파일 표시가 기록됩니다. 테이
프 드라이브의 경우 이 속성을 on으로 설정할 수 있습니다. 기본값은 no입니다. 예를 들어, 8mm 테이프 드
장치 관리 187
라이브에서 확장된 파일마크는 2.2MB의 테이프를 사용하고 쓰는 데 최대 8.5초가 걸릴 수 있습니다. 정규 파
일 표시는 184KB를 사용하며 쓰는 데 약 1.5초 걸립니다.
8mm 테이프를 첨가 모드에서 사용할 때 오류를 줄이려면 파일 표시에서 역 조작 후 보다 나은 위치 지정을
위해 확장 파일 표시를 사용하십시오.
리텐션(Retension)
리텐션(Retension) 속성을(chdev 명령의 경우, ret 속성) ret=yes로 설정하면 테이프 드라이브가 테이프
가 삽입되거나 드라이브가 재설정될 때마다 자동으로 테이프를 리텐션(Retension)합니다. 리텐션
(Retension)이란 테이프 장력을 고르게 하기 위해 테이프의 끝까지 감았다가 처음으로 되감는 것을 의미합니
다. 테이프를 리텐션(Retension)하면 오류를 줄일 수 있지만 이 조치는 몇 분 정도 걸릴 수 있습니다. ret=no
값을 지정하면 테이프 드라이브는 테이프를 자동으로 재인장하지 않습니다. 기본값은 yes입니다.
밀도 설정 #1 및 밀도 설정 #2
밀도 설정 #1(chdev 명령의 경우 density_set_1 속성)은 특수 파일 /dev/rmt*, /dev/
rmt*.1, /dev/rmt*.2 및 /dev/rmt*.3을 사용할 때 테이프 드라이브가 기록하는 밀도 값을 설정합니
다. 밀도 설정 #2(chdev의 경우 density_set_2 속성)는 특수 파일 /dev/rmt*.4, /dev/
rmt*.5, /dev/rmt*.6 및 /dev/rmt*.7을 사용할 때 테이프 드라이브가 기록하는 밀도 값을 설정합니
다. 자세한 정보는 197 페이지의 『테이프 드라이브용 특수 파일 』의 내용을 참조하십시오.
밀도 설정은 0 - 255 범위의 10진수로 표시됩니다. 0으로 설정하면 일반적으로 드라이브의 고밀도 설정인
디폴트 테이프 드라이브 밀도가 선택됩니다. 허용되는 특정 값과 그 의미는 테이프 드라이브의 유형에 따라
다릅니다. 이러한 속성은 테이프 드라이브가 지원하는 모든 밀도로 기록된 테이프를 읽는 테이프 드라이브의
능력에 영향을 미치지 않습니다. 일반적으로 밀도 설정 #1을 테이프 드라이브의 최고 밀도로 설정하고 밀도
설정 #2를 테이프 드라이브의 두 번째 높은 밀도로 설정합니다.
예약 지원
예약 속성(chdev 명령의 경우 res_support 속성)을 사용하는 테이프 드라이브의 경우
res_support=yes 값을 지정하면 테이프 드라이브가 열려 있는 동안 SCSI 버스에 예약됩니다. 두 개 이상
의 SCSI 어댑터가 테이프 장치를 공유하면 장치가 열려 있는 동안 단일 어댑터에 의해 액세스될 수 있습니다.
일부 SCSI 테이프 드라이브는 reserve 또는 release 명령을 지원하지 않습니다. 일부 SCSI 테이프 드라이브
에는 reserve 또는 release 명령을 항상 지원하기 위해 이 속성에 대해 사전 정의된 값이 있습니다.
가변 길이 블록 크기
가변 길이 블록 크기 속성(chdev 명령의 경우 var_block_size 속성)은 가변 길이 레코드를 기록할 때 테
이프 드라이브에 필요한 블록 크기를 지정합니다. 일부 SCSI 테이프 드라이브의 경우에는 가변 길이 레코드
를 기록할 때에도 모드 선택 데이터에 제로가 아닌 블록 크기를 지정해야 합니다. 블록 크기 속성은 가변 길
이 레코드를 나타내는 0으로 설정됩니다. 필수 속성인지 여부를 판별하려면 특정 테이프 드라이브 SCSI 스
펙을 참조하십시오.
데이터 압축
데이터 압축 속성(chdev 명령의 경우 compress 속성)을 compress=yes로 설정하면 테이프 드라이브는
압축 모드가 됩니다(드라이브가 데이터 압축을 지원하는 경우 ). 그럴 경우 드라이브는 데이터를 테이프에 압
축 형식으로 기록하여 추가 데이터가 단일 테이프에 포함될 수 있도록 합니다.이 속성을 no로 설정하면 테이
프 드라이브가 원시 모드(압축되지 않음)로 기록됩니다. 읽기 조작은 이 속성 설정의 영향을 받지 않습니다.
디폴트 설정은 yes입니다.
자동 로더
자동 로더 속성(chdev 명령의 경우 autoload 속성)을 autoload=yes로 설정하면 드라이브가 설치된 경
우 자동 로더가 활성화됩니다. 그럴 경우 로더에서 다른 테이프를 사용할 수 있으면 테이프를 테이프 끝까지
이동시키는 읽기 또는 쓰기 조작이 자동으로 다음 테이프에서 계속됩니다. 단일 테이프 카트리지로 제한되는
테이프 드라이브 명령은 영향을 받지 않습니다. 디폴트 설정은 yes입니다.
재시도 지연
재시도 지연 속성은 명령 실패 후 시스템이 명령을 재수행할 때까지 기다리는 시간(초)을 설정합니다. 시스템
은 실패한 명령을 네 번까지 재수행할 수 있습니다. 이 속성은 유형 OST 테이프 드라이브에만 적용됩니다. 디
폴트 설정은 45입니다.

읽기/쓰기 제한시간
READ/WRITE 속성에 대한 읽기/쓰기 제한시간 또는 최대 지연은 시스템이 읽기 또는 쓰기 명령을 완료하는
데 걸리는 최대 시간(초)을 설정합니다. 이 속성은 유형 OST 테이프 드라이브에만 적용됩니다. 디폴트 설정
은 144입니다.
테이프 변경 시 오류 리턴
테이프 변경 시 오류 리턴 또는 재설정 속성이 설정되면 테이프 드라이브를 재설정하거나 테이프를 변경한
경우 열 때 오류가 리턴됩니다. 닫을 때 테이프 위치를 테이프 시작 부분 이후로 유지하는 테이프 드라이브의
이전 조작 때문일 수 있습니다. 리턴되는 오류는 -1이고 errno는 EIO으로 설정됩니다. 애플리케이션에 표
시된 오류 조건은 해제됩니다. 또한 테이프 드라이브 자체를 재구성하면 오류 조건이 지워집니다.
2.0GB 4mm 테이프 드라이브(유형 4mm2gb)의 속성

다음은 2.0GB 4mm 테이프 드라이브(유형 4mm2gb)의 속성입니다.
블록 크기
디폴트 값은 1024입니다.
장치 버퍼
이 속성의 일반 정보는 이 테이프 장치 유형에 적용됩니다.
고정 값을 가지는 속성
테이프 드라이브가 2.0GB 4mm 테이프 드라이브로 구성되는 경우 리텐션(Retension), 예약 지원, 가변 길이
블록 크기, 밀도 설정 #1 및 밀도 설정 2 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다. 테이프
장치는 항상 2.0GB 모드에서 쓰므로 밀도 설정이 사전 정의되어 있습니다.

블록 크기
장치 버퍼
사용자는 이 드라이브의 밀도 설정을 변경할 수 없습니다. 다음과 같이 설치된 DDS(Digital Data Storage) 미
디어 유형에 따라 장치가 스스로를 자동으로 다시 구성합니다.
매체 유형 장치 구성
DDS 읽기 전용입니다.
DDS |||| 2.0GB 모드에서만 읽기/쓰기입니다.
DDS2 두 밀도 모두에서 읽기와 4.0GB 모드에서만 쓰기입니다.
비DDS 지원되지 않습니다. 카트리지가 배출됩니다.
데이터 압축
테이프 드라이브가 4.0GB 4mm 테이프 드라이브로 구성되는 경우 리텐션(Retension), 가변 길이 블록 크기,
밀도 설정 #1 및 밀도 설정 2 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
2.3GB 8mm 테이프 드라이브(유형 8mm)

다음은 2.3GB 8mm 테이프 드라이브(유형 8mm)의 속성입니다.
블록 크기
디폴트 값은 1024입니다. 값이 작을수록 테이프에 저장되는 데이터의 양이 줄어듭니다.
장치 버퍼
장치 관리 189
테이프 드라이브가 2.3GB 8mm 테이프 드라이브로 구성되는 경우 리텐션(Retension), 예약 지원, 가변 길이
블록 크기, 데이터 압축, 밀도 설정 #1 및 밀도 설정 2 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없
습니다. 테이프 장치는 항상 2.3GB 모드에서 쓰므로 밀도 설정이 사전 정의되어 있습니다.

블록 크기
디폴트 값은 1024입니다. 2.3GB 모드에서 테이프에 쓰는 경우 값이 작을수록 테이프에 저장되는 데이터의
양이 줄어듭니다.
장치 버퍼
다음 설정이 적용됩니다.
설정 의미
140 5GB 모드(압축 가능)
21 5GB 모드 압축되지 않은 테이프
20 2.3GB 모드
0 디폴트(5.0GB 모드)
디폴트 값은 밀도 설정 #1의 경우 140이고 밀도 설정 #2의 경우 20입니다. 밀도 설정 #1 또는 #2의 값이

21이면 사용자가 5GB 모드로 압축되지 않은 테이프를 읽거나 쓸 수 있습니다.
데이터 압축
테이프 드라이브가 5.0GB 8mm 테이프 드라이브로 구성되는 경우 리텐션(Retension), 예약 지원 및 가변 길
이 블록 크기 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
20000MB 8mm 테이프 드라이브(자동 구성)의 속성

다음은 20000MB 8mm 테이프 드라이브(자동 구성)의 속성입니다.
블록 크기
장치 버퍼
드라이브가 20.0GB 형식으로 된 데이터 카트리지를 읽고 쓸 수 있습니다. Read 명령 실행 중 이 드라이브는
테이프에 기록되는 형식을 자동으로 결정합니다. Write 명령 실행 중 밀도 설정은 테이프에 기록되는 데이터
형식을 결정합니다.
설정 의미
39 20GB 모드(압축 가능)
0 디폴트(20.0GB 모드)
디폴트 값은 밀도 설정 #1과 밀도 설정 #2에 대해 39입니다.

데이터 압축
테이프 드라이브가 20.0GB 8mm 테이프 드라이브로 구성되는 경우 리텐션(Retension), 예약 지원 및 가변
길이 블록 크기 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
35GB 테이프 드라이브(유형 35gb)의 속성

다음은 35GB 테이프 드라이브(유형 35gb)의 속성입니다.
블록 크기
IBM 7205 M모델 311의 처리량은 블록 크기에 따라 달라집니다. 이 드라이브의 최소 권장 블록 크기는
32KB입니다. 블록 크기가 32KB 미만이면 데이터 비율(백업 또는 복원 시간)이 제한됩니다. 다음 테이블에
서는 권장 블록 크기를 명령별로 보여 줍니다.
지원되는 명령 디폴트 블록 크기(바이트) 권장사항

BACKUP 32K 또는 51.2K(디폴트) Backup이 이름순인지 여부에 따
라 32K 또는 51.2K를 사용합니다.
변경이 필요하지 않습니다.
TAR 10K 매뉴얼에 블록 크기를 512KB라고
한 오류가 있습니다. Blocking
매개변수를 -N64로 설정하십시
오.
MKSYSB BACKUP을 참조하십시오. MKSYSB 명령은 BACKUP 명령을
사용합니다. 변경이 필요하지 않습
니다.
DD 적용되지 않음 Blocking 매개변수를 bs=32K
로 설정하십시오.
CPIO 적용되지 않음 Blocking 매개변수를 -C64로
설정하십시오.
참고: 블록 크기를 선택할 때 용량 및 처리량을 알아야 합니다. 블록 크기가 작을 경우 성능에 상당한 영향을
주지만 용량에는 거의 영향을 주지 않습니다. 2.6GB 형식(밀도) 및 6.0GB 형식(밀도)의 용량은 권장 블록 크
기보다 작은 블록 크기를 사용하는 경우에 영향을 받습니다. 예를 들어, 1024바이트의 블록 크기를 사용하여
32GB의 데이터를 백업하면 약 22시간이 걸립니다. 32KB의 블록 크기를 사용하여 같은 32GB의 데이터를
백업해도 약 2시간이 걸립니다.
장치 버퍼
다음 차트에서는 IBM 7205-311 테이프 드라이브에 지원되는 데이터 카트리지 유형과 밀도 설정(10진수 및
16진수)을 보여 줍니다. 사용자가 복원(읽기) 조작을 수행하면 테이프 드라이브가 기록된 밀도와 일치하도록
밀도를 자동으로 설정합니다. 백업(쓰기) 조작을 수행할 때 사용 중인 데이터 카트리지와 일치하도록 밀도를
설정해야 합니다.
지원되는 데이터 카 원시 용량 압축된 데이터 용량 SMIT 밀도 설정 HEX 밀도 설정

트리지
DLTtape III 2.6GB 2.6GB(압축 없음) 23 17h
6.0GB 6.0 GB(압축 없음) 24 18h
10.0GB 20.0GB(드라이브의 25 19h
디폴트)
장치 관리 191
트리지
DLTtapeIIIxt 15.0GB 30.6GB(드라이브의 25 19h
디폴트)
DLTtapeIV 20.0GB 40.0GB 26 1Ah
35.0GB 70.0GB(드라이브의 27 1Bh
디폴트)
참고: 데이터 카트리지에 지원되지 않는 원시 용량을 요청한 경우 드라이브에 로드되는 데이터 카트리지에
대해 지원되는 값 중 가장 높은 용량이 디폴트 값으로 설정됩니다.
데이터 압축
실제 압축은 쓰여지고 있는 데이터의 유형에 따라 다릅니다(이전 테이블 참조). 이 압축된 데이터 용량에 대
해서는 압축 비율을 2:1로 가정합니다.
150MB 1/4인치 테이프 드라이브(유형 150mb)의 속성

다음은 150MB 1/4인치 테이프 드라이브(유형 150mb)의 속성입니다.
블록 크기
디폴트 블록 크기는 512입니다. 그 외에 유일하게 유효한 블록 크기는 0(가변 길이 블록일 경우)입니다.
장치 버퍼
1/4인치 테이프에 쓰는 작업은 테이프를 시작할 때(BOT) 또는 빈 테이프가 발견된 후에만 수행될 수 있습니
다. 테이프에 데이터가 있는 경우 BOT일 경우를 제외하고는 데이터를 겹쳐쓸 수 없습니다. 이미 기록된 테이
프에 데이터를 추가한 다음 되감으려는 경우에는 다음 파일 표시가 발견되어 시스템에서 오류를 리턴할 때까
지 계속 진행해야 합니다. 그런 다음에만 쓰기를 다시 시작할 수 있습니다.
설정 의미
16 QIC-150
15 QIC-120
0 디폴트(QIC-150) 또는 사용 시스템에 의한 최종 밀도 설정입니다.
디폴트 값은 밀도 설정 #1의 경우 16이고 밀도 설정 #2의 경우 15입니다.

테이프 드라이브가 150MB 1/4인치 테이프 드라이브로 구성되는 경우 확장된 파일 표시, 예약 지원, 가변 길
이 블록 크기 및 데이터 압축 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
525MB 1/4인치 테이프 드라이브(유형 525mb)의 속성

다음은 525MB 1/4인치 테이프 드라이브(유형 525mb)의 속성입니다.
블록 크기
디폴트 블록 크기는 512입니다. 그 외 유효한 블록 크기는 0(가변 길이 블록일 경우)과 1024입니다.
장치 버퍼

설정 의미
17 QIC-525*
16 QIC-150
15 QIC-120
* QIC-525는 1024 블록 크기를 지원하는 유일한 모드입니다.

테이프 드라이브가 525MB 1/4인치 테이프 드라이브로 구성되는 경우 확장된 파일 표시, 예약 지원, 가변 길
이 블록 크기 및 데이터 압축 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
1200MB 1/4인치 테이프 드라이브(유형 1200mb-c)의 속성

다음은 1200MB 1/4인치 테이프 드라이브(유형 1200mb-c)의 속성입니다.
블록 크기
장치 버퍼
설정 의미
21 QIC-1000*
17 QIC-525*
16 QIC-150
15 QIC-120
* QIC-525와 QIC-1000 모드만 1024 블록 크기를 지원합니다.
장치 관리 193
테이프 드라이브가 1200MB 1/4인치 테이프 드라이브로 구성되는 경우 확장된 파일 표시, 예약 지원, 가변
길이 블록 크기 및 데이터 압축 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
12000MB 4mm 테이프 드라이브(자동 구성)의 속성

다음은 12000MB 4mm 테이프 드라이브(자동 구성)의 속성입니다.
블록 크기
IBM 12000MB 4mm 테이프 드라이브의 처리량은 블록 크기에 따라 달라집니다. 이 드라이브의 최소 권장
블록 크기는 32KB입니다. 블록 크기가 32KB 미만이면 데이터 비율(백업 또는 복원 시간)이 제한됩니다. 다
음 테이블에서는 권장 블록 크기를 명령별로 보여 줍니다.
지원되는 명령 디폴트 블록 크기(바이트) 권장사항

BACKUP 32K 또는 51.2K(디폴트) Backup이 이름순인지 여부에 따
라 32K 또는 51.2K를 사용합니다.
변경이 필요하지 않습니다.
TAR 10K 매뉴얼에 블록 크기를 512KB라고
한 오류가 있습니다. Blocking
매개변수를 -N64로 설정하십시
오.
MKSYSB BACKUP을 참조하십시오. MKSYSB 명령은 BACKUP 명령을
사용합니다. 변경이 필요하지 않습
니다.
DD Blocking 매개변수를 bs=32K
로 설정하십시오.
CPIO Blocking 매개변수를 -C64로
설정하십시오.
참고: 블록 크기를 선택할 때 용량 및 처리량을 알아야 합니다. 블록 크기가 작을 경우 성능에 상당한 영향을
주지만 용량에는 거의 영향을 주지 않습니다.
장치 버퍼
다음 차트에서는 IBM 12000MB 4mm 테이프 드라이브에 지원되는 데이터 카트리지 유형과 밀도 설정(10
진수 및 16진수)을 보여 줍니다. 사용자가 복원(읽기) 조작을 수행하면 테이프 드라이브가 기록된 밀도와 일
치하도록 밀도를 자동으로 설정합니다. 백업(쓰기) 조작을 수행할 때 사용 중인 데이터 카트리지와 일치하도
록 밀도를 설정해야 합니다.

트리지
DDS III 2.0GB 4.0GB 19 13h
DDS2 4.0GB 8.0GB 36 24h
DDS3 12.0GB 24.0GB 37 25h
참고: 데이터 카트리지에 지원되지 않는 원시 용량을 요청한 경우 드라이브에 로드되는 데이터 카트리지에
대해 지원되는 값 중 가장 높은 용량이 디폴트 값으로 설정됩니다.
데이터 압축
실제 압축은 쓰여지고 있는 데이터의 유형에 따라 다릅니다(이전 테이블 참조). 이 압축된 데이터 용량에 대
해서는 압축 비율을 2:1로 가정합니다.

13000MB 1/4인치 테이프 드라이브(자동 구성)의 속성

다음은 13000MB 1/4인치 테이프 드라이브(자동 구성)의 속성입니다.
블록 크기
장치 버퍼
설정 의미
33 QIC-5010-DC*
34 QIC-2GB*
21 QIC-1000*
17 QIC-525*
16 QIC-150
15 QIC-120
0 디폴트(QIC-5010-DC)*
* QIC-525, QIC-1000, QIC-5010-DC 및 QIC-2GB 모드만 1024 블록 크기를 지원합니다.

테이프 드라이브가 13000MB 1/4인치 테이프 드라이브로 구성되는 경우 확장된 파일 표시, 예약 지원 및
가변 길이 블록 크기 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
1/2인치 9 트랙 테이프 드라이브(유형 9trk)의 속성

다음은 1/2인치 9 트랙 테이프 드라이브(유형 9trk)의 속성입니다.
블록 크기
디폴트 블록 크기는 1024입니다.
장치 버퍼
설정 의미
3 인치당 6250비트(bpi)
2 1600bpi
0 이전에 사용된 쓰기 밀도
장치 관리 195
테이프 드라이브가 1/2인치 9 트랙 테이프 드라이브로 구성되는 경우 확장된 파일 표시, 리텐션(Retension),
예약 지원, 가변 길이 블록 크기 및 데이터 압축 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
3490e 1/2인치 카트리지(유형 3490e)의 속성

다음은 3490e 1/2인치 카트리지(유형 3490e)의 속성입니다.
블록 크기
디폴트 블록 크기는 1024입니다. 이 드라이브의 특징은 고속 데이터 전송률이므로 드라이브가 효율적으로
작동하는 데 있어 블록 크기가 매우 중요합니다. 블록 크기가 클수록 작업 속도가 빨라지므로 사용 가능한 가
장 큰 블록 크기를 사용해야 합니다.
참고: 블록 크기 값을 늘리면 시스템의 다른 프로그램과 호환되지 않는 원인이 될 수 있습니다. 이러한 문제점
이 발생하면 해당 프로그램을 실행하는 동안 다음과 같은 오류 메시지를 수신합니다.
A system call received a parameter that is not valid.
장치 버퍼
압축
자동 로더
이 드라이브 특징은 카트리지 로더에서 일련의 테이프 카트리지를 순차적으로 로드하고 배출하는 자동 로더
인 테이프 시퀀서입니다. 이 기능이 올바르게 작동하려면 프론트 패널 스위치가 AUTO 위치에 있어야 하고
자동 로더 속성이 yes로 설정되어 있어야 합니다.
기타 SCSI 테이프(유형 ost)의 속성

다음은 기타 SCSI 테이프(유형 ost)의 속성입니다.
블록 크기
시스템 디폴트는 512이지만 해당 테이프 드라이브의 디폴트 블록 크기에 맞게 조정해야 합니다. 일반적인
값은 512와 1024입니다. 8mm와 4mm 테이프 드라이브는 일반적으로 1024를 사용하므로 블록 크기 속성
을 512로 두면 테이프 공간이 낭비됩니다. 값 0은 일부 드라이브에서 가변 블록 크기를 나타냅니다.
장치 버퍼
디폴트 값은 이 두 설정 모두에 대해 0입니다. 기타 값과 해당 의미는 테이프 드라이브에 따라 다릅니다.
예약 지원
디폴트 값은 no입니다. 이 값은 드라이브가 예약/해제 명령을 지원하는 경우에 yes로 설정할 수 있습니다. 이
러한 명령을 지원하는지 여부를 정확하게 모르면 no로 설정하는 것이 안전합니다.
가변 길이 블록 크기
디폴트 가변 길이 블록 크기 값은 0입니다. 0이 아닌 값은 주로 1/4인치 카트리지(QIC) 드라이브에 사용됩니
다. 특정 테이프 드라이브에 대한 정보는 SCSI 스펙을 참조하십시오.
재시도 지연
이 속성은 유형 ost 테이프 드라이브에만 적용됩니다.
읽기/쓰기 제한시간
이 속성은 유형 ost 테이프 드라이브에만 적용됩니다.
테이프 드라이브가 기타 SCSI 테이프 드라이브로 구성되는 경우 확장된 파일 표시, 리텐션(Retension) 및 데
이터 압축 속성은 사전 정의된 값을 가지며 이 값은 변경할 수 없습니다.
MPIO 테이프 속성
MPIO 지원 테이프 장치는 MPIO 장치 속성에 나열된 추가 속성을 가집니다.

테이프 드라이브용 특수 파일
운영 체제에 알려진 각 테이프 드라이브와 연관된 몇 가지 특수 파일이 있습니다.
테이프의 파일에 대해 읽기 및 쓰기 작업을 수행하려면 rmt 특수 파일을 사용해야 합니다. 이러한 특수 파일
은 /dev/rmt*, /dev/rmt*.1, /dev/rmt*.2 - /dev/rmt*.7입니다. rmt*는 rmt0, rmt1 등과 같은 테이
프 드라이브의 논리적 이름입니다.
테이프 드라이브와 연관된 특수 파일 중 하나를 선택하여 테이프 드라이브와 관련된 입출력 조작의 수행 방법을
선택하십시오.
항목 설명
밀도 테이프 드라이브 밀도 설정 #1 또는 테이프 드라이브 밀도 설정 #2를 사용하여
쓸지를 선택할 수 있습니다. 이러한 밀도 설정의 값은 테이프 드라이브의 속성
의 일부입니다. 일반적으로 밀도 설정 #1은 가장 높은 테이프 드라이브 밀도로
설정하고 밀도 설정 #2는 그 다음으로 높은 테이프 드라이브 밀도로 설정하기
때문에 밀도 설정 #1을 사용하는 특수 파일을 고밀도라고 하고 밀도 설정 #2를
사용하는 특수 파일을 저밀도라고 하지만 이 보기가 항상 정확한 것은 아닙니
다. 테이프에서 읽을 때는 밀도 설정이 무시됩니다.
닫을 때 되감기 테이프 드라이브를 참조하는 특수 파일이 닫힐 때 테이프를 되감을 것인지 여부
를 선택할 수 있습니다. 닫을 때 되감기를 선택하면 파일이 닫힐 때 테이프가 테
이프 시작 부분에 위치합니다.
열 때 리텐션(Retension) 파일이 열릴 때 테이프를 리텐션(Retension)할지 여부를 선택할 수 있습니다.
리텐션(Retension)이란 오류를 줄이기 위해 테이프의 끝까지 감았다가 처음으
로 되감는 것을 의미합니다. 열 때 리텐션(Retension)을 선택하면 열기 프로세
스의 일부로 테이프는 테이프의 시작 부분에 위치합니다.
다음 표는 rmt 특수 파일의 이름과 특성을 보여 줍니다.
특수 파일 닫을 때 되감기 열 때 리텐션(Retension) 밀도 설정
/dev/rmt* 예 아니오 #1
/dev/rmt*.1 아니오 아니오 #1
/dev/rmt*.2 예 예 #1
/dev/rmt*.3 아니오 예 #1
/dev/rmt*.4 예 아니오 #2
/dev/rmt*.5 아니오 아니오 #2
/dev/rmt*.6 예 예 #2
/dev/rmt*.7 아니오 예 #2
테이프 드라이브 rmt2의 테이프에 있는 세 개의 파일에 쓴다고 가정합시다. 첫 번째 파일은 테이프 시작 부분에
있고 두 번째 파일은 첫 번째 파일의 뒤에, 세 번째 파일은 두 번째 파일의 뒤에 있습니다. 또한 테이프 드라이브에
밀도 설정 #1을 설정할 경우 다음 특수 파일 리스트를 지정된 순으로 테이프 쓰기에 사용할 수 있습니다.
1. /dev/rmt2.3
2. /dev/rmt2.1
3. /dev/rmt2
이러한 특수 파일을 선택하는 이유는 다음과 같습니다.
• /dev/rmt2.3 파일에는 첫 번째 파일이 테이프의 시작 부분에 위치하도록 하는 열 때 리텐션(Retension)이
있으므로 이 파일이 첫 번째 파일로 선택됩니다. 다음 입출력 조작은 이 파일의 끝 부분에서 시작되므로 닫을
때 되감기는 선택되지 않습니다. 첫 번째 파일이 열릴 때 테이프가 이미 시작 부분에 있는 경우 /dev/rmt2.1
파일을 첫 번째 파일로 사용하면 테이프 리텐션(Retension) 시간이 절약되므로 속도가 더 빨라집니다.
장치 관리 197
• /dev/rmt2.1 파일에서는 열 때 리텐션(Retension)과 닫을 때 되감기가 모두 선택되지 않았으므로 이 파일은
두 번째 파일로 선택됩니다. 파일을 열거나 닫을 때 테이프의 시작 부분으로 이동할 필요가 없습니다.
• /dev/rmt2 파일은 두 번째 파일 뒤에 오기 때문에 열 때 리텐션(Retension)이 필요하지 않으므로 이 파일이
세 번째 즉, 마지막 파일로 선택됩니다. 테이프의 세 번째 파일 이후에는 더 이상 테이프에 쓸 계획이 없으므로
닫을 때 되감기가 선택됩니다. 그 다음의 테이프 사용은 테이프 시작 부분에서 시작됩니다.
특정 rmt 특수 파일을 선택하는 것 외에도 tctl 명령을 사용하여 테이프 조작을 제어할 수 있습니다.
USB 장치 지원
AIX 운영 체제는 USB(Univeral Serial Bus) 장치를 지원합니다.
AIX 운영 체제는 다음 유형의 써드 파티 장치 및 IBM USB 장치를 지원합니다.
• 플래시 드라이브
• 디스크 드라이브
• 광 드라이브(Blu-ray, DVD 및 CD-ROM)
• 테이프 드라이브
• 키보드
• 마우스
• 스피커
참고: AIX 운영 체제는 USB 프린터를 지원하지 않습니다.
일부 써드 파티 USB 장치는 AIX 운영 체제에서 인식하지 못할 수 있습니다. 예를 들어 Power Systems USB 포트
에서 사용할 수 있는 전류가 충분하지 않을 수 있습니다. 그러므로 AIX 운영 체제는 모든 가능한 써드 파티 USB
장치를 지원하지는 않습니다.
USB 플래시 드라이브 지원

기술 레벨 5300-09가 있는 AIX 5.3 및 기술 레벨 6100-02가 있는 AIX 6.1부터 시작하여, 범용 직렬 버스(USB)
플래시 드라이브가 지원됩니다.
이러한 장치에 대한 지원은 다음 장치 패키지에 포함됩니다.
devices.usbif.08025002
USB 플래시 드라이브에 대한 AIX 지원은 산업 표준 OEM USB 플래시 드라이브의 샘플을 기준으로 유효성 확인
됩니다. AIX USB 호스트 제어기의 장치 드라이버는 USB 2.0을 지원합니다. USB 플래시 드라이브는 usbms0 및
usbms1 등과 같은 논리적 이름으로 구성되고, 원시 및 블록 특수 파일 둘 모두를 제공합니다. 예를 들어,
usbms0의 원시 특수 파일은 /dev/rusbms0이고, 블록 특수 파일은 /dev/usbms0입니다. 5300-11 기술 레
벨이 있는 AIX 버전 5.3 및 6100-04 기술 레벨이 있는 AIX 버전 6.1 이전에는 USB 플래시 드라이브는 /dev/
flashdrive0으로서 구성되었습니다.
국제 표준 기구(ISO) 파일 시스템(읽기 전용 ISO 9660)은 이러한 드라이브에서 지원됩니다. tar 명령, cpio 명
령 또는 백업 또는 복원 아카이브를 사용하여 드라이브에서 시스템 백업을 작성할 수 있습니다. dd 명령을 사용
하여 ISO 이미지를 드라이브에 추가할 수도 있습니다.
AIX 운영 체제는 USB 플래시 드라이브에 대한 플러그 앤 플레이를 지원하지 않습니다. AIX 사용자에게 사용 가
능한 플래시 드라이브를 작성하려면 루트 사용자가 드라이브를 시스템 USB 포트에 연결하고 다음 명령을 실행
해야 합니다.
cfgmgr -l usb0
주의: 포트에서 플래시 드라이브를 제거할 때 주의하십시오. 제거하기 전에 드라이브가 적절하게 닫히거
나 마운트 해제되지 않은 경우 드라이브의 데이터가 손상될 수 있습니다.
드라이브를 제거한 후에는 루트 사용자가 다음 명령을 실행할 때까지 오브젝트 데이터 관리자(ODM)에서 사용
가능한 상태로 남아 있습니다.

rmdev -l usbmsn
드라이브가 사용 가능 상태에 있을 때 시스템에 다시 연결하고 다시 열거나 마운트할 수 있습니다. 드라이브가 여

전히 사용자에게 열려 있는 동안 시스템 USB 포트에서 연결 해제되면, 해당 드라이브는 사용자가 이를 닫은 후
다시 열 때까지 재사용할 수 없습니다.
USB 블루 레이 드라이브 읽기 전용 지원
6100-06 기술 레벨을 포함한 AIX 버전 6.1 이상은 USB 연결된 블루 레이 드라이브를 인식하고 구성합니다.
이 기능은 다음 장치 패키지에 포함됩니다.
devices.usbif.08025002
블루 레이 미디어를 읽는 AIX 운영 체제의 기능은 업계 표준 주문자 상표 부착 방식(OEM) USB 블루 레이 드라이

브의 샘플을 기준으로 유효성이 확인됩니다.
USB 블루 레이 드라이브는 cd0 및 cd1 등과 같은 논리적 이름을 사용하여 구성됩니다. 드라이브는 원시 및 블록
특수 파일 둘 모두를 제공합니다. 예를 들어, cd0의 원시 특수 파일은 /dev/rcd0이고 블록 특수 파일
은 /dev/cd0입니다.
읽기 전용 기능은 국제 표준화 기구(ISO) 파일 시스템(읽기 전용 ISO 9660), 범용 디스크 형식(UDF) 파일 시스템
(버전 2.01 이하) 및 표준 광학 미디어 액세스 명령(예: dd 및 tar)에 대해 제공됩니다.
AIX 운영 체제는 USB 블루 레이 드라이브에 있는 CD, DVD 또는 블루 레이 미디어에 쓰기 조작을 지원하지 않습
니다. 쓰기 조작이 금지되지는 않지만(드라이브는 쓰기 가능), IBM은 쓰기 조작 동안에 발생한 문제에 대한 지원
을 제공하지 않습니다.
AIX 운영 체제는 USB 블루 레이 드라이브에 대한 플러그 앤 플레이를 지원하지 않습니다. USB 블루 레이 드라이
브를 AIX 사용자가 사용할 수 있게 만들려면, 루트 사용자는 드라이브를 시스템의 USB 포트에 연결하고 다음 명
령을 실행해야 합니다.
cfgmgr -l usb0
드라이브가 제거된 후에 드라이브는 루트 사용자가 다음 명령을 실행할 때까지 오브젝트 데이터 관리자(ODM)
데이터베이스에서 사용 가능한 상태로 남아 있습니다.
rmdev -l cdn
드라이브가 사용 가능 상태에 있으면 이를 시스템에 다시 연결할 수 있습니다. 드라이브가 사용자에게 여전히 열

려 있는 상태에서 시스템 USB 포트에서 연결 해제되면 이를 닫은 후 다시 열 때까지 해당 드라이브를 사용할 수
없습니다.
스토리지 데이터 캐싱
스토리지 데이터의 서버 측 캐싱이 캐시 장치에서 지원됩니다.
캐시 장치는 다음 장치 유형 중 하나일 수 있습니다.
• 서버에서 내장 SSD(Solid-State Drive)와 같은 서버에 연결된 플래시 장치.
• SAS(Serial Attached SCSI) 제어기를 사용하여 서버에 직접 연결된 플래시 장치.
• SAN(Storage Area Network)의 플래시 자원.
AIX 운영 체제는 캐시 장치로 사용하려면 해당 장치를 플래시 장치로 식별해야 합니다. AIX 운영 체제는 장치의
플래시 장치인지 여부를 SCSI 블록 장치 특성 필수 제품 데이터(VPD) 페이지의 MEDIUM ROTATION RATE 필
드를 사용하여 판별합니다. 장치가 해당 페이지를 지원하지 않거나 MEDIUM ROTATION RATE 필드에서
0001h Non-rotating medium 이외의 값을 입력하면 장치는 캐시 장치로 사용될 수 없습니다.
스토리지 데이터 캐싱 개념
워크로드가 실행 중인 동안 스토리지 데이터를 동적으로 캐시할 수 있습니다(캐시 시작 또는 중지). 캐시 조작을
수행하기 위해 워크로드를 비활성 상태로 가져올 필요가 없습니다.
장치 관리 199
다음 항목은 캐싱 개념을 설명하는 데 사용됩니다.
캐시 장치
캐시 장치는 캐싱에 사용되는 SSD(Solid-State Drive) 또는 플래시 디스크입니다.
캐시 풀
캐시 풀은 스토리지 캐싱에 사용되는 캐시 장치의 그룹입니다.
캐시 파티션
캐시 파티션은 캐시 풀에서 작성되는 논리적 캐시 장치입니다.
목표 장치
목표 장치는 캐싱되고 있는 스토리지 장치입니다.
단일 캐시 파티션은 하나 이상의 목표 장치를 캐싱하는 데 사용할 수 있습니다. 목표 장치가 캐싱되면 장치 블록
의 모든 읽기 요청은 캐싱 소프트웨어로 라우팅됩니다. 특정 블록이 캐시에서 발견되면 I/O 요청은 캐시 장치로
부터 처리됩니다. 요청된 블록을 캐시에서 찾을 수 없거나 쓰기 요청인 경우에는, I/O 요청이 목표 장치로 돌아갑
니다.
스토리지 데이터 캐싱의 장점

스토리지 데이터의 서버측 캐싱은 특히 스토리지 서브시스템이 정체될 때 가상화 밀도를 높일 수 있습니다.
스토리지 데이터 캐싱에는 다음 장점이 있습니다.
대기 시간
SSD(Solid-State Drive) 스토리지에 대기 시간이 더 낮으므로 분석 및 트랜잭션 워크로드가 조회-응답 시간
을 줄였습니다. 서버 측 캐싱을 사용하는 경우 트랜잭션 워크로드의 평균 대기 시간은 절반으로 줄 수 있습니
다.
처리량
SSD 스토리지는 더 나은 처리량을 제공하므로 온라인 트랜잭션 처리(OLTP) 워크로드에는 더 높은 트랜잭션
비율이 있습니다.
쓰기 처리량
스토리지 영역 네트워크(SAN)가 정체되는 환경에서는 캐시로서 사용되는 플래시 장치는 읽기 요청의 상당
한 비율을 오프로드할 수 있습니다. 읽기 요청이 오프로드되면 SAN은 더 나은 쓰기 처리량을 가질 수 있고 다
수의 클라이언트와 호스트를 효과적으로 제공할 수 있습니다.
더 작은 메모리 사용 공간
플래시 캐시 장치가 구성된 경우 일부 워크로드는 낮은 메모리 사용 공간 내에서도 수행할 수 있습니다.
스토리지 데이터 캐싱의 제한사항

캐싱 기능을 사용하기 위해 제한사항 및 추가 구성 요구사항을 이해했는지 확인하십시오. 캐싱되어야 하는 목표
장치의 애플리케이션 제한사항 또한 고려해야 합니다.
스토리지 데이터를 캐싱하기 위해서 다음 제한사항을 고려하십시오.
• 캐싱 소프트웨어는 읽기 전용 캐시로 간주되고, 이는 읽기 요청만이 플래시 SSD(Solid-State Drive)에서 처리
됨을 의미합니다. 모든 쓰기 요청은 원본 스토리지 장치에 의해 처리됩니다.
• 스토리지 장치에 작성된 데이터는 캐시에서 자동으로 채워지지 않습니다. 쓰기 조작이 캐시에 있는 블록에서
수행되면 캐시의 기존 데이터는 유효하지 않은 것으로 표시됩니다. 블록에 대한 액세스 빈도 및 최신 액세스에
따라 동일한 블록이 캐시에 다시 나타납니다.
• 캐싱 소프트웨어가 각 읽기 블록에서 메타데이터를 관리하므로 각 AIX 논리적 파티션(LPAR)에서 추가 메모리
가 필수입니다. 캐싱이 사용 가능한 모든 LPAR에 대해 최소 4GB의 메모리가 필수입니다.
• 캐싱 소프트웨어는 로컬 읽기 패턴을 기반으로 데이터를 캐시에 로드하고, 캐시 항목을 로컬에서 무효화합니
다. 목표 장치는 둘 이상의 LPAR이 동시에 공유해서는 안됩니다. 목표 장치는 Oracle Real Application
Cluster(RAC), DB2 pureScale® 및 General Parallel File System(GPFS) 등과 같은 클러스터된 스토리지의 일
부일 수 없습니다. 고가용성 클러스터의 일부인 목표 장치는 액세스가 싱글 호스트가 목표 장치에서 데이터를
동시에 읽거나 쓰고 있고 캐싱이 활성 노드에서만 사용 가능함을 액세스가 지정하는 경우에만 캐싱될 수 있습
니다.
• 캐시 디스크는 AIX LPAR 또는 Virtual I/O Server(VIOS) LPAR에 프로비저닝할 수 있습니다. 캐시 장치는 공유
할 수 없습니다.

• 캐싱 소프트웨어는 목표 장치에 대한 모든 I/O 요청을 인터셉트하기 위해 목표 장치를 열어야 합니다. 캐싱이
시작된 후에 워크로드가 목표 장치를 독점적으로 열어야 하는 경우에는 독점 열기 조작이 실패합니다. 이러한
인스턴스에서는 캐싱을 중지한 후 워크로드가 시작된 후에 다시 시작해야 합니다. 배타적 열기 조작의 예는 목
표 디스크의 PVID(physical volume identifier)를 설정하는 것입니다.
• 디스크가 목표 장치로 사용되는 경우에는 디스크의 reserve_policy 속성은 single_path로 설정되어서
는 안됩니다.
• 목표 장치에 대해 캐싱 조작이 시작되면 캐시 엔진 로직은 캐시로의 데이터 승격을 지연합니다. 목표 장치에서
캐싱 조작이 시작되기 전에 실행된 모든 미해결 I/O 조작이 캐싱 조작을 시작하기 전에 완료되도록 하기 위해
서는 이러한 지연이 필요합니다. 지연의 정확한 시간은 사용 가능한 경로 수와 대상 디스크의 rw_timeout 속
성(있는 경우)을 기반으로 내부적으로 계산됩니다. 내부적으로 계산된 시간을 사용자 정의 시간에 의해 재정의
해야 하는 경우에는 /etc/environment 파일에서 DEFAULT_IO_DRAIN_TIMEOUT_PD 환경 변수를 사용자
정의 시간종료 값(초)으로 설정할 수 있습니다.
• NVMe 장치는 목표로 사용할 수 없습니다.
스토리지 데이터 캐싱의 구성요소

캐싱 소프트웨어는 캐시 관리와 캐시 엔진 구성요소로 구성됩니다.
캐시 관리
AIX 운영 체제와 가상 I/O 서버(VIOS)에서 사용 가능한 cache_mgt 명령을 사용하여 스토리지 데이터 캐싱을
관리할 수 있습니다. cache_mgt 명령을 사용하여 다음 태스크를 수행할 수 있습니다.
• 캐시 풀을 작성하고 파티션을 만듭니다.
• 캐시 파티션을 대상 장치 또는 AIX 논리적 파티션(LPAR)에 가상 작은 컴퓨터 시스템 인터페이스(vSCSI) 장치
로서 지정합니다.
• 캐싱 조작을 시작하고 중지합니다.
캐시 엔진
캐시 엔진은 캐싱 소프트웨어의 가장 본질적인 부분입니다. 캐시 엔진은 스토리지의 어떤 블록을 캐싱해야 하는
지와, 데이터를 캐시 또는 1차 스토리지에서 검색해야 하는지 여부를 결정합니다.
캐싱 알고리즘은 캐시를 공간적 지역 특성(최근에 읽힌 다른 블록의 가까이에)이 있는 데이터로 채우는 '읽을 때
채우기' 메커니즘을 기반으로 합니다. 캐싱 알고리즘은 캐시가 비어 있을 때 보다 빠르게 캐시에 데이터를 채웁니
다.
캐시의 모든 블록은 얼마나 자주 읽히는지를 검사하기 위해 모니터링되고 히트 맵이 생성됩니다. 히트 맵은 액세
스의 빈도와 최근성 둘 모두를 고려합니다. 캐시가 완전히 채워지면 새 항목은 새 블록이 캐시에서 가장 차가운
블록보다 따뜻한 경우에만 캐시에 추가됩니다. 가장 차가운 블록은 캐시에서 제거되고 새 항목이 추가됩니다.
공격적인 채우기를 수행하면 캐시가 사용 가능하게 되는 즉시 유효하게 만드는 짧은 워밍업 시간이 가능합니다.
히트 맵을 기반으로 하는 제거 정책은 캐싱이 동적이고 변화하는 워크로드 패턴에 맞게 조정되도록 합니다.
스토리지 데이터 캐싱 구성
AIX 운영 체제에서 플래시 장치의 서버 측 캐싱은 몇몇 개별 구성에서 지원됩니다. 이러한 구성은 캐시 장치가
AIX 논리적 파티션(LPAR)에 프로비저닝된 방법에 따라 다릅니다.
서버 측 캐싱은 AIX 운영 체제에서 다음 모드를 지원합니다.
• 전용 모드
• 가상 모드
• N_Port ID 가상화(NPIV) 모드
전용 모드에서 스토리지 데이터 캐싱

전용 모드에서 캐시 장치는 AIX 논리적 파티션(LPAR)에 직접 프로비저닝됩니다.
캐시 풀을 작성한 다음에 캐시 장치에서 캐시 파티션을 작성해야 합니다. 단 하나의 캐시 파티션만을 전용 캐시
장치에서 작성할 수 있습니다. 캐시 파티션을 사용하여 AIX LPAR에서 임의의 수만큼의 목표 장치를 캐싱할 수
있습니다. LPAR은 캐시 장치가 이 LPAR에 전용이기 때문에 이동 가능하지 않습니다. LPAR을 또 다른 서버로 마
장치 관리 201
이그레이션해야 하는 경우에는 마이그레이션 전에 캐싱을 수동으로 중지하고 캐시 장치를 구성 해제해야 합니
다.
다음 그림은 전용 캐시 장치에 대해 AIX LPAR에서 구성을 캐싱하기 위한 예를 보여줍니다.
그림 16. 스토리지 데이터 캐싱: 전용 캐시 장치를 위한 구성
캐시 장치가 hdisk1, hdisk2 및 hdisk3이고 목표 장치가 hdisk4, hdisk5 및 hdisk6라고 가정하십시오.

목표 장치의 캐싱을 시작하고 모니터하려면 다음 단계를 완료하십시오.
1. SSD 스토리지에서 캐시 풀을 작성하십시오.
# cache_mgt pool create -d hdisk1,hdisk2,hdisk3 -p cmpool0
2. 캐시 풀에서 80MB의 캐시 파티션을 작성하십시오.

# cache_mgt partition create -p cmpool0 -s 80M -P part1
3. 캐시하려는 대상 디스크에 캐시 파티션을 지정하십시오.

# cache_mgt partition assign -t hdisk4 -P part1
4. 목표 장치의 캐싱을 시작하십시오.

# cache_mgt cache start -t hdisk4
5. 캐시 히트에 대한 통계를 모니터링하십시오.

# cache_mgt monitor get -h -s
가상 모드에서 스토리지 데이터 캐싱

가상 모드에서 캐시 장치는 가상 I/O 서버(VIOS)에 지정됩니다.
가상 모드에서 캐시 풀은 VIOS에 작성됩니다. 그런 다음 캐시 풀은 VIOS에서 파티션으로 나누어집니다. 각 캐시
파티션은 가상 호스트(vhost) 어댑터에 지정될 수 있습니다. 캐시 파티션이 AIX 논리적 파티션(LPAR)에서 검색
되면, 캐시 파티션은 목표 장치를 캐싱하는 데 사용할 수 있습니다. 캐시 파티션은 캐시 장치가 가상이므로 또 다
른 서버로 마이그레이션할 수 있습니다. 마이그레이션 전에 캐싱은 소스 LPAR에서 자동으로 중지됩니다. 마이그
레이션 조작의 일부로서, 캐싱 소프트웨어가 설치되고 캐시 풀이 대상 VIOS에서 사용 가능한 경우 동일 크기의
캐시 파티션이 대상 VIOS에서 동적으로 작성됩니다. 마이그레이션 동안에 캐시 파티션이 LPAR에 사용 가능하게
됩니다. 마이그레이션이 완료되면 캐싱은 대상 LPAR에서 자동으로 시작됩니다. 이 경우, 캐싱은 빈(채워지지 않
은) 상태에서 시작됩니다.
다음 그림은 가상 모드에서 캐싱 구성의 예를 보여줍니다. 여기서 캐시 장치는 VIOS LPAR에 있고 목표 장치는
AIX LPAR에 있습니다.
장치 관리 203
그림 17. 스토리지 데이터 캐싱: 가상 캐시 장치를 위한 구성
캐시 장치가 hdisk1, hdisk2 및 hdisk3(VIOS LPAR에서)이고, 목표 장치가 hdisk4 및 hdisk5(AIX LPAR

에서)이라고 가정하십시오. 목표 장치의 캐싱을 시작하고 모니터하려면 다음 프로시저를 완료하십시오.
1. VIOS LPAR에서 SSD 스토리지를 사용하여 캐시 풀을 작성하십시오.
# cache_mgt pool create -d hdisk1,hdisk2,hdisk3 -p cmpool0
2. VIOS LPAR에서 캐시 풀에서 80MB의 캐시 파티션을 작성하십시오.

# cache_mgt partition create -p cmpool0 -s 80M -P part1
3. VIOS LPAR에서 가상 호스트 어댑터에 파티션을 지정하십시오.

# cache_mgt partition assign -P part1 -v vhost0
4. AIX LPAR에서 캐시 파티션을 목표 장치에 지정하십시오.

# cache_mgt partition assign -t hdisk4 -P cachedisk0
# cache_mgt partition assign -t hdisk5 -P cachedisk0
5. AIX LPAR에서 목표 장치의 캐싱을 시작하십시오.

6. AIX LPAR에서 캐시 히트에 대한 통계를 모니터하십시오.

# cache_mgt monitor get -h -s
NPIV 모드에서 스토리지 데이터 캐싱

이 모드에서 캐시 장치는 AIX 논리적 파티션(LPAR)에서 가상 파이버 채널(N_Port ID 가상화) 장치로서 사용 가
능합니다.
캐시 풀을 작성한 다음에 AIX LPAR에서 캐시 파티션을 작성해야 합니다. AIX LPAR에서 단 하나의 캐시 파티션
만을 작성할 수 있습니다. 캐시 파티션을 사용하여 AIX LPAR에서 임의의 수만큼의 목표 장치를 캐싱할 수 있습
니다. 캐시 장치를 SAN(Storage Area Network)에서 사용 가능하므로 LPAR을 또 다른 서버로 마이그레이션할
수 있습니다. 캐시 장치는 대상 시스템에서 가시적이어야 합니다. 캐싱 조작은 마이그레이션 프로세스 동안에 계
속할 수 있고 캐시는 마이그레이션이 완료된 후에 채워집니다.
NPIV 모드에서 목표 장치를 캐싱하는 것은 캐시 장치가 SAN에서 사용 가능하다는 점을 제외하고는 전용 모드에
서 스토리지 데이터를 캐싱하는 것과 같습니다. 그러나 목표 장치를 캐싱하는 프로시저는 전용 모드에서 스토리
지 데이터를 캐싱하는 것과 같습니다.
스토리지 데이터 캐시 관리
캐시는 구성되지만 캐싱 요구사항은 시간에 따라 변경될 수 있습니다. 캐싱할 새 워크로드를 추가하고 싶을 수도
있습니다. 변경 요구사항을 충족하기 위해 캐시 풀은 추가 캐시 장치로 확장될 수 있고, 새 캐시 파티션이 기존 풀
에서 작성되거나 기존 파티션의 크기가 늘어날 수 있습니다.
다음 예를 사용하여 캐싱 구성을 관리할 수 있습니다.
• 캐시 장치를 풀에 추가하려면 다음 명령을 입력하십시오.
# cache_mgt pool extend -p pool1 -d hdisk4 -f
-f 플래그는 디스크에 기존 볼륨 그룹이 포함된 경우 디스크(hdisk4)의 기존 사용량을 재정의합니다.

• 크기 100MB의 새 워크로드를 위한 파티션을 작성하려면 다음 명령을 입력하십시오.
# cache_mgt partition create -p pool1 -s 100M -P part2
• 기존 파티션의 크기를 20MB만큼 늘리려면 다음 명령을 입력하십시오.

# cache_mgt partition extend -p part1 -s 20M
고가용성 고려사항
캐싱된 대상 장치가 고가용성 클러스터에서 관리되는 자원 그룹의 일부인 경우 장애 복구 조작은 적절하게 계획
되어야 합니다.
캐싱은 한 번에 하나의 노드에서만 활성화될 수 있습니다. 장애 복구 이벤트가 초기화되기 전에, 캐싱 조작이 원
본 시스템에서 사용 안함으로 설정되었는지 확인해야 합니다. 대체 시스템에 대한 장애 복구가 완료된 후에는 캐
싱 소프트웨어를 수동으로 사용으로 설정해야 합니다.
캐싱 소프트웨어를 사용으로 설정하려면 다음 단계를 완료하십시오.
1. 원본 시스템에서 캐싱을 중지하십시오.
# cache_mgt cache stop -t hdisk2
2. 장애 복구가 완료된 후에 새 시스템에서 캐싱을 시작하십시오.

장치 관리 205
모니터링 캐시 통계
각 대상 장치에 대한 캐시 통계는 cache_mgt monitor get 명령을 사용하여 표시할 수 있습니다.
예를 들어 hdisk1이 캐시된 유일한 대상 장치인 경우, cache_mgt 명령의 출력은 다음의 예와 유사할 수 있습
니다.
# cache_mgt monitor get -h -sETS Device I/O Statistics -- hdisk1
Start time of Statistics -- Mon Mar 27 07:10:41 2017
-----------------------------------------------------
Read Count: 152125803
Write Count: 79353626
Read Hit Count: 871
Partial Read Hit Count: 63
Read Bytes Xfer: 10963365477376
Write Bytes Xfer: 4506245999616
Read Hit Bytes Xfer: 48398336
Partial Read Hit Bytes Xfer: 5768192
Promote Read Count: 2033078104
Promote Read Bytes Xfer: 532959226494976
cache_mgt 명령은 다음과 같은 캐싱 메트릭을 제공합니다.

읽기 수
모든 애플리케이션에서 대상 장치에 발행한 모든 읽기 조작의 총 개수입니다. 이 값에는 캐시 장치에서 데이
터를 사용할 수 있는 경우 캐시 장치에 대한 읽기 조작도 포함됩니다. 이 값은 서로 다른 읽기 요청의 총 개수
이며 읽기 요청의 크기(바이트 개수)를 표시하지는 않습니다.
쓰기 수
모든 애플리케이션에서 대상 장치에 발행한 모든 쓰기 조작의 총 개수입니다. 이 값은 서로 다른 쓰기 요청의
총 개수이며 쓰기 요청의 크기(바이트 개수)를 표시하지는 않습니다.
읽기 히트 수
전체 읽기 히트인 대상 장치에 발행된 읽기 조작의 총 개수입니다. 전체 읽기 히트는 캐시 장치에서 읽기 요청
을 완전히 이행하는 읽기 조작 인스턴스입니다. 읽기 히트 수 값은 서로 다른 읽기 히트 요청의 총 개수이며
읽기 요청의 크기(바이트 개수)를 표시하지는 않습니다. 이 값은 읽기 수 값에 포함됩니다.
부분 읽기 히트 수
부분 읽기 히트인 대상 장치에 발행된 읽기 조작의 총 개수입니다. 부분 읽기 히트는 캐시 장치에서 읽기 요청
을 부분적으로 이행하는 읽기 조작 인스턴스입니다. 캐시 장치에서 사용할 수 없는 나머지 데이터는 대상 장
치에서 가져와야 합니다. 부분 읽기 히트 수 값은 서로 다른 읽기 요청의 총 개수이며 읽기 요청의 크기(바
이트 개수)를 표시하지는 않습니다. 이 값은 읽기 수 값에 포함됩니다.
읽기 바이트 Xfer
애플리케이션에서 대상 장치에 발행된 모든 읽기 요청에서 전송된 총 바이트 개수입니다. 이 값은 전체 읽기
히트 데이터, 부분 읽기 히트 데이터 및 대상 장치에서 가져온 모든 데이터의 총 바이트 개수를 의미합니다.
쓰기 바이트 Xfer
애플리케이션에서 대상 장치에 발행된 모든 쓰기 요청에서 전송된 총 바이트 개수입니다.
읽기 히트 바이트 Xfer
전체 읽기 히트 인스턴스 중에 읽은 총 바이트 개수입니다.
부분 읽기 히트 바이트 Xfer
부분 읽기 히트 인스턴스 중에 읽은 총 바이트 개수입니다.
승격 읽기 수
데이터가 캐시 장치에 채워질 때 대상 장치에 발행되는 총 읽기 명령 개수입니다. 대상 디스크로의 최대 데이
터 전송 크기가 요청 크기보다 작으면 캐시 장치에 데이터를 채우라는 단일 요청이 여러 읽기 작업으로 분할
될 수 있으므로 이 값은 데이터가 캐시 장치로 채워질 때 인스턴스의 수를 표시하지는 않습니다.
승격 읽기 바이트 Xfer
데이터가 캐시 장치에 채워질 때 대상 장치에서 읽은 총 바이트 개수입니다.
로그인 이름, 시스템 ID 및 비밀번호

운영 체제가 올바른 환경을 제공하려면 사용자가 누구인지를 알아야 합니다.

운영 체제에서 자신을 식별하기 위해, 로그인 이름(사용자 ID 또는 사용자 이름) 및 비밀번호를 입력하여 로그인
합니다. 비밀번호가 보안의 양식이 됩니다. 사용자의 로그인 이름을 알고 있지만 비밀번호를 모르면 사용자 시스
템에 로그인할 수 없습니다.
사용자 시스템이 다중 사용자 시스템으로 시작되면, 각각 권한을 부여받은 사용자는 시스템에 대한 계정, 비밀번
호 및 로그인 이름을 갖게 됩니다. 운영 체제는 각각의 사용자가 사용한 자원을 기억하고 있습니다. 이는 시스템
사용통계가 됩니다. 시스템 스토리지에 파일 시스템이라는 개인 영역을 각 사용자에게 제공합니다. 로그인 하면,
수천 개의 서로 다른 파일이 시스템에 존재해도 파일 시스템은 사용자의 파일만을 포함하고 있는 것처럼 보입니
다.
시스템에서 하나 이상의 유효한 로그인 이름을 갖는 것이 가능합니다. 한 로그인 이름을 다른 이름으로 변경하려
할 경우, 시스템에서 로그아웃할 필요가 없습니다. 로그아웃하지 않고, 동시에 다른 쉘에 또는 동시에 동일한 쉘
에 연속해서 다른 로그인 이름을 사용할 수도 있습니다. 게다가, 사용자 시스템이 다른 사용자와 연결된 네트워크
의 일부이면, 사용자가 로그인 이름을 갖고 있는 다른 시스템에 로그인할 수 있습니다. 이를 원격 로그인이라고
합니다.
운영 체제에서 작업을 완료했으면, 파일과 데이터의 보안을 위해 로그아웃하십시오.
운영 체제에 로그인
운영 체제를 사용하려면, 사용자 시스템이 실행 중이어야 하고 로그인되어야 합니다. 사용자가 운영 체제로 로그
인할 때, 시스템에서 사용자 자신을 식별하고 시스템으로 하여금 사용자의 환경을 설정하도록 허용합니다.
하루 중 특정 시간 동안만 또는 한 주의 특정 요일에만 로그인할 수 있도록 시스템을 설정할 수 있습니다. 사용자
가 허용된 시간 이외의 시간에 로그인하려고 하면, 사용자 액세스를 거절합니다. 시스템 관리자는 로그인 시간을
검증할 수 있습니다.
로그인 프롬프트에서 로그인합니다. 운영 체제로 로그인할 때, 홈 디렉토리(로그인 디렉토리)로 들어가게 됩니
다.
사용자 시스템을 시작한 후에 시스템에 로그인하여 세션을 시작합니다.
1. login: 프롬프트 뒤에 로그인 이름을 입력하십시오.
login: LoginName
예를 들어, 사용자의 로그인 이름이 denise인 경우:
login: denise
2. password: 프롬프트가 표시되면, 비밀번호를 입력하십시오.

(화면에는 사용자가 입력한 내용이 표시되지 않습니다).
password: [your password]
비밀번호 프롬프트가 표시되지 않으면, 사용자는 정의된 비밀번호를 가지지 않은 것입니다. 운영 체제에서 작업
을 시작할 수 있습니다.
시스템이 켜져 있지 않으면 로그인 하기 전에 다음을 수행하십시오.
1. 접속된 각 장치의 스위치를 켜십시오.
2. 전원 스위치를 온(I)으로 설정하여 시스템을 시작하십시오.
3. 세 자리 표시를 찾아보십시오. 자체 테스트가 오류없이 완료되면, 세 자리 표시가 공백이 됩니다.
주의를 요청하는 오류가 발생하면, 세 자리 숫자 코드가 남아 있고 시스템은 정지됩니다. 오류 코드 및 복구에 대
한 정보는 시스템 관리자에게 문의하십시오.
자체 테스트 완료가 성공적이면 다음과 같은 로그인 프롬프트가 사용자 화면에 표시됩니다.
login:
사용자가 로그인한 후, 운영 체제가 설정된 방법에 따라, 사용자 시스템이 명령행 인터페이스(쉘) 또는 그래픽 인
터페이스(예: AIXwindows 또는 상용 데스크탑 환경(CDE))로 시작됩니다.
사용자 비밀번호 및 사용자 이름 구성에 관련한 질문이 있으면 시스템 관리자에게 문의하십시오.
장치 관리 207
한 번 이상 로그인(login 명령)
둘 이상의 프로젝트에서 작업 중이고 별도의 계정을 유지보수하고 싶은 경우 둘 이상의 동시 로그인을 가질 수 있
습니다. 동일한 로그인 이름을 사용하거나 다른 로그인 이름을 사용하여 시스템에 로그인하여 이를 수행합니다.
참고: 각각의 시스템은 주어진 시간 내에 언제라도 활성할 수 있는 로그인 이름의 최대 수를 갖고 있습니다. 이 수
는 라이센스 계약에 의해 결정되며 설치에 따라 다양합니다.
예를 들어, denise1로 이미 로그온하고 사용자의 다른 로그인 이름이 denise2인 경우 프롬프트에 다음을 입
력하십시오.
login denise2
password: 프롬프트가 표시되면, 비밀번호를 입력하십시오. (화면에는 사용자가 입력한 내용이 표시되지 않습
니다). 사용자는 현재 두 개의 로그인을 사용자 시스템에서 실행하고 있습니다.
시스템에서 다른 사용자로 전환(su 명령)

(사용자의 로그인 이름을 아는 경우) su(switch user) 명령을 사용하여 세션과 연관된 사용자 ID를 변경할 수 있
습니다.
예를 들어, 사용자 joyce로 전환하려면 프롬프트에 다음을 입력하십시오.
su joyce
password: 프롬프트가 표시되면, 사용자 joyce의 비밀번호를 입력하십시오. 사용자 ID는 현재 joyce입니다.
비밀번호를 모르면, 요청이 거부됩니다.
사용자 ID가 joyce인지 확인하려면, id 명령을 사용하십시오.
로그인 메시지 억제
로그인에 성공하면, login 명령은 해당 사용자의 마지막으로 성공하거나 실패한 로그인 시도 날짜와 시간을 표
시하고, 인증 정보(일반적으로 비밀번호)의 최종 변경 이후에 이 사용자의 실패한 로그인 시도 총계를 표시합니
다. 사용자의 홈 디렉토리에 .hushlogin 파일을 포함시켜 이 메시지를 생략할 수 있습니다.
사용자의 홈 디렉토리에서 프롬프트에 다음 명령을 입력하십시오.

touch .hushlogin
touch 명령은 .hushlogin이라는 빈 파일(존재하지 않는 경우)을 작성합니다. 다음 번에 사용자가 로그인하

면, 모든 로그인 메시지는 억제됩니다. 시스템이 오늘의 메시지만을 유지하고 다른 로그인 메시지는 억제하도록
지시할 수 있습니다.
운영 체제에서 로그아웃(exit 및 logout 명령)

운영 체제에서 로그아웃하려면 시스템 프롬프트에서 다음 중 한 가지를 수행하십시오.
EOF 제어 키 시퀀스(Ctrl-D)를 누르십시오.
OR
exit를 입력하십시오.
OR
logout을 입력하십시오.
로그아웃한 후, 시스템은 login: 프롬프트를 표시합니다.
사용자 ID 표시
특정 사용자의 시스템 ID를 표시하려면, id 명령을 사용하십시오. 시스템 ID는 시스템에서 사용자와 사용자 그
룹을 식별하는 번호입니다.

적용 가능할 경우, id 명령은 다음의 정보를 표시합니다.
• 사용자 이름 및 실제 사용자 ID
• 사용자의 그룹 이름 및 실제 그룹 ID
• 사용자의 추가 그룹 이름 및 추가 그룹 ID(있을 경우)
예를 들어, 프롬프트에 다음을 입력하십시오.
id
시스템은 다음과 유사한 정보를 표시합니다.

uid=1544(sah) gid=300(build) euid=0(root) egid=9(printq) groups=0(system),10(audit)
이 예제에서, 사용자의 이름은 sah이고 ID 번호는 1544입니다. 기본 그룹 이름은 build이고 ID 번호는 300입
니다. 유효한 사용자 이름은 root이고 ID 번호는 0입니다. 유효한 그룹 이름은 printq이고 ID 번호는 9입니다.
그리고 두 추가 그룹 이름은 system 과 audit이고, ID 번호는 각각 0과 10입니다.
id denise

uid=2988(denise) gid=1(staff)
이 예제에서, 사용자 denise는 ID 번호가 2988이고, ID 번호가 1인 staff이라는 기본 그룹 이름만 가지고 있

습니다.
로그인 이름 표시(whoami 및 logname 명령)

둘 이상의 동시 로그인이 있는 경우 로그인 이름, 특히 현재 사용 중인 로그인 이름을 놓치기 쉽습니다. whoami
및 logname 명령을 사용하여 이 정보를 표시할 수 있습니다.
whoami 명령 사용
어떤 로그인 이름이 사용 중인지 알아보려면 프롬프트에 다음을 입력하십시오.
whoami

denise
이 예제에서 사용 중인 로그인 이름은 denise입니다.

who am i 명령 사용
who 명령의 변형인 who am i 명령은 로그인 이름, 터미널 이름 및 로그인 시간을 표시하도록 합니다. 프롬
프트에 다음을 입력하십시오.
who am i

denise pts/0 Jun 21 07:53
이 예에서, 로그인 이름은 denise이고, 터미널 이름은 pts/0이며, 이 사용자는 6월 21일 오전 7시 53분에
로그인했습니다.
logname 명령 사용
who 명령의 또 다른 변형인 logname 명령은 who 명령과 동일한 정보를 표시합니다.
프롬프트에 다음을 입력하십시오.
장치 관리 209
logname

denise
이 예에서 로그인 이름은 denise입니다.
운영 체제 이름 표시(uname 명령)
운영 체제의 이름을 표시하려면, uname 명령을 사용하십시오.
uname

AIX
이 예에서, 운영 체제의 이름은 AIX 입니다.
시스템 이름 표시(uname 명령)

네트워크 상에 있을 때 사용자의 시스템 이름을 표시하려면, -n 플래그와 함께 uname 명령을 사용하십시오. 사
용자의 시스템 이름은 네트워크에서 사용자의 이름을 식별합니다. 그러나 사용자의 로그인 ID와는 다릅니다.
uname -n

barnard
이 예에서 시스템 이름은 barnard입니다.
로그인된 모든 사용자 표시
현재 로컬 시스템에 로그인한 모든 사용자의 정보를 표시하려면, who 명령을 사용하십시오.
로그인 이름, 시스템 이름 및 로그인 날짜와 시간 정보가 표시됩니다.
참고: 이 명령은 로컬 노드에 로그인된 사용자만 식별합니다.
로컬 시스템 노드를 사용 중인 사용자에 대해 알아보려면 다음을 입력하십시오.
who
joe lft/0 Jun 8 08:34

denise pts/1 Jun 8 07:07
이 예에서, 사용자 joe는 lft/0 터미널에 6월 8일 오전 8시 34분에 로그인했습니다.

who 명령을 참조하십시오.
비밀번호
고유의 비밀번호는 사용자 파일에 대해 일부 시스템 보안을 제공합니다.
사용자 시스템이 비밀번호와 각각의 계정을 연관시킵니다. 보안은 허가받지 않은 사람들이 시스템에 액세스하지
못하도록 하고 다른 사용자의 파일을 부당하게 변경하지 못하게 하므로 컴퓨터 시스템의 중요한 부분입니다. 보
안을 통해 사용자가 액세스할 수 있는 파일과 사용할 수 있는 명령에 대한 일부 사용자의 배타적 특권을 허용할
수도 있습니다. 보호를 위해, 일부 시스템 관리자는 사용자가 특정 명령이나 파일에만 액세스하도록 허용합니다.

비밀번호 가이드라인
사용자는 고유한 비밀번호를 가져야 합니다. 비밀번호는 공유해서는 안됩니다. 다른 회사 자산과 마찬가지로 비
밀번호를 보호해야 합니다. 비밀번호는 쉽게 생각해 낼 수 없도록 어렵게 작성하되, 기억할 수가 없어서 적어둘
만큼 너무 어려워서는 안됩니다.
알려지지 않은 비밀번호를 사용하여 사용자 ID를 보안합니다. 사용자 이름이나 생일과 같은 개인 정보로 된 비밀
번호는 좋지 않습니다. 이와 같은 것은 쉽게 추측할 수 있습니다.
좋은 비밀번호는 최소 6문자로 되어 있고 영문자가 아닌 문자가 들어 있는 것입니다. 특이한 단어의 조합 및 고의
로 잘못 철자된 것도 좋은 선택입니다.
참고: 비밀번호가 너무 어려워서 기록해 놓아야 한다면 적절한 비밀번호라고 할 수 없습니다.
비밀번호를 선택할 때 다음과 같은 지침을 사용하십시오.
• 사용자 ID를 비밀번호로 사용하지 마십시오. 철자를 거꾸로, 두 번 반복해서 또는 수정해서 비밀번호로 사용하
지 마십시오.
• 비밀번호를 재사용하지 마십시오. 시스템이 비밀번호의 재사용을 거부할 수도 있습니다.
• 사람의 이름을 비밀번호로 사용하지 마십시오.
• 온라인 철자 검사 사전에서 찾을 수 있는 단어를 비밀번호로 사용하지 마십시오.
• 6문자 이하의 비밀번호는 사용하지 마십시오.
• 예의에 어긋난 단어를 비밀번호로 사용하지 마십시오. 비밀번호를 생각할 때 가장 먼저 고려해야 합니다.
• 기록해 두지 않아도 되도록 기억하기 쉬운 비밀번호를 사용하십시오.
• 문자와 숫자를 모두 사용하며 대문자와 소문자가 모두 있는 비밀번호를 사용하십시오.
• 숫자로 분리한 두 단어를 비밀번호로 사용하십시오.
• 발음할 수 있는 비밀번호를 사용하십시오. 기억하기가 쉽습니다.
• 비밀번호를 기록해 두지 마십시오. 그러나 기록해야만 하는 경우, 잠금 장치가 되어 있는 캐비넷과 같은 안전한
장소에 두십시오.
비밀번호 변경(passwd 명령)

비밀번호를 변경하려면 passwd 명령을 사용하십시오.
1. 프롬프트에 다음을 입력하십시오.
passwd
아직 비밀번호가 없으면 단계 2를 생략하십시오.

2. 다음과 같은 프롬프트가 표시됩니다.
Changing password for UserID
UserID's Old password:
이 요청은 사용자가 없을 때 허가되지 않은 사용자가 사용자의 비밀번호를 변경하지 못하도록 합니다. 현재

비밀번호를 입력하고 Enter를 누르십시오.
3. 다음 프롬프트가 표시됩니다.
UserID's New password:
원하는 새 비밀번호를 입력한 후 Enter를 누르십시오.

4. 새 비밀번호를 다시 입력하도록 요청하는 다음 프롬프트가 표시됩니다.
새로운 비밀번호 다시 입력:
이 요청은 비밀번호가 다시 작성할 수 없는 잘못된 문자열로 설정되는 것을 막습니다.
비밀번호 널(null)화(passwd 명령)

로그인할 때마다 비밀번호를 입력하지 않으려면, 사용자 비밀번호를 널(공백)로 설정하십시오.
비밀번호를 널(null)로 설정하려면 다음을 입력하십시오.
장치 관리 211
passwd
새 비밀번호를 입력하라고 프롬프트되면, Enter 또는 Ctrl-D를 누르십시오.

passwd 명령은 새 비밀번호를 다시 입력하라고 프롬프트를 표시하지 않습니다. 널(null) 비밀번호를 확인하는
메시지가 표시됩니다.
자세한 정보 및 전체 구문은 passwd 명령을 참조하십시오.
로그인 이름, 시스템 ID 및 비밀번호용 명령 요약

명령을 사용하여 로그인 이름, 시스템 ID 및 비밀번호에 대한 작업을 수행할 수 있습니다.
로그인 및 로그아웃 명령
항목 설명
login 세션을 초기화합니다.
logout 모든 프로세스를 정지합니다.
shutdown 시스템 조작을 종료합니다.
su 세션과 연관된 사용자 ID를 변경합니다.
touch 파일에 대한 액세스 및 수정 시간을 갱신하거나 빈 파일을 작성합니다.
사용자 및 시스템 식별 명령
항목 설명
id 지정된 사용자의 시스템 ID를 표시합니다.
logname 로그인 이름을 표시합니다.
uname 현재 운영 체제의 이름을 표시합니다.
who 현재 로그인된 사용자를 식별합니다.
whoami 로그인 이름을 표시합니다.
비밀번호 명령
항목 설명
passwd 사용자의 비밀번호를 변경합니다.
공통 데스크탑 환경
CDE(Common Desktop Environment)로 네트워크된 장치 및 도구의 위치를 알 필요 없이 이에 액세스할 수 있습
니다. 단순히 오브젝트를 끌어다 놓음으로써 애플리케이션 간에 데이터를 교환할 수 있습니다.
이전에는 복잡한 명령행 구문을 필요로 했던 많은 태스크가 이제는 훨씬 쉽고 플랫폼 간에 유사하게 수행할 수 있
습니다. 예를 들어, 중앙 집중적으로 애플리케이션을 구성하고 사용자들에게 분배할 수 있습니다. 지원하는 사용
자 애플리케이션의 보안, 가용성 및 상호 운영성의 중앙 관리가 가능합니다.
참고: CDE(Common Desktop Environment) 1.0 도움말 볼륨, 웹 기반 문서 및 하드 카피 매뉴얼에서는 데스크
탑을 공통 데스크탑 환경, AIXwindows 데스크탑, CDE 1.0 또는 데스크탑으로 표현할 수도 있습니다.
데스크탑 자동 시작 사용 및 사용 안함 설정
시스템이 켜질 때 자동으로 상용 데스크탑 환경을 시작하도록 시스템을 설정하면 편리합니다.
이러한 설정은 SMIT(System Management Interface Tool)를 통해서나 명령행에서 수행할 수 있습니다.
선행 조건
데스크탑 자동 시작을 사용 또는 사용 안함으로 설정하려면 루트 사용자 권한이 있어야 합니다.

데스크탑 자동 시작을 사용 또는 사용 안함으로 설정하는 방법을 결정하려면 다음 테이블을 참조하십시오.
상용 데스크탑 환경 자동 시작 및 정지
데스크탑 자동 시작 사용 설정 1 smit dtconfig /usr/dt/bin/dtconfig -e
데스크탑 자동 시작 사용 안함 설정 1 smit dtconfig /usr/dt/bin/dtconfig -d
참고: 이 태스크를 완료한 후에 시스템을 재시작하십시오.
수동으로 공통 데스크탑 환경 시작
다음 절차를 사용하여 수동으로 공통 데스크탑 환경을 시작할 수 있습니다.
1. 시스템에 루트로 로그인하십시오.
2. 명령행에 다음을 입력하십시오.
/usr/dt/bin/dtlogin -daemon
데스크탑 로그인 화면이 표시됩니다. 로그인하면 데스크탑 세션이 시작됩니다.
수동으로 공통 데스크탑 환경 정지
로그인 관리자를 수동으로 정지하면, 로그인 관리자가 시작한 모든 X 서버 및 데스크탑이 정지됩니다.
1. 터미널 에뮬레이터 창을 열고 루트로 로그인하십시오.
2. 다음을 입력하여 로그인 관리자의 프로세스 ID를 가져오십시오.
cat /var/dt/Xpid
3. 다음을 입력하여 로그인 관리자를 정지하십시오.

kill -term process_id
데스크탑 프로파일 수정
사용자가 데스크탑에 로그인할 때, 쉘 환경 파일(.profile 또는 .login)이 자동으로 읽혀지지 않습니다. 데스
크탑은 사용자가 로그인하기 전에 X를 실행하기 때문에 .profile 파일이나 .login 파일이 제공하는 기능은
데스크탑의 로그인 관리자가 제공해야 합니다.
사용자에게만 적용되는 환경 변수는 /Home Directory/ .dtprofile에 설정됩니다. 이 파일의 서식 파일
은 /usr/dt/config/sys.dtprofile에 있습니다. 데스크탑에만 적용되는 변수 및 쉘 명령
은 .dtprofile에 두십시오. 쉘 환경 파일과 합치려면 .dtprofile 행을 추가하십시오.
시스템 측면의 환경 변수는 로그인 관리자 구성 파일에 설정할 수 있습니다. 환경 변수 구성에 관한 세부사항은
공통 데스크탑 환경 1.0: 고급 사용자 및 시스템 관리자 안내서를 참조하십시오.
공통 데스크탑 환경용 표시장치와 터미널 추가 및 제거

공통 데스크탑 환경용 표시장치와 터미널을 추가하고 제거할 수 있습니다.
로그인 관리자는 단일 로컬 비트맵 또는 그래픽 콘솔을 사용하여 시스템에서 시작할 수 있습니다. 그러나 여러 가
지 다른 상황도 발생할 수 있습니다(아래 그림 참조). 다음에서 공통 데스크탑 환경를 시작할 수 있습니다.
• 로컬 콘솔
• 원격 콘솔
• 네트워크의 호스트 시스템에서 실행 중인 비트맵 및 문자 표시화면 X 터미널 시스템
장치 관리 213
그림 18. CDE 인터페이스 위치
X 터미널 시스템은 표시장치, 키보드 및 X 서버만 실행하는 마우스로 구성됩니다. 공통 데스크탑 환경를 포함한
클라이언트는 네트워크에 있는 하나 이상의 호스트 시스템에서 실행됩니다. 클라이언트의 출력은 X 터미널 표시
장치로 방향 지정됩니다.
다음 로그인 관리자 구성 태스크는 가능한 여러 구성을 지원합니다.
• 로컬 표시장치 제거
• ASCII 또는 문자 표시화면 터미널 추가
워크스테이션을 X 터미널로 사용하려면 명령행에 다음을 입력하십시오.
/usr/bin/X11/X -query hostname
X 터미널의 역할을 하는 워크스테이션의 X 서버는 다음을 수행해야 합니다.

• XDMCP 및 -query 명령행 옵션을 지원합니다.
• 터미널 호스트에 xhost 사용 권한(/etc/X*.hosts에 있음)을 제공합니다.
로컬 표시장치를 제거하려면 /usr/dt/config 디렉토리에 있는 Xservers 파일에서 해당 항목을 제거하십
시오.
문자 표시화면 터미널 또는 ASCII 터미널은 터미널이 비트맵 장치가 아닌 구성입니다.
비트맵 표시장치가 없는 경우 ASCII 또는 문자 표시화면 콘솔을 추가하려면 다음 단계를 수행하십시오.
1. /etc/dt/config/Xservers 파일이 없는 경우 /usr/dt/config/Xservers 파일을 /etc/dt/
config 디렉토리에 복사하십시오.
2. Xservers 파일을 /etc/dt/config에 복사해야 하는 경우 /etc/dt/config/Xconfig의
Dtlogin.servers: 행을 다음과 같이 변경하거나 추가하십시오.
Dtlogin*servers: /etc/dt/config/Xservers

3. X 서버를 시작하는 /etc/dt/config/Xservers에서 해당 행을 주석 처리하십시오.
# * Local local@console /path/X :0
그러면 로그인 옵션 메뉴를 사용할 수 없게 됩니다.

4. 로그인 관리자 구성 파일을 읽으십시오.
비트맵 표시장치가 있는 경우 문자 표시화면 콘솔을 추가하려면 다음 단계를 수행하십시오.
2. Xservers 파일을 /etc/dt/config에 복사해야 하는 경우 /etc/dt/config/Xconfig의
Dtlogin.servers: 행을 다음과 같이 변경하거나 추가하십시오.
3. /etc/dt/config/Xservers에서 X Server를 시작하는 행을 다음과 같이 편집하십시오.
* Local local@none /path/X :0
4. 로그인 관리자 구성 파일을 읽으십시오.
공통 데스크탑 환경를 위한 장치 사용자 조정 표시

두 개 이상의 표시장치가 있는 시스템에서 실행되도록 공통 데스크탑 환경 로그인 관리자를 구성할 수 있습니다.
시스템에 여러 개의 표시장치가 있는 경우, 다음의 구성 요구사항이 만족되어야 합니다.
• 서버가 각 표시장치에서 시작되어야 합니다.
• 각 표시장치에 대해 Windows 모드가 구성되어서는 안됩니다.
각 표시장치에 대해 다른 dtlogin 자원을 사용하는 것이 필요하거나 바람직할 수 있습니다.
표시장치마다 서로 다른 시스템 환경 변수를 사용하는 것이 필요하거나 바람직할 수 있습니다.
각 표시장치에서 서버 시작
다음 절차를 사용하여 각 표시장치에서 서버를 시작하십시오.
2. Xservers 파일을 /etc/dt/config로 복사할 경우 /etc/dt/config/Xconfig의
Dtlogin.servers: 행을 다음과 같이 변경하십시오.
3. 각 표시장치에서 X 서버를 시작하려면 /etc/dt/config/Xservers를 편집하십시오.

서버 시작 시 일반 구문은 다음과 같습니다.
DisplayName DisplayClass DisplayType [ @ite ] Command
ITE(Internal Terminal Emulator)와 연관된 표시장치만 No Windows Mode로 동작될 수 있습니다. No

Windows 모드는 임시로 표시장치에 대해 데스크탑을 사용 불가능하게 설정한 후 getty 프로세스를 실행합니다
(아직 시작하지 않은 경우). getty 프로세스는 터미널 유형을 설정하고 로그인 프로세스에 사용되는 UNIX 프로그
램입니다.
이 프로세스를 사용하면 로그인한 후 공통 데스크탑 환경에서 불가능한 태스크를 수행할 수 있습니다. 로그아웃
시, 데스크탑은 표시장치에 대해 재시작됩니다. getty 프로세스가 아직 표시장치에서 실행 중이 아니면, No
Windows Mode가 초기화될 때 로그인 관리자가 이를 시작합니다.
디폴트 구성에서 ite가 생략되면 display:0은 ITE(/dev/console)와 연관됩니다.
다른 표시장치를 ITE로 설정
다른 표시장치를 ITE로 설정하려면 이 절차를 사용하십시오.
장치 관리 215
다른 표시장치를 ITE로 지정하려면 다음을 수행하십시오.
• ITE 표시장치에서 ITE를 문자 장치로 설정하십시오.
• 다른 모든 표시장치에서는 ITE를 없음으로 설정하십시오.
다음 예제에서는 sysaaa:0의 세 로컬 표시장치에서 서버를 시작하는 Xserver 파일의 항목을 표시합니다. 표
시장치 :0은 콘솔(ITE)이 됩니다.
sysaaa:0 Local local /usr/bin/X11/X :0

호스트 sysbbb에서 비트맵 표시장치 :0은 ITE가 아니며 ITE는 /dev/ttyi1 장치와 연관됩니다. Xserver 파
일의 다음 항목은 :1에서 No Windows Mode를 사용할 수 있는 두 비트맵 표시장치에서 서버를 시작합니다.
sysaaa:0 Local local@none /usr/bin/X11/X :0

sysaaa:1 Local local@ttyi1 /usr/bin/X11/X :1
Xconfig에서 표시장치 이름 설정
/etc/dt/config/Xconfig에서 표시장치 이름으로 일반 hostname:0 구문을 사용할 수 없습니다.
Xconfig에 표시장치 이름을 지정하려면 다음을 수행하십시오.
• 콜론의 위치에 밑줄 문자를 사용하십시오.
• 완전한 호스트 이름에는 마침표 대신 밑줄 문자를 사용하십시오.
다음 예제에서는 Xconfig에서 표시장치의 이름 설정을 표시합니다.
Dtlogin.claaa_0.resource: value
Dtlogin.sysaaa_prsm_ld_edu_0.resource: value
각 표시장치마다 다른 로그인 관리자 자원 사용

각 표시장치마다 다른 로그인 관리자 자원을 사용하려면 다음 단계를 수행하십시오.
1. /etc/dt/config/Xconfig 파일이 없는 경우, /usr/dt/config/Xconfig 파일을 /etc/dt/
config 디렉토리로 복사하십시오.
2. /etc/dt/config/Xconfig 파일을 편집하여 각 표시장치에 다른 자원을 지정하십시오.
Dtlogin.DisplayName.resources: path/file
여기서 path는 사용할 Xresource 파일의 경로 이름이고 file은 사용할 Xresource 파일의 파일 이름입니다.
3. Xconfig 파일에 지정된 각 자원 파일을 작성하십시오.
언어별 Xresources 파일은 /usr/dt/config/<LANG>에 설치됩니다.
4. 각 파일에서, 해당 표시장치에 대해 dtlogin 자원을 위치시키십시오.
다음 예제에서는 세 개의 표시장치에 서로 다른 자원을 지정하는 Xconfig 파일의 행을 보여 줍니다.
Dtlogin.sysaaa_0.resources: /etc/dt/config/Xresources0
표시장치마다 다른 스크립트 실행
특정 표시장치에 대해 특정 스크립트를 실행하려면 이 절차를 사용하십시오.
2. 각 표시장치에 대해 다른 스크립트를 지정하려면 /etc/dt/config/Xconfig에서 startup, reset 및
setup 자원을 사용하십시오(이러한 파일은 Xstartup, Xreset 및 Xsetup 파일 대신 실행됩니다).

Dtlogin*DisplayName*startup: /path/file
Dtlogin*DisplayName*reset: /path/file
Dtlogin*DisplayName*setup: /path/file
여기서 path는 사용할 파일의 경로 이름이고 file은 사용할 파일의 파일 이름입니다. 시작 스크립트는 사용자가
로그인한 후, 공통 데스크탑 환경 세션이 시작되기 전에 루트에서 실행됩니다.
/usr/dt/config/Xreset 스크립트는 Xstartup 파일에 설정된 내용을 반대로 하는데 사용할 수 있습니다.
Xreset 파일은 사용자가 로그아웃할 때 실행됩니다.
다음 예제는 두 표시장치에 각각 다른 스크립트를 지정하는 Xconfig 파일의 행을 표시합니다.
Dtlogin.sysaaa_0*startup: /etc/dt/config/Xstartup0
Dtlogin.sysaaa_1*startup: /etc/dt/config/Xstartup1
Dtlogin.sysaaa_0*setup: /etc/dt/config/Xsetup0
Dtlogin.sysaaa_1*setup: /etc/dt/config/Xsetup1
Dtlogin.sysaaa_0*reset: /etc/dt/config/Xreset0
Dtlogin.sysaaa_1*reset: /etc/dt/config/Xreset1
표시장치마다 다른 시스템 전반의 환경 변수 설정

각 표시장치의 시스템 전반의 환경 변수를 사용자 조정하려면 이 절차를 사용하십시오.
표시장치마다 다른 시스템 전반 환경 변수를 설정하려면 다음을 수행하십시오.
2. 각 표시장치에 대해 개별적으로 /etc/dt/config/Xconfig 의 환경 자원을 설정하십시오.
Dtlogin*DisplayName*environment: value
다음은 각 표시장치에 대한 환경 변수에 적용되는 규칙입니다.

• 공백 및 탭으로 변수 지정을 분리하십시오.
• TZ 및 LANG을 설정하기 위해 환경 자원을 사용하지 마십시오.
• Xconfig 파일에는 쉘 처리가 없습니다.
다음 예제에서는 두 표시장치의 변수를 설정하는 Xconfig 파일의 행을 표시합니다.
Dtlogin*syshere_0*environment:EDITOR=vi SB_DISPLAY_ADDR=0xB00000
Dtlogin*syshere_1*environment: EDITOR=emacs \
SB_DISPLAY_ADDR=0xB00000
HEA(Host Ethernet Adapter)가 있는 LPM(Live Partition Mobility)

IBM PowerVM® 소프트웨어의 HEA(Host Ethernet Adapter)가 있는 LPM(Live Partition Mobility) 기능을 사용
하면 HEA가 마이그레이션 파티션에 지정되어 있는 동안 AIX LPAR 및 호스팅된 애플리케이션을 한 물리적 파티
션에서 또 다른 물리적 파티션으로 마이그레이션할 수 있습니다.
마이그레이션 동안에 HEA는 마이그레이션 파티션에서 제거되고, HEA는 마이그레이션이 완료될 때 파티션에 복
원되지 않습니다. 그러나, 네트워크 연결성은 영향을 받지 않은 상태로 남아 있습니다.
HEA가 있는 라이브 파티션 이동성 요구사항

HEA가 있는 LPM의 사용을 시작하려면 먼저 시스템 환경이 구성 및 액세스 요구사항을 충족하는지 확인해야 합
니다.
파티션 요구사항
• CEC 소스와 CEC 대상이 파티션 마이그레이션에 사용 가능해야 합니다.
• 소스 AIX LPAR는 프로파일에 Required 설정이 있는 물리적 자원을 가지고 있지 않아야 합니다.
• 소스 AIX LPAR는 HEA 외에 물리적 자원을 가지고 있지 않아야 합니다.
장치 관리 217
액세스 요구사항
• 마이그레이션하려는 파티션에서 루트 권한이 있어야 합니다.
• 소스 HMC 및 대상 HMC에서 파티션 마이그레이션에 필요한 hscroot 권한 또는 동등한 권한이 있어야 합니
다.
구성 요구사항
• HEA는 파티션 프로파일에 Required 설정이 있지 않아야 하지만 프로파일에 Desired 설정은 있을 수 있습
니다.
• 모든 HEA는 EtherChannel 하에서 1차 어댑터로 구성되어야 합니다.
• EtherChannel에서 모든 1차 어댑터는 HEA여야 합니다.
• EtherChannel의 백업 어댑터는 가상 이더넷 어댑터여야 합니다.
• 하나의 EtherChannel의 최소값은 HEA가 1차 어댑터로서 구성되고 가상 이더넷 어댑터가 백업 어댑터로
서 구성되어야 합니다.
• 최대 네 개의 EtherChannel이 지원됩니다.
• EtherChannel 장애 복구가 기능해야 합니다.
• 소스 시스템과 대상 시스템 둘 모두가 파티션 마이그레이션을 위해 설정되었는지 검증해야 합니다.
• 두 개의 HMC 간에 마이그레이션 중인 경우에는 소스 HMC와 원격 HMC 사이에 SSH 인증을 설정해야 합니
다. 마이그레이션을 시작하기 전에 소스 HMC에서 mkauthkeys 명령을 실행해야 합니다.
HEA가 있는 라이브 파티션 이동성 실행

SMIT 인터페이스를 사용하여 HEA가 있는 LPM을 실행할 수 있습니다.
HEA가 있는 LPM을 사용하려고 시도하기 전에 217 페이지의 『HEA가 있는 라이브 파티션 이동성 요구사항』
주제를 검토하십시오.
HEA가 있는 LPM 파티션 마이그레이션을 완료하려면 다음 단계를 완료하십시오.
1. 명령 프롬프트에 smitty migration SMIT 단축 경로를 입력하여 HEA(Host Ethernet Adapter)가 있는
라이브 파티션 이동(LPM) 메뉴를 표시하십시오.
2. 소스 HMC 호스트 이름 또는 IP 주소를 지정하십시오.
3. 소스 HMC 사용자 이름을 지정하십시오.
4. 소스 및 대상 시스템이 동일한 HMC에 의해 관리되는 경우 no를 입력하고 5단계로 이동하십시오. 소스와 대
상 시스템이 서로 다른 HMC에 의해 관리되는 경우에는 yes를 입력하고 다음 단계를 완료하십시오.
참고: yes를 입력하기 전에 소스 HMC에서 mkauthkeys 명령을 실행해야 합니다.
a) 원격 HMC 호스트 이름 또는 IP 주소를 지정하십시오.
b) 소스 HMC 사용자 이름을 지정하십시오.
5. 소스 시스템의 이름을 지정하십시오.
6. 대상 시스템의 이름을 지정하십시오.
7. 마이그레이션하려는 파티션의 이름을 지정하십시오.
8. 유효성 확인 없이 마이그레이션을 수행하려면 no를 입력하십시오. 마이그레이션 유효성 확인만을 수행하려
면 yes를 입력하십시오. yes를 지정하면 마이그레이션이 수행되지 않고 유효성 확인만이 수행됩니다.
참고: 파티션 마이그레이션을 수행하기 전에 파티션 마이그레이션 유효성 확인을 수행해야 합니다.
9. 모든 필드에 올바른 정보가 있음을 확인하고 Enter를 눌러 마이그레이션을 실행하십시오.
참고: 비밀번호를 입력하라는 프롬프트가 두 번 표시됩니다. 이전에 4b 단계에 지정한 소스 HMC 사용자 이름
의 비밀번호를 입력하십시오.
이 예에서 파티션 X는 HMC A가 관리하는 CEC C에서 HMC B가 관리하는 CEC D로 마이그레이션되는 중입니다.
HMC A와 HMC B 사이의 인증을 위해 HMC A에서 mkauthkeys 명령을 실행하십시오.

이 마이그레이션 프로세스의 경우 다음 값이 SMIT에 지정됩니다.
Source HMC Hostname or IP address: A

Source HMC username: hscroot
Migration between two HMCs: yes
Remote HMC hostname or IP address: B
Remote HMC username: hscroot
Source system: C
Destination system: D
Migrating Partition name: X
Migration validation only: no
또 다른 예는 파티션 X가 HMC A가 관리하는 CEC C에서 마찬가지로 HMC A가 관리하는 CEC D로 마이그레이션
되는 중인 경우입니다.
이 마이그레이션 프로세스의 경우 다음 값이 SMIT에 지정됩니다.
Source HMC Hostname or IP address: A

Source HMC username: hscroot
Migration between two HMCs: no
Remote HMC hostname or IP address:
Remote HMC username:
Source system: C
Destination system: D
Migrating Partition name: X
Migration validation only: no
마이그레이션 실패의 경우 소스 HMC에서 LPM(Live Partition Mobility)을 수행하기 위한 프로시저를 수행하십

시오.
LPM을 사용하여 NIM 클라이언트 마이그레이션

LPM(Live Partition Mobility)이 시스템을 한 물리적 서버에서 또 다른 물리적 서버로 이동하는 데 사용되고, 시스
템이 NIM(Network Installation Management) 클라이언트로 정의된 경우에는, NIM 관리자는 LPM 마이그레이
션이 완료된 후에 새 하드웨어 값을 반영하기 위해 NIM 클라이언트의 cpuid 속성을 갱신해야 합니다.
cpuid 속성을 갱신하려면 다음 단계를 완료하십시오.
1. NIM 클라이언트에서 다음 명령을 실행하여 새 cpuid ID를 구하십시오.
uname -a
2. NIM 마스터에서 다음 명령을 실행하십시오.

nim -o change -a cpuid=cpuid client
참고: OS_install 네트워크 설치 프로그램은 AIX 운영 체제에서 CSM(Cluster Systems Management) 지

원이 제거되었으므로 더 이상 Linux® 운영 체제의 설치를 지원하지 않습니다.
DLPAR을 위해 어댑터 재배치

동적 논리적 파티션(DLPAR) 조작을 위해 어댑터를 재배치하기 전에 그래픽 어댑터를 구성해야 합니다.
FC 5748과 같은 그래픽 어댑터를 동적으로 재배치하려면 다음 지시사항을 사용하십시오.
1. 현재 프로세스(데스크탑 및 Xserver)가 그래픽 어댑터(예: /dev/lft0)를 사용하고 있지 않은지 확인하십시오.
2. 콘솔이 lft0으로 설정되지 않았는지 확인하십시오. 정의되거나 사용 가능한 종속 인터페이스(lft 또는 rcm)를
식별하려면 다음 명령을 입력하십시오.
lsdev -C | grep lft
lsdev -C | grep rcm
그래픽 어댑터가 정의된 후에 상위 주변 기기 구성요소 상호연결(PCI) 어댑터를 획득하려면 다음 명령을 입력

하십시오.
odmget -q name=<cortina adapter name. for instance cor0> CuDv
이 명령은 상위 및 코르티나에 대한 정보를 제공합니다.
장치 관리 219
3. 어댑터가 DLPAR 조작에 준비될 수 있도록 모든 종속 인터페이스를 제거하려면 다음 명령을 입력하십시오.
# pdisable lft0
# rmdev -l rcm0
rcm0 Defined
# rmdev -l lft0
lft0 Defined
# rmdev -Rdl pci23

cor0 deleted
pci23 deleted
관리 콘솔 인터페이스는 그래픽 어댑터에서 DLPAR 조작에 사용될 수 있습니다.
루프백 디바이스
루프백 디바이스는 파일에 액세스하기 위해 블록 장치로 사용할 수 있는 장치입니다.
루프백 파일은 ISO 이미지, 디스크 이미지, 파일 시스템 또는 논리적 볼륨 이미지를 포함할 수 있습니다. 예를 들
어, CD-ROM ISO 이미지를 루프백 디바이스에 연결하고 이를 마운트하면, CD-ROM 장치에 액세스하는 것과 같
은 방법으로 이미지에 액세스할 수 있습니다.
loopmount 명령을 사용하여 루프백 디바이스를 작성하고, 지정된 파일을 루프백 디바이스에 바인드하고, 루프
백 디바이스를 마운트하십시오. loopumount 명령을 사용하여 루프백 디바이스에서 이전에 마운트된 이미지
파일을 마운트 해제하고, 장치를 제거하십시오. AIX에서 루프백 디바이스의 수에는 한계가 없습니다. 루프백 디
바이스는 기본적으로 작성되지 않고 장치를 명시적으로 작성해야 합니다. 루프백 디바이스의 블록 크기는 항상
512바이트입니다.
새 장치는 또한 mkdev 명령으로 작성되고, chdev 명령으로 변경되고, rmdev 명령으로 제거될 수도 있습니다.
장치가 작성된 후에는 기본 이미지에 액세스하기 위해 마운트되거나, 원시 입출력을 위해 블록 장치로서 사용될
수 있습니다. 기본 이미지에 대한 정보는 ioctl (IOCINFO) 명령으로 검색할 수 있습니다.
AIX에서 루프백 디바이스에 다음 제한사항이 적용됩니다.
• 디스크 이미지에서 varyonvg 명령은 지원되지 않습니다.
• CD ISO 및 DVD UDF+ISO 및 기타 CD/DVD 이미지는 읽기 전용 형식에서만 지원됩니다.
• 이미지 파일은 단 하나의 루프백 디바이스와만 연관될 수 있습니다.
• 루프백 디바이스는 워크로드 파티션에서는 지원되지 않습니다.

주의사항
이 정보는 미국에서 제공되는 제품 및 서비스용으로 작성된 것입니다.
IBM은 다른 국가에서 이 책에 기술된 제품, 서비스 또는 기능을 제공하지 않을 수도 있습니다. 현재 사용할 수 있
는 제품 및 서비스에 대한 정보는 한국 IBM 담당자에게 문의하십시오. 이 책에서 IBM 제품, 프로그램 또는 서비
스를 언급했다고 해서 해당 IBM 제품, 프로그램 또는 서비스만을 사용할 수 있다는 것을 의미하지는 않습니다.
IBM의 지적 재산권을 침해하지 않는 한, 기능상으로 동등한 제품, 프로그램 또는 서비스를 대신 사용할 수도 있
습니다. 그러나 비IBM 제품, 프로그램 또는 서비스의 운영에 대한 평가 및 검증은 사용자의 책임입니다.
IBM은 이 책에서 다루고 있는 특정 내용에 대해 특허를 보유하고 있거나 현재 특허 출원 중일 수 있습니다. 이 책
을 제공한다고 해서 특허에 대한 라이센스까지 부여하는 것은 아닙니다. 라이센스에 대한 의문사항은 다음으로
문의하십시오.
07326
서울특별시 영등포구
국제금융로 10, 3IFC
한국 아이.비.엠 주식회사
대표전화서비스: 02-3781-7114
2바이트 문자 세트(DBCS) 정보에 관한 라이센스 문의는 한국 IBM에 문의하거나 다음 주소로 서면 문의하시기

바랍니다.
Intellectual Property Licensing

Legal and Intellectual Property Law
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan
IBM은 타인의 권리 비침해, 상품성 및 특정 목적에의 적합성에 대한 묵시적 보증을 포함하여(단, 이에 한하지 않
음) 묵시적이든 명시적이든 어떠한 종류의 보증 없이 이 책을 "현상태대로" 제공합니다.일부 국가에서는 특정 거
래에서 명시적 또는 묵시적 보증의 면책사항을 허용하지 않으므로, 이 사항이 적용되지 않을 수도 있습니다.
이 정보에는 기술적으로 부정확한 내용이나 인쇄상의 오류가 있을 수 있습니다. 이 정보는 주기적으로 변경되며,
변경된 사항은 최신판에 통합됩니다. IBM은 이 책에서 설명한 제품 및/또는 프로그램을 사전 통지 없이 언제든지
개선 및/또는 변경할 수 있습니다.
이 정보에서 언급되는 비IBM의 웹 사이트는 단지 편의상 제공된 것으로, 어떤 방식으로든 이들 웹 사이트를 옹호
하고자 하는 것은 아닙니다. 해당 웹 사이트의 자료는 본 IBM 제품 자료의 일부가 아니므로 해당 웹 사이트 사용
으로 인한 위험은 사용자 본인이 감수해야 합니다.
IBM은 귀하의 권리를 침해하지 않는 범위 내에서 적절하다고 생각하는 방식으로 귀하가 제공한 정보를 사용하
거나 배포할 수 있습니다.
(i) 독립적으로 작성된 프로그램과 기타 프로그램(본 프로그램 포함) 간의 정보 교환 및 (ii) 교환된 정보의 상호 이
용을 목적으로 본 프로그램에 관한 정보를 얻고자 하는 라이센스 사용자는 다음 주소로 문의하십시오.
07326
서울특별시 영등포구
국제금융로 10, 3IFC
한국 아이.비.엠 주식회사
대표전화서비스: 02-3781-7114
이러한 정보는 해당 조건(예를 들면, 사용료 지불 등)하에서 사용될 수 있습니다.

이 정보에 기술된 라이센스가 부여된 프로그램 및 프로그램에 대해 사용 가능한 모든 라이센스가 부여된 자료는
IBM이 IBM 기본 계약, IBM 프로그램 라이센스 계약(IPLA) 또는 이와 동등한 계약에 따라 제공한 것입니다.
인용된 성능 데이터와 고객 예제는 예시 용도로만 제공됩니다. 실제 성능 결과는 특정 구성과 운영 조건에 따라
다를 수 있습니다.
© Copyright IBM Corp. 2010, 2019 221

비IBM 제품에 관한 정보는 해당 제품의 공급업체, 공개 자료 또는 기타 범용 소스로부터 얻은 것입니다. IBM에
서는 이러한 제품들을 테스트하지 않았으므로, 비IBM 제품과 관련된 성능의 정확성, 호환성 또는 기타 청구에 대
해서는 확신할 수 없습니다. 비IBM 제품의 성능에 대한 의문사항은 해당 제품의 공급업체에 문의하십시오.
IBM이 제시하는 방향 또는 의도에 관한 모든 언급은 특별한 통지 없이 변경될 수 있습니다.
여기에 나오는 모든 IBM의 가격은 IBM이 제시하는 현 소매가이며 통지 없이 변경될 수 있습니다. 실제 판매가는
다를 수 있습니다.
이 정보는 계획 수립 목적으로만 사용됩니다. 이 정보는 기술된 제품이 GA(General Availability)되기 전에 변경
될 수 있습니다.
이 정보에는 일상의 비즈니스 운영에서 사용되는 자료 및 보고서에 대한 예제가 들어 있습니다. 이들 예제에는 개
념을 가능한 완벽하게 설명하기 위하여 개인, 회사, 상표 및 제품의 이름이 사용될 수 있습니다. 이들 이름은 모두
가공의 것이며 실제 인물 또는 기업의 이름과 유사하더라도 이는 전적으로 우연입니다.
저작권 라이센스:
이 정보에는 여러 운영 플랫폼에서의 프로그래밍 기법을 보여주는 원어로 된 샘플 응용프로그램이 들어 있습니
다. 귀하는 이러한 샘플 프로그램의 작성 기준이 된 운영 플랫폼의 애플리케이션 프로그래밍 인터페이스(API)에
부합하는 애플리케이션을 개발, 사용, 판매 또는 배포할 목적으로 IBM에 추가 비용을 지불하지 않고 이들 샘플
프로그램을 어떠한 형태로든 복사, 수정 및 배포할 수 있습니다. 이러한 샘플 프로그램은 모든 조건하에서 완전히
테스트된 것은 아닙니다. 따라서 IBM은 이들 샘플 프로그램의 신뢰성, 서비스 가능성 또는 기능을 보증하거나 진
술하지 않습니다. 본 샘플 프로그램은 일체의 보증 없이 "현상태대로" 제공됩니다. IBM은 귀하의 샘플 프로그램
사용과 관련되는 손해에 대해 책임을 지지 않습니다.
이러한 샘플 프로그램 또는 파생 제품의 각 사본이나 그 일부에는 반드시 다음과 같은 저작권 표시가 포함되어야
합니다.
© (귀하의 회사명) (연도).
이 코드의 일부는 IBM Corp.의 샘플 프로그램에서 파생됩니다.

© Copyright IBM Corp. _enter the year or years_.
개인정보처리방침 고려사항
SaaS(Software as a Service) 솔루션을 포함한 IBM 소프트웨어 제품(이하 "소프트웨어 오퍼링")은 제품 사용 정
보를 수집하거나 최종 사용자의 경험을 개선하는 데 도움을 주거나 최종 사용자와의 상호 작용을 조정하거나 그
외의 용도로 쿠키나 기타 다른 기술을 사용할 수 있습니다. 많은 경우에 있어서, 소프트웨어 오퍼링은 개인 식별
정보를 수집하지 않습니다. IBM의 일부 소프트웨어 오퍼링은 귀하가 개인 식별 정보를 수집하도록 도울 수 있습
니다. 본 소프트웨어 오퍼링이 쿠키를 사용하여 개인 식별 정보를 수집할 경우, 본 오퍼링의 쿠키 사용에 대한 특
정 정보가 다음에 규정되어 있습니다.
본 소프트웨어 오퍼링은 개인 식별 정보를 수집하기 위해 쿠키 및 기타 다른 기술을 사용하지 않습니다.
본 소프트웨어 오퍼링에 배치된 구성이 쿠키 및 기타 기술을 통해 최종 사용자의 개인 식별 정보 수집 기능을 고
객인 귀하에게 제공하는 경우, 귀하는 통지와 동의를 위한 요건을 포함하여 이러한 정보 수집과 관련된 법률 자문
을 스스로 구해야 합니다.
이러한 목적의 쿠키를 포함한 다양한 기술의 사용에 대한 자세한 정보는 IBM 개인정보처리방침 주요 내용
(http://www.ibm.com/privacy/kr/ko), IBM 온라인 개인정보처리방침(http://www.ibm.com/privacy/
details/kr/ko/) “쿠키, 웹 비콘 및 기타 기술” 및 “IBM 소프트웨어 제품 및 SaaS(Software-as-a Service) 개인정
보처리방침”(http://www.ibm.com/software/info/product-privacy) 부분을 참조하십시오.
상표
IBM, IBM 로고 및 ibm.com은 전세계 여러 국가에 등록된 International Business Machines Corp.의 상표 또는
등록상표입니다. 기타 제품 및 서비스 이름은 IBM 또는 타사의 상표입니다. 현재 IBM 상표 목록은 웹 저작권 및
상표 정보(www.ibm.com/legal/copytrade.shtml)에 있습니다.
UNIX는 미국 또는 기타 국가에서 사용되는 The Open Group의 등록상표입니다.
Windows는 미국 및 기타 국가에서 사용되는 Microsoft Corporation의 상표입니다.

색인
특수 문자 i-노드 (계속)
당 바이트 수(NBPI)
.hushlogin 파일 208 식별 104
/(루트) 파일 시스템 72 지정 104
/export 디렉토리 78 및 프래그먼트 102
/opt 파일 시스템 71 i-노드 번호 113
/proc 파일 시스템 71 i-노드, 수 105
/usr/share 디렉토리 76 i-노드당 바이트 수(NBPI) 104
/var 파일 시스템 77 id 명령 208
A J
API JFS
워크로드 관리자(WLM) 152 다른 물리적 볼륨에 복사 111
API(Application Programming Interface) JFS 로그 13
워크로드 관리자(API) 152 JFS2 로그 13
ASCII 터미널
추가 213
L
C ln 명령 113
login
cd 명령 114, 116 개요 207
CD-ROM 디렉토리 207
파일 시스템 84 메시지 억제 208
CD-ROM 파일 시스템(CDRFS) 100 이름 206
CDRFS 파일 시스템 84 이름 표시 209
cfgmgr 186 login 명령 208
chdev 명령 183 logname 명령 209
cp 명령 116 logout
개요 207
logout 명령 208
D lsattr 명령 183
df 명령 80 lsdev 명령 183
dials/LPFKeys 위치 코드 159 LVCB(논리적 볼륨 제어 블록)
dircmp 명령 119 원시 논리적 볼륨 액세스에서 보호되지 않음 45
DVD LVM 9, 35
파일 시스템 84
M
E mkdev 명령 183
EFS mkdir 명령 115
암호화된 파일 시스템 79 MPIO
exit 명령 208 관리 168
mvdir 명령 115
MWC(미러 쓰기 일관성) 53
F
files N
.hushlogin 208
경로 이름 114 NBPI 104
마운트 96 NFS(Network File System) 100
비교 119
P
I passwd 명령 211
i-노드 pwd 명령 116
가변 수 104
색인 223
R 공통 데스크탑 환경
표시장치 및 터미널 제거 213
rmdir 명령 118 표시장치 및 터미널 추가 213
표시장치 사용자 조정 215
프로파일 수정 213
S 광 드라이브
SCSI 장치 구성 36
위치 코드 159 광학 미디어
skulker 명령 26 읽기/쓰기에서 파일 시스템 사용 84
SPOT 디렉토리 78 기록 검증 정책 60
SPOT(Shared Product Object Tree) 디렉토리 78
su 명령 208 나
네트워크
T 시스템 이름 표시 210
touch 명령 208 논리적 볼륨
tty(전신 타자기) 기록 검증 정책 60
위치 코드 158 다른 물리적 볼륨에 복사 12
다른 시스템으로 컨텐츠 이동 16
디스크 대체 32
U 맵 파일 59
볼륨 그룹 정책 62
uname 명령 210
스트라이프 59
USB 블루 레이 드라이브 지원 199
신규에 파일 시스템 추가 79
USB 장치 지원 198
원시
USB 플래시 드라이브 198
정의 45
이름 변경 12
V 전략 52
정의 41
VGDA(volume group descriptor area) 2 제한사항 33
VGSA(volume group status area) 2 크기
VMM 68 검사 79
늘리기 79
W 줄이기 79
핫 스팟 60
who 명령 209, 210 논리적 볼륨 관리자 9
who am i 명령 209 논리적 볼륨 관리자(LVM)
whoami 명령 209 장치 구성 데이터베이스와 동기화 34
WLM 정의 1
API 152 논리적 볼륨 스토리지
논리적 볼륨 41
논리적 파티션 42
X 디스크 간 할당 정책 54, 58
X 터미널 213 디스크 오버플로우 92
물리적 볼륨 40
볼륨 그룹 40
가 비쿼럼 볼륨 그룹 8
쓰기 스케줄링 정책 53
가변 i-노드 수 정의 39
및 프래그먼트 102 최대 크기 42
가상 메모리 관리자 68 쿼럼 2
가상 메모리 관리자(VMM) 파일 시스템 42
개요 62 논리적 볼륨 암호화 50
가용성 논리적 볼륨 제어 블록
디스크 장애 51 원시 논리적 볼륨 액세스에서 보호되지 않음 45
어댑터 또는 전원 공급장치 장애 51 논리적 볼륨의 핫 스팟 60
경로 논리적 파티션
디렉토리 114 디스크 간 할당 전략 55
경로 이름 정의 42
디렉토리 114 크기 정의 87
상대 114
절대 114
공간
사용 가능 표시 80

다 로그인 (계속)
다른 사용자로 208
다시 포맷하지 않고 디스크에서 데이터 복구 27 운영 체제에 207
다중 경로 입출력 166 한 번 이상 208
데이터 압축 루트 볼륨 그룹(rootvg)
성능에 미치는 영향 109 미러링 43
프래그먼트 102 파일 시스템의 크기 줄이기 87
독점 사용 RSET 루트 파일 시스템 71
독점 사용 프로세서 자원 세트 148 루트(/) 파일 시스템 72
디렉토리
개요 113
경로 이름 114 마
구조 114 마운트
루트 사용자 113 /etc/filesystem 자동 마운트 97
마운트 96 다중 마운트 사용 96
변경 116 디스크 없는 워크스테이션 마운트
복사 116 보안 98
삭제 118 설명 99
상위 114 로컬
서브디렉토리 114 정의 96
유형 113 원격
이동 115 정의 96
이름 바꾸기 115 자동 마운트 97
작성 115 파일 시스템 마운팅 96
작업 114 마운트 위치 96
제거 118 맵 파일 59
조직 114 멀티프로토콜 포트
컨텐츠 비교 119 위치 코드 160
표시 116 명령
홈 114 cd 114, 116
디렉토리 트리 114 chdev 183
디스크 cp 116
제거 46 df 80
추가 11 dircmp 119
디스크 간 할당 전략 54, 58 exit 208
디스크 드라이브 id 208
공간 비우기 26 ln 113
다른 디스크에서 공간 마운팅 26 login 208
더 이상 사용하지 않는 파일 제거 26 logname 209
데이터 복구 logout 208
다시 포맷하지 않음 27 lsattr 183
디렉토리에 대한 액세스 제한 26 lsdev 183
디스크의 파일 시스템 마운트 해제 82 mkdev 183
문제점 복구 25 mkdir 115
진단 25 mvdir 115
디스크 드라이브 문제점 진단 25 passwd 211
디스크 드라이브(하드 드라이브) pwd 116
실패 rmdir 118
복구 예제 31 su 208
파일 시스템 나열 82 touch 208
디스크 사용량 uname 210
프래그먼트의 영향 102 who 209, 210
디스크 스트라이핑 59 who am i 209
디스크 없는 워크스테이션 whoami 209
마운트 보안 98 명령 및 단축 경로 9
디스크 오버플로우, 수정 92 명령 요약
디스크(하드 드라이브) 로그인 이름 212
구성 17 비밀번호 212
시스템 ID 212
라 목표 디바이스 구성 186
문자 표시화면 터미널
로그아웃 추가 213
운영 체제에서 208 물리적 볼륨
로그인 논리적 볼륨을 다른 곳에 복사 12
색인 225
물리적 볼륨 (계속) 사용자
디스크 구성 17 다른 사용자로 변경 208
사용 가능한 디스크 드라이브에서 작성 19 로그인한 사용자 표시 210
정의 40 시스템 ID 표시 208
컨텐츠 이동 16 사용자 정의 볼륨 그룹
JFS를 또 다른 위치에 복사 111 반입 87
물리적 파티션 사용자 정의 볼륨 그룹 반입 87
정의 40 사용자 조정
크기 40 장치 표시 215
미러 제거 사용자 ID
볼륨 그룹 45 다른 사용자로 변경 208
미러링 삭제
루트 볼륨 그룹(rootvg) 43 디렉토리 118
볼륨 그룹 43 상대 경로 이름 114
볼륨 그룹에서 미러링된 디스크 분할 24 상위 디렉토리 114
색인 노드 참조 번호 113
성능
바 개선
백업 원시 논리적 볼륨 정의 45
프래그먼트의 영향 111 세 자리 숫자 표시장치 207
범위 설정 55 세 자리 숫자 표시장치 읽기 207
변경 소프트웨어
다른 디렉토리로 116 장치 문제 확인 183
다른 사용자로 208 수정
복원 데스크탑 프로파일 213
프래그먼트의 영향 111 스왑 공간
볼륨 그룹 페이징 공간 참조 62
고가용성 50 시스템
디스크 대체 32 사용통계 206
루트 사용자 이름 표시 210
미러링 43 전원 공급 207
미러 제거 45 실패한 디스크 드라이브
미러링 43 복구 예제 31
미러링된 디스크 분할 24 실패한 디스크 드라이브의 복구 프로시저
반입 15 예 31
반출 15 쓰기 스케줄링 정책 53
별도로 작성하는 시기 50
비쿼럼 8 아
비쿼럼 상태로 변경 8
사용자 정의 어댑터 위치 코드 157
반입 87 엄격성 디스크 간 설정 56
연결 변환 프로세스 2 연결 변환 프로세스
이동 15 실패 재정의 34
전략 50 오류 로깅
정의 40 장치 오류 확인 183
정책 구현 62 운영 체제
쿼럼 2 로그아웃 208
볼륨 그룹에서 미러링된 디스크 분할 24 로그인 207
블록 이름 표시 210
성능에 미치는 영향 105 워크로드 관리자
비밀번호 시작과 중지 126
가이드라인 211 API 152
널(NULL)로 설정 211 워크로드 관리자 시작 126
변경 또는 설정 211 워크로드 관리자 정지 126
설명 206 원격
비쿼럼 볼륨 그룹 8 login 206
원시 논리적 볼륨
정의 45
사 위치 코드
사용 가능 파일 시스템 멀티프로토콜 포트 160
대형 파일 위치(geometry) 107 어댑터 157
사용 가능 공간 107 정의됨 157
작성 107 프린터/플로터 158
dials/LPFKeys 159

위치 코드 (계속) 캐싱 (계속)
SCSI 장치 159 관리 205
tty 158 구성 201
유지보수 9 구성요소 201
이름 바꾸기 장점 200
디렉토리 115 전용 모드에서 구성 201
통계 모니터링 206
NPIV 모드에서 구성 205
자 케이블
작성 연결 확인 184
디렉토리 115 쿼럼
작업 디렉토리 114 비쿼럼 볼륨 그룹 8
장치 비쿼럼 상태로 변경 8
노드 156 정의 2
다수 구성 37
상태 157 타
상태 확인 183
새로 정의 183 테이프 드라이브
설치 36 관리 187
소프트웨어 확인 183 속성
속성 변경 183 변경 가능 187, 189–196
속성 확인 183 특수 파일 197
연결 상태 확인 184
위치 코드 157
읽기/쓰기 광 드라이브 구성 36
파
준비 상태 확인 185 파일 시스템
진단 실행 185 /opt 71
클래스 156 /proc 71
MPIO 관리 명령 79, 80
케이블 연결 168 관리 태스크 79
MPIO 사용 가능 168 구조 71
장치 구성 데이터베이스 그룹
논리적 볼륨 관리자와 동기화 34 마운트 82
장치 드라이버 마운트 해제 중 82
크기에 프래그먼트 사용 시 미치는 영향 111 대형 파일 107
재배치 데이터 압축 107
DLPAR을 위한 어댑터 219 디스크 오버플로우 92
저널 파일 시스템(JFS) 루트 볼륨 그룹에서 크기 줄이기 87
가변 i-노드 수 102 루트 사용자 71
데이터 압축 107 마운트 82, 96
읽기/쓰기 광학 미디어 84 마운트 해제 중 82
최대 크기 105 무결성 확인 86
크기 제한 104 무시 45
프래그먼트 102 사용 가능한 공간 80
저널 파일 시스템(JFS) 로그 설명 206
크기 105 손상된 수정 90
절대 경로 이름 114 스파스 파일 106
제거 유형
로컬 표시장치 213 저널 파일 시스템(JFS) 100
제한사항 확장 저널 파일 시스템(JFS2) 100
논리적 볼륨 33 CD-ROM 100
지정된 디렉토리에서 사용자 제한 26 DVD-ROM 100
NFS(Network File System) 100
차 이미지 111
읽기/쓰기 광학 미디어 84
초강력 엄격성 디스크 간 설정 56 저널 파일 시스템(JFS) 100
파일 트리
/(루트) 파일 시스템 72
카 /export 디렉토리 78
캐싱 /usr 파일 시스템 74
가상 모드에서 구성 203 /usr/share 디렉토리 76
개념 199 /var 파일 시스템 77
고가용성 고려사항 205 개요 70
색인 227
파일 시스템 (계속)
파일 트리 (계속)
루트(/) 파일 시스템 72
프래그먼트 102
홈 71
확장 저널 파일 시스템(JFS2) 100
CD-ROM 파일 시스템(CDRFS) 100
CDRFS 84
i-노드 102
NFS(Network File System) 100
UDFS 84
파일 시스템 검증 86
파일 시스템 로그 13
파일 시스템 사용 가능
파일 할당 제로(0)로 만들기 107
파일 시스템 프래그먼트 주소 지정 가능성 105
파일 시스템에서 불일치 확인 86
파일 할당 제로(0)로 만들기 107
페이징 공간
개요 62
관리 명령 64
늦은 할당 모드 63
작성을 위한 특성 64
제거 66
조기 할당 모드 63
특성 변경 66
할당 63
hd6 이동 66
hd6의 크기 변경 66
표시
로그인 이름 209
로그인한 사용자 210
사용 가능한 공간 80
사용자 시스템 이름 210
사용자 ID 208
운영 체제 이름 210
파일 디렉토리 116
프래그먼트
디스크 사용량에 미치는 영향 102
및 가변 i-노드 수 102
백업/복원에 미치는 영향 111
성능에 미치는 영향 105
장치 드라이버의 제한 111
크기
식별 104
지정 104
프린터
위치 코드 158
하
하드 디스크 17
하드 디스크 드라이브(하드 드라이브)
디스크 드라이브 참조 26
할당 그룹 크기 105
할당, 파일 제로(0)로 만들기(kproc) 107
핫 디스크 제거 11, 46
핫 제거 32, 46, 47
핫 플러그 관리
PCI 163
홈 디렉토리 114
홈 파일 시스템 71
확장 저널 파일 시스템(JFS2)
크기 제한 104, 106

IBM®

Devicemanagement PDF

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Devicemanagement PDF

Uploaded by

Copyright:

Available Formats

AIX 버전 7.

이 개정판은 새 개정판에서 별도로 명시하지 않는 한, AIX 버전 7.2 및 모든 후속 릴리스에 적용됩니다.

이 문서에 관한 정보................................................................................................. vii

© Copyright IBM Corp. 2010, 2019 vii

새로운 정보 또는 변경된 정보를 확인하는 방법

© Copyright IBM Corp. 2010, 2019 1

새 미러 풀을 작성할 때 미러 풀 이름을 지정해야 합니다. 미러 풀 이름은 다음 규칙을 준수해야 합니다.

지리적 논리적 볼륨 관리자

Node 1_1 Node 2_1

1차 사이트(사이트 1)의 Node 1_1에서 실행 중인 워크로드는 1차 사이트에 있는 로컬 디스크(1차 디스크)에 데

이 명령을 실행하는 경우, 비동기 agmvg 볼륨 그룹이 작성됩니다. 볼륨 그룹에는 두 개의 디스크(hdisk5

이 명령을 실행하는 경우 미러 풀 mp1이 hdisk5 및 hdisk15 디스크에 대해 작성됩니다.

mklv -t jfs2 -y glv -p copy1=mp1 -b n -s s -u 1 agmvg 10

• 다음 명령을 실행하여 log 논리적 볼륨을 작성하십시오.

mklv -t jfs2log -y glv_log -p copy1=mp1 -b n -s s -u 1 agmvg 10

d. 다음 명령을 실행하여 data 논리적 볼륨 및 log 논리적 볼륨에 사용해야 하는 저널 파일 시스템(JFS2) 파

e. RPV 서버 및 RPV 클라이언트에서 비동기 볼륨 그룹의 미러 사본을 작성하십시오.

• 다음 명령을 실행하여 2차 사이트의 비동기 미러링 특성을 구성하십시오.

• 다음 명령을 실행하여 chmp 명령이 성공적인지를 검증하십시오.

다음 예제와 유사한 출력이 표시됩니다.

• 다음 명령을 실행하여 GLVM 환경에서 활성화된 비동기 입출력 조작 요청 및 연결 수를 모니터하십시오.

다음 예제와 유사한 출력이 표시됩니다.

Remote Physical Volume Statistics:

rpvstat -n 명령을 사용하여 사이트에 연결하는 네트워크의 상태 및 사용법을 확인할 수 있습니다.

볼륨 그룹을 비쿼럼 상태로 변환

표 2. 논리적 볼륨 및 스토리지 관리 태스크

데이터가 없는 하드 디스크를 기존 smit extendvg

새 볼륨 그룹 추가 및 활성화 smit mkvg

데이터 할당을 사용하도록 논리적 smit chlv1

자동 활성화를 사용하도록 볼륨 그 smit chvg

새 논리적 볼륨에 논리적 볼륨 복사 smit cplv

크기가 동일한 기존 논리적 볼륨에 smit cplv

크기가 큰 기존 논리적 볼륨에 논리 smit cplv

논리적 볼륨의 크기 늘리기 smit extendlv

볼륨 그룹별로 모든 논리적 볼륨 나 smit lslv2

물리적 볼륨의 상태, 논리적 볼륨 또 smit lspv

논리적 볼륨의 상태 또는 맵핑 나열 smit lslv

볼륨 그룹 재구성 smit reorgvg

디스크 구성 해제 및 전원 차단 smit rmvdsk1 또는 smit

– 새 볼륨 그룹에 디스크를 추가하려면 명령행에 다음 단축 경로를 입력하십시오.

• 디스크에 데이터가 포함된 경우 데이터를 반입하십시오.

여기서 FSname은 파일 시스템의 전체 이름입니다.

여기서 -n 플래그는 새 논리적 볼륨의 이름(NewLVname)을 지정하고 OldLVname은 변경할 이름입니다. 예

이때, 논리적 볼륨의 이름이 바뀌고 사용할 수 있게 됩니다.

논리적 볼륨을 또 다른 물리적 볼륨으로 복사하기

원래 논리적 볼륨을 사용 가능한 상태로 유지하면서 논리적 볼륨 복사

주의: 다음 단계에서는 splitlvcopy 명령을 사용합니다. 논리적 볼륨을 분할하기 전에는 항상 논리

splitlvcopy -y newlv oldlv

다른 물리적 볼륨에 원시 논리적 볼륨 복사

2. 다음 명령을 사용하여, 새 미러 사본의 파티션을 동기화하십시오.

3. 다음 명령을 사용하여, 물리적 볼륨에서 논리적 볼륨 사본을 제거하십시오.

이때, 원시 논리적 볼륨 사본이 사용 가능하게 됩니다.

사용자 정의 볼륨 그룹용 전용 디스크에 파일 시스템 로그 작성

2. SMIT 단축 경로를 사용하여 새 논리적 볼륨을 이 볼륨 그룹에 추가하십시오.

3. 논리적 볼륨 추가 화면에서, 다음 필드에 데이터를 추가하십시오. 예를 들어 다음과 같습니다.

Number of LOGICAL PARTITIONS 1

PHYSICAL VOLUME names hdisk1

Logical volume TYPE jfslog

POSITION on Physical Volume center

4. 필드를 설정한 후, Enter 키를 눌러 변경사항을 승인하고 SMIT를 종료하십시오.

6. 다음 프롬프트가 나타나면 y를 입력하고 Enter를 누르십시오.

이 프롬프트가 의미하는 바와는 달리 어떤 것도 삭제되지 않습니다. 이 프롬프트에 y를 응답하면 시스템은

8. 2단계에서 사용한 것과 동일한 볼륨 그룹의 이름(이 예제에서는 fsvg1)을 입력하십시오. 논리적 볼륨 화면

Number of LOGICAL PARTITIONS 64