VOS 스트림 파일의 크기는 약 2GB로 제한됩니다. 이는 s$seq_position, s$get_port_status, s$lock_region 등과 같은 인터페이스의 정의에서 파일 내 위치를 나타내기 위해 부호 있는 32비트 변수를 사용하며, 2**31이 표현 가능한 최대 값이기 때문입니다. 스트림 파일에서 위치는 다른 VOS 파일 구조에서와 같이 레코드 번호가 아니라 바이트 오프셋으로 표시됩니다.
릴리스 17.2부터 64비트 스트림 파일을 사용할 수 있으며, 이 파일의 크기는 VOS 파일 시스템의 제한(파일당 최대 512GB)에 의해서만 제한됩니다. 이러한 파일은 확장성을 높일 뿐만 아니라, 특히 바이너리 데이터에 접근할 때 다른 이점도 제공합니다. 일반 스트림 파일과 달리, 모든 바이트가 0으로 구성된 블록은 디스크 공간을 차지하지 않으며, 이러한 데이터를 읽을 때 디스크 액세스가 필요하지 않습니다.
POSIX 호환 애플리케이션은 소스 코드를 수정하지 않고도 대용량 파일을 처리할 수 있도록 쉽게 빌드할 수 있습니다. 17.2 이상 모듈에서 실행되는 디스크에 생성된 새 파일은 64비트(일반적으로 stream64라고 함) 파일이 되며, 17.2 미만 모듈에서는 일반 스트림 파일이 됩니다. VOS s$ 인터페이스나 VOS Language I/O를 사용하는 애플리케이션은 네이티브 애플리케이션이라고 하며, 스트림 파일을 사용하는 애플리케이션은 바이트 위치 지정 연산을 사용하지 않는 경우(BOF 또는 EOF로의 위치 지정은 바이트 위치 지정으로 간주되지 않음) 또는 파일이 stream64인 경우 stream64 파일에 액세스할 수 있습니다. 그러나 stream64 파일을 생성하려면 해당 애플리케이션을 수정해야 합니다.
64비트 스트림 파일을 사용할 계획이 있다면 도움이 될 만한 정보를 다음과 같이 정리했습니다. 내용은 다음과 같습니다:
기존 애플리케이션 및 호환성
– 기존 POSIX 애플리케이션
– 기존 네이티브 애플리케이션
– 호환성
– 오픈 소스 제품
스파스 할당
파일 변환
물리적 특성
– 익스텐트
– 익스텐트가 스파스 할당에 미치는 영향
– 유연한 익스텐트
도구
– 모듈에서 64비트 스트림 파일 찾기
– 블록 비교
– 스파스 파일 비교
기존 애플리케이션 및 호환성
– 기존 POSIX 애플리케이션
릴리스 17.2부터는 Posix 애플리케이션을 대용량 파일 지원 기능으로 빌드할 수 있으며, 이를 통해 대상 시스템이 17.2 이상 버전이 실행 중인 디스크에 있는 경우 64비트 파일에 액세스하고 생성할 수 있습니다. 애플리케이션이 POSIX를 준수하는 경우(예: 필요한 곳에 int 대신 off_t와 같은 유형을 사용하도록 코딩된 경우), 소스 코드를 변경할 필요가 없습니다. OpenVOS POSIX.1 참조 매뉴얼 R502의 “기존 애플리케이션을 64비트 스트림 파일 환경으로 이식하기”에 설명된 대로 빌드하기만 하면 됩니다. 생성되는 파일이 17.2 이전 버전을 실행하는 모듈의 디스크에 있는 경우, 일반 스트림 파일이 생성되며, 파일을 2GB 이상으로 확장하려고 시도할 때만 오류가 발생하므로 문제없이 작동합니다. 따라서 POSIX 애플리케이션이 대용량 파일을 사용할 수 있도록 하는 데 상호 운용성 측면에서 추가 비용이 들지 않습니다. 릴리스 17.2부터는 대부분의 VOS 지원 오픈 소스 제품이 64비트 스트림 파일을 생성하고 올바르게 처리합니다.
POSIX 호환 애플리케이션은 소스 코드를 수정하지 않고도 대용량 파일을 처리할 수 있도록 쉽게 빌드할 수 있습니다. 17.2 이상 모듈에서 실행되는 디스크에 생성된 새 파일은 64비트 스트림(일반적으로 stream64라고 함) 파일이 되며, 17.2 미만 모듈에서는 일반 스트림 파일이 됩니다. VOS s$ 인터페이스나 VOS Language I/O를 사용하는 애플리케이션은 네이티브 애플리케이션이라고 하며, 스트림 파일을 사용하는 애플리케이션은 바이트 단위 위치 지정 연산을 사용하지 않는 경우(BOF 또는 EOF로의 위치 지정은 바이트 단위 위치 지정에 해당하지 않음)이거나 파일 크기가 2GB 미만인 경우에만 stream64 파일에 액세스할 수 있습니다.
– 기존 네이티브 애플리케이션
많은 네이티브 애플리케이션은 단순히 create_file 명령어(또는 s$create_file)의 사용 방식을 STREAM 대신 STREAM64로 지정하도록 변경하기만 하면 됩니다. 애플리케이션이 위치 지정 연산을 사용하고 파일 크기가 2GB를 초과할 경우, s$seq_position 호출 시 오류가 발생합니다. 더 큰 파일을 지원하려면 s$seq_position 호출을 s$seq_position_x로 변경해야 합니다. 다시 말해, _x 인터페이스를 사용하더라도 위치 지정 인수가 지원되는 범위 내에 있는 한, _x 인터페이스를 지원하지 않는 모듈에 존재하는 일반 스트림 파일을 참조하는 애플리케이션의 기능에는 아무런 지장이 없습니다. 따라서 이러한 변경을 통해 모든 유형의 스트림 파일에 접근할 수 있으며 상호 운용성 측면에서도 아무런 손실이 없습니다.
바이트 위치(s$seq_read, s$seq_write, s$seq_position)를 전달하지 않는 인터페이스만 사용하는 기존 애플리케이션은 별도의 수정 없이도 stream64 파일을 처리할 수 있습니다. 많은 애플리케이션은 순차적 파일이든 스트림 파일이든 ASCII 파일을 처리하도록 작성되었기 때문에, 파일 크기와 관계없이 64비트 스트림 파일을 처리하는 데 별도의 변경이 필요하지 않습니다.
64비트 스트림 파일에는 인덱스를 포함할 수 없으므로, 인덱스가 포함된 스트림 파일은 stream64로 변환할 수 없습니다. 또한 기존 인덱스 구현의 제한 사항으로 인해 인덱스가 포함된 스트림 파일의 크기는 2GB를 초과할 수 없습니다.
– 호환성
64비트 스트림 파일은 여러 가지 장점을 제공하므로, 인덱스가 필요하지 않은 경우 가능한 한 이를 사용해야 합니다.
파일 크기가 2GB를 초과하지 않는 한, 해당 파일을 구버전 VOS가 실행 중인 모듈로 복사하거나 이동할 수 있으며, 그곳에서는 일반 스트림 파일로 표시됩니다. 파일이 “제한된” 상태가 아닌 경우, stream64 파일이 포함된 디스크를 구버전 VOS로 이동하는 것도 가능합니다. 파일이 2GB를 초과하거나 스파스(sparse) 방식으로 할당된 경우 해당 파일은 제한된 파일이 됩니다. 이러한 파일은 포함된 디스크가 17.2 이전 버전의 VOS로 이동될 경우 열 수 없습니다(이러한 이동을 계획 중이라면 제한된 파일을 식별할 수 있는 도구를 사용할 수 있습니다). 그러나 구버전 VOS에서 실행되는 애플리케이션은 네트워크를 통해 모든 종류의 stream64 파일을 열고, 읽고, 쓸 수 있습니다. 발생할 수 있는 오류는 해당 애플리케이션이 17.2 이상 버전에서 실행될 때와 동일합니다(예: 파일 크기가 2GB를 초과할 때 바이트 위치 지정을 위해 s$seq_position을 사용하는 경우).
– 오픈 소스 제품
VOS에서 지원되는 대부분의 오픈 소스 소프트웨어는 대용량 파일을 처리할 수 있도록 변환되었습니다(예: ftp, sftp, samba 등). 이는 몇 가지 의미를 내포합니다. 릴리스 17.2부터는 스트림 파일을 VOS로 FTP 전송할 때 파일 크기가 너무 크다는 점을 걱정할 필요가 없습니다. FTP 데몬이 스트림64 파일을 생성하기 때문입니다. FTP는 모든 바이트를 기록하므로, 전송된 파일이 대부분 이진 0으로 구성되어 있더라도 결과 파일은 스파스 파일이 되지 않습니다(다음 섹션 참조). 전송된 파일을 단순히 복사하는 것만으로도 해당 파일이 차지하는 디스크 공간을 크게 줄일 수 있습니다. FTP로 전송된 파일에 인덱스를 추가할 계획이라면, 먼저 해당 파일을 일반 스트림 파일로 변환해야 합니다(물론 파일 길이는 2GB를 초과해서는 안 됩니다).
스파스 할당
스트림64 파일의 경우, 모든 바이트가 0으로 구성된 블록이 항상 할당되는 것은 아니므로 디스크 공간을 차지하지 않습니다. gnu “truncate” 명령어(>system>gnu_library>bin 경로)를 사용하면 스트림 파일의 크기를 줄이거나 늘릴 수 있습니다. 18.0 버전에서 VOS는 reset_eof라는 유사한 명령어를 제공합니다. EOF 이후의 데이터는 정의되지 않지만, EOF가 확장될 경우 현재 EOF 지점부터의 파일 내용은 항상 이진 0으로 설정됩니다.
일반 스트림 파일과 stream64 파일을 생각해 봅시다:
create_file stm -organization stream
create_file s64 -organization stream64
각 파일의 내용이 ‘abc’라고 가정합시다. 각 파일이 20억 바이트를 차지하도록 파일 크기를 늘리고자 합니다:
bash
bash-4.2$ truncate -s 2000000000 s64
bash-4.2$ truncate -s 2000000000 stm
첫 번째 요청은 즉시 완료되는 반면, 두 번째 요청은 몇 분이 걸립니다. 파일들은 논리적으로 동일합니다:
bash-4.2$ ls -l
총 244382개
-rwxrwxrwx 1 nobody nobody 2000000000 2월 25일 14:08 s64
-rwxrwxrwx 1 nobody nobody 2000000000 2월 25일 14:11 stm
그러나 VOS list 명령어에서 볼 수 있듯이, 각 파일이 차지하는 디스크 블록 수는 상당히 다릅니다:
목록
파일 수: 2, 블록 수: 488764
w 4 s64
w 488760 stm
릴리스 18.0에서는 VOS의 reset_eof 명령을 사용하여 이와 동일한 작업을 수행할 수 있습니다:
reset_eof s64 2000000000
일반 스트림 파일을 수천 블록 이상 확장하려고 하면 VOS 명령어가 경고를 표시합니다. 이는 매우 많은 자원을 소모하는 작업이기 때문입니다.
reset_eof stm 2000000000
eof를 2000000000으로 확장하면 파일에 488281개의 블록이 추가됩니다. stm을 1999999996바이트 확장하시겠습니까? (예, 아니오)
다음은 확장된 64비트 스트림 파일입니다. 이 파일은 단 두 개의 데이터 블록으로 구성되어 있습니다:
dump_file s64
블록 번호 1
000 6162630A 00000000 00000000 00000000 |abc………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
블록 번호 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
일반 스트림 파일 stm의 내용을 출력하면 할당된 총 488,282개의 블록이 모두 표시되며, 대부분의 블록은 이진 0으로 채워져 있습니다.
dump_file stm
블록 번호 1
000 6162630A 00000000 00000000 00000000 |abc………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
블록 번호 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
3번 블록
…
블록 번호 488282
000 00000000 00000000 00000000 00000000 |…………….|
=
400 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |…………….|
=
FF0 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF |…………….|
그럼에도 불구하고, compare_files와 diff는 두 파일을 동일하게 인식하지만, 일반 스트림 파일의 모든 블록을 일일이 읽어 들여야 하므로 이 경우 몇 분이 소요될 수 있습니다:
준비됨;compare_files s64 stm
준비됨 14:29:47
준비됨 14:31:24 45.877 46
파일 변환
convert_stream_file 명령어는 순차 파일 및 스트림 파일 유형(스트림, 64비트 스트림, 순차, 확장 순차) 간 변환과 익스텐트 변경에 사용할 수 있습니다. 일반적으로 변환 과정은 파일 내용을 복사하는 것을 포함하며, 이는 빈 대상 파일을 생성한 후 -truncate 옵션을 사용하여 copy_file을 호출하는 방식과 유사합니다. convert_stream_file은 파일을 원본 위치에서 직접 변경하는 데 사용할 수 있으며, 변환을 시도하기 전에 기존 내용이 요청된 새 형식으로 표현될 수 있는지 확인한다는 장점이 있습니다.
There are cases where a stream file can be reset to stream64 and vice versa without conversion, i.e., without copying contents. This is done by resetting the directory entry and is possible only if the file is not sparse, is less that 2 GB and extent size is not changed. This can be useful when migrating a disk containing stream64 files to a pre-17.2 module and again if the disk is moved back. The set_stream_files command is available for this purpose. It is a privileged command intended for use by a System Administrator: it takes a directory as input and resets files in that directory, and optionally in all sub-directories. It affects only those stream64 files which can be reset without conversion (not sparse and otto>stm
file organization: stream file
last used at: 15-02-25 14:34:45 est
…
extent size: 1
next byte: 2000000000
blocks used: 488760 <<<<<
다음:
convert_stream_file stm -to stream64 -extent_size 8
display_file_status stm
file organization: stream file (64-bit/rstr)
last used at: 15-02-25 14:39:16 est
…
extent size: 8
next byte: 2000000000
blocks used: 18 <<<<
sparse: yes
생성된 파일은 스파스(sparse) 파일이 되었기 때문에 제한됨(64-bit/rstr)으로 표시됩니다. copy_file 명령어도 스파스 파일을 생성합니다. stream64 파일을 일반 stream 파일로 변환하면 모든 블록이 구체화되므로, 결과 파일의 크기가 원본보다 상당히 커질 수 있습니다.
stream64 파일에서는 이진 0으로만 구성된 블록이 디스크에 할당될지 여부가 보장되지 않습니다. 예를 들어, 블록에 0을 몇 개 쓰면 그 블록이 결국 모두 0으로 채워지게 되는데, 이 경우 블록은 계속 할당된 상태로 유지됩니다. 또한 프로그램이 명시적으로 0 데이터를 써서 블록을 채우는 경우에도 마찬가지입니다. 단, 한 번도 데이터가 기록되지 않은 블록만이 할당되지 않은 상태로 남습니다. copy_file 및 convert_stream_file 함수는 이진 0으로만 구성된 블록을 절대 기록하지 않습니다.
물리적 특성
– 범위
모든 VOS 파일의 실제 성장 한계는 익스텐트 크기에 의해 결정되므로, 익스텐트가 무엇인지 이해하는 것이 중요합니다. VOS 파일 맵에는 파일 내 각 4k 블록에 대한 디스크 주소가 포함되어 있으며, 이는 523792개 항목으로 제한됩니다. 따라서 익스텐트가 없는 파일의 크기는 2145452032(523792 × 4096)바이트로 제한됩니다. 이는 2**31보다 약간 작은 값이므로, 일반 스트림 파일의 실제 크기 증가 한계입니다.
익스텐트(extent)는 디스크 상의 N개 연속된 블록으로 구성된 그룹이며, 여기서 N은 익스텐트 크기입니다. 익스텐트를 통해 할당된 파일의 파일 맵에는 익스텐트 내 첫 번째 블록의 주소가 포함되어 있으므로, 파일 맵을 통해 훨씬 더 큰 파일을 표현할 수 있습니다. 동적으로 할당된 익스텐트는 최대 256까지의 익스텐트 크기를 허용하므로 512GB 용량의 파일을 저장할 수 있습니다(참고: 익스텐트 크기를 256보다 크게 허용하는 정적으로 할당된 익스텐트는 페이징 파일과 함께 사용하는 경우를 제외하고는 더 이상 권장되지 않습니다. 이러한 방식은 많은 제한 사항과 성능 문제를 가지고 있어 일반적인 용도로는 적합하지 않습니다).
stream64 파일이 2GB를 초과하여 확장되려면 익스텐트(extent)가 있어야 하며, 이 익스텐트의 값이 실제 확장 한계를 결정합니다. 예를 들어,
create_file stm64 -organization steam64 -extent_size 32
최대 64GB까지 용량이 늘어날 수 있는 파일을 생성합니다.
릴리스 17.2에서 Posix 런타임으로 생성된 파일의 기본 익스텐트 크기는 8이며, 최대 16GB까지 확장될 수 있습니다. 이러한 파일은 한 번에 8블록씩 증가하므로, 모든 파일의 최소 크기는 8블록입니다. 시스템 관리자는 모듈별로 이 기본값을 변경할 수 있지만, 확장 가능한 최대 용량이 클수록 파일의 최소 크기도 커집니다. 매우 작은 파일을 다수 생성하는 애플리케이션의 경우, 확장 영역이 너무 크면 문제가 될 수 있습니다.
– 익스텐트가 스파스 할당에 미치는 영향
일반적으로 스트림64 파일의 경우, 한 번도 쓰기 작업이 수행되지 않은 블록은 할당되지 않습니다. 하지만 익스텐트 내의 블록 하나라도 쓰기 작업이 수행되면, 일부 블록에 이진 0만 들어 있더라도 해당 익스텐트의 모든 블록이 할당됩니다.
문자열 "abc"를 포함하는 비익스텐트 파일(stm1)이 익스텐트 크기가 8인 파일(stm8)로 변환된다고 가정해 봅시다:
dump_file stm1
블록 번호 1
000 6162630A 00000000 00000000 00000000 |abc………….|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
convert_stream_file stm1 stm8 -extent_size 8
dump_file stm8
블록 번호 1
000 6162630A 00000000 00000000 00000000 |abc………….|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
블록 번호 2
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
3번 블록
…
블록 번호 8
000 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
릴리스 18.0에서 dump_file에 -brief 옵션이 추가되었으며, 물리적으로는 존재하지만 “비어 있는”(실제로는 존재하지 않을 수도 있는) 블록을 표시하지 않으려는 경우에 유용합니다. DAE-8 파일에서 이 옵션을 사용하는 방법은 다음과 같습니다:
dump_file stm8 -brief
블록 번호 1
000 6162630A 00000000 00000000 00000000 |abc………….|
010 00000000 00000000 00000000 00000000 |…………….|
=
FF0 00000000 00000000 00000000 00000000 |…………….|
이는 고정 파일의 상대 경로에 있는 모든 값이 -1인 “빈” 블록을 숨기는 데에도 효과적입니다.
– 유연한 익스텐트
릴리스 18.0에서는 유연한 익스텐트가 도입되어 작은 파일을 한 번에 한 블록씩 확장할 수 있게 되었으며, 파일이 커짐에 따라 익스텐트 값이 변경됩니다. 이는 릴리스 18.0에서 POSIX 애플리케이션으로 생성되는 모든 파일의 기본 설정이며, create_file 명령을 사용할 때 특정 익스텐트 크기를 지정하지 않으면 이 설정이 적용됩니다:
create_file flex -organization stream64 -extent_size
유연한 익스텐트를 가진 파일을 ‘flex 파일’이라고 하며, stream64 파일만 유연한 익스텐트를 가질 수 있습니다. display_file_status 명령어는 flex 파일의 익스텐트 크기를 “flex”로 표시합니다.
display_file_status flex
이름: %swsle#Raid4>flex
파일 구성: 스트림 파일 (64비트)
마지막 수정 일시: 2015년 2월 25일 12:06:25 EST
…
동적 익스텐트: 예
익스텐트 크기: flex
18.0 이전 버전의 모듈에서 display_file_status 명령을 실행하면 다음과 같은 메시지가 표시됩니다:
extent size: -1
flex 파일을 17.2 모듈의 디스크에 복사하면, 해당 모듈의 기본 설정에 따른 익스텐트가 생성됩니다. 17.1 또는 그 이전 버전의 모듈에 복사할 경우, 일반 스트림 파일로 생성됩니다.
릴리스 17.2 이상에서는 compare_files가 스트림 파일 간의 익스텐트 크기 차이를 인식하지 못하며, 익스텐트와 관계없이 파일들이 동일하게 표시됩니다. 예를 들어, %swsle#m109_mas가 17.2를 실행 중인 모듈에 있다고 가정해 보겠습니다:
copy_file flex %swsle#m109_mas>Stratus
compare_files flex %swsle#m109_mas>Stratus>flex
완료 14:42:38 0.001 6
17.2 이전 버전의 모듈에서 compare_files를 실행하면 다음과 같은 차이가 표시됩니다:
compare_files %swsle#Raid>flex %swsle#m109_mas>Stratus>flex
A (%swsle#Raid4>flex)와 B (%swsle#m109_mas>Stratus>flex)가 일치하지 않습니다.
– 두 파일의 일부 속성이 일치하지 않습니다:
익스텐트 크기 -1 8
Flex 파일은 512GB보다 약간 적은 용량을 저장할 수 있습니다. 구체적으로 540,142,534,656바이트를 저장할 수 있는데, 이는 DAE-256의 549,235,720,192바이트보다 적은 수치입니다. 하지만 Flex 파일은 작은 파일이 한 번에 256블록씩만 늘어나는 방식과 달리, 처음에는 한 블록씩, 그다음 8블록, 32블록, 256블록 순으로 용량이 증가한다는 장점이 있습니다.
flex 파일이 포함된 디스크를 18.0 이전 버전의 모듈에 마운트해서는 안 됩니다. 디스크에 flex 파일이 있는지 쉽게 확인할 수 있는 도구가 있습니다. 실수로 마운트할 경우, 해당 파일들은 표시되지 않으며 접근할 수 없게 됩니다. 이러한 파일이나 이를 포함하는 디렉터리는 삭제할 수 없으므로, 디스크를 18.0 이상이 실행 중인 모듈로 다시 이동하더라도 그대로 유지됩니다. 그러나 18.0 이전 버전의 모듈에서 복구 작업을 수행하면 모든 flex 파일이 제거되고 해당 공간이 회수됩니다.
도구
– 모듈에서 64비트 스트림 파일 찾기
디스크를 이전 버전의 VOS로 마이그레이션해야 할 경우, 이전 릴리스와 호환되지 않는 파일을 찾아야 합니다. 이를 돕는 명령어가 제공됩니다:
locate_stream_files -form
—————————– locate_stream_files ————————-
directory_names:
-depth:
-type: 64-bit
-brief: no
-long: no
-type 옵션은 flex, sparse 또는 large(해당 특성을 가진 64비트 스트림 파일을 검색함)로 지정할 수도 있고, all(모든 스트림 파일을 검색함)로 지정할 수도 있습니다.
-depth 옵션에 따라 하위 디렉터리가 검색되며, 파일에 (type 옵션으로 지정되지 않은) 속성이 하나라도 있는 경우 해당 속성과 익스텐트 크기에 대한 정보도 함께 표시됩니다. 디렉터리 이름을 지정하지 않으면 모듈에 있는 모든 디스크가 루트 디렉터리부터 검색됩니다. 예를 들어:
locate_stream_files - 64비트
디스크의 디렉터리 확인 중 %swsle#raid0-1…
%swsle#raid0-1:
smb_test.stm64 (FLEX/large)
smb_test.stmb
총 2개의 64비트 스트림 파일.
디스크의 디렉터리 확인 중 %swsle#raid0-2…
%swsle#raid0-2:
big_stream (FLEX)
smb_test.stm (FLEX)
smb_test.stm64a (FLEX/large)
총 3개의 64비트 스트림 파일.
디스크의 디렉터리 확인 중 %swsle#Raid4…
%swsle#Raid4>otto:
b3 (DAE-8)
big (DAE-256/large/sparse)
…
– 블록 비교
릴리스 17.2 및 18.0에서는 스트림 파일에 유용한 compare_files 명령을 위한 새로운 옵션이 제공됩니다. VOS 구조화 파일 유형의 경우 블록 단위 비교는 일반적으로 유용하지 않습니다. 왜냐하면 값이 다른 두 블록이 종종 동일한 논리적 레코드를 나타내기 때문입니다. 예를 들어, 상대 파일의 레코드에서 현재 길이를 초과하는 미사용 데이터는 예측할 수 없습니다. 또한, 순차 파일에는 정의되지 않은 채움 바이트가 포함되어 있습니다. 확장 순차 파일의 경우, 레코드 크기가 다르면 동일한 논리적 레코드를 나타내더라도 블록 내용은 완전히 달라집니다.
그러나 블록 비교는 고정 파일이나 스트림 파일의 경우에도 때때로 유용할 수 있습니다. 문제는 compare_files가 레코드 단위로 작동하며, 편집기를 통해 찾을 수 있는 레코드 번호(또는 줄 번호)를 기준으로 차이점을 표시하도록 설계되었다는 점입니다. 이는 레코드 단위로 구성되지 않은 이진 스트림 파일의 경우 문제를 야기해 왔습니다. 모든 파일의 레코드 크기는 32767바이트로 제한되어 있으므로, 스트림 파일에서 32k바이트 이상의 시퀀스가 중간에 NL 레코드 구분자 없이 나타날 경우 s$seq_read를 사용하면 다음 32767자리를 반환하게 되며, 다음 바이트가 NL인지 아닌지를 구분하지 못합니다. 이로 인해 NL 문자로 구분된 문자열이 아닌 이진 값을 포함하는 스트림 파일의 경우, 레코드 기반 비교 결과가 모호해집니다.
이 문제는 릴리스 17.2에서 해결되었습니다. compare_files는 이전에 잘못된 성공 결과가 발생했을 수 있는 경우, 특히 32767자 뒤에 줄바꿈(NL)이 오는 경우와 32767자 뒤에 줄바꿈(NL)이 오지 않는 경우를 감지합니다. 이러한 상황이 발생하면 스트림 파일에 32767자를 초과하는 레코드가 포함되어 있음을 나타내는 오류가 보고됩니다. 이러한 상황이 전혀 발생하지 않는다면, 레코드 기반 결과는 유효하며 신뢰할 수 있습니다. 하지만 어쨌든 파일의 동일성만 확인하려는 경우, 비정형 파일의 블록을 비교하는 것이 레코드 기반 방식보다 훨씬 빠릅니다. 블록 비교의 문제점은 레코드가 기준점이 되어주지 않기 때문에, 첫 번째 불일치 이후의 비교는 종종 의미가 없어진다는 점입니다.
릴리스 17.2에서는 이러한 목적을 위해 compare_files 명령어에 -compare_blocks 옵션이 추가되었습니다. 이 옵션을 사용하면 비정형 파일이 블록 단위로 동일한지 여부를 신속하게 감지하고, 차이가 발생하는 블록을 식별할 수 있습니다. 드물게 차이가 오버레이(삽입이나 삭제가 아닌 특정 바이트의 수정)로 인해 발생하고 나머지 파일은 동일한 경우를 대비하여 -continue 옵션도 사용할 수 있습니다. 이를 통해 파일의 나머지 부분에서 차이가 나는 블록의 범위를 확인할 수 있습니다. 예를 들어, 오버레이가 아닌 바이트 삽입이 발생한 경우, 나머지 모든 블록이 서로 다르게 나타납니다. 즉, 레코드 비교에서 수행되는 것과 같은 재동기화(resync)는 블록 비교에서는 불가능합니다. 하지만 앞서 언급한 경우와 같이, 이 추가 정보를 통해 차이점이 단지 몇 개의 블록에 있는 오버레이된 바이트뿐이며, 이는 타임스탬프와 같은 것을 나타낼 수 있음을 확인할 수 있습니다.
-compare_blocks와 -continue의 사용 예시:
compare_files flex dae256 -compare_blocks -continue
A (%swsle#m111_mas>Stratus>Newman>flex)는 B (%swsle#m111_mas>Stratus>Newman>dae256)와 일치하지 않습니다.
– 2번부터 24번까지의 데이터 블록이 다릅니다.
– 33번부터 488번까지의 데이터 블록이 다릅니다.
– 파일 B에는 272개의 추가 블록이 있습니다.
– 스파스 파일 비교
`compare_files` 명령어는 파일 내에 물리적으로 존재하는 모든 블록을 검사합니다. 이는 스파스 파일의 경우 문제가 될 수 있는데, 바이너리 0으로 구성된 블록이 한 파일에서는 할당된 블록으로 나타날 수 있지만 다른 파일에는 존재하지 않을 수 있기 때문입니다. 두 파일은 논리적으로는 동일할 수 있지만, 블록 단위로 보면 동일하지 않을 수 있습니다. 실제로 `copy_file`을 사용하면 대상 파일에서 바이너리 0으로 구성된 블록이 제거되며, 이러한 블록이 존재할 경우 소스 파일과 대상 파일이 블록 단위로 동일하지 않음을 보장합니다.
이는 익스텐트 기반 스트림 파일에서도 발생하는 문제입니다. 익스텐트 내의 모든 블록은 비록 내용이 모두 0으로 채워져 있더라도 항상 인스턴스화되기 때문입니다. 즉, 스파스 익스텐트 파일의 블록은 동일한 데이터를 나타내더라도, 동일한 구조의 비익스텐트 파일 내 블록과는 다르게 보일 수 있습니다. copy_file 명령어를 실행한다고 해서 익스텐트 내의 0으로 채워진 블록을 제거할 수는 없습니다.
위에서 -continue 옵션의 사용법을 보여주는 예시는 실제로 두 개의 동일한 파일을 다루고 있는데, 한 파일은 DAE-256 익스텐트를 사용하고 다른 파일은 플렉서블 익스텐트를 사용한다는 점만 다릅니다.
따라서 내용이 “abc”인 DAE-8 파일은 “abc”가 포함된 블록 하나와 그 뒤에 이진 0으로 채워진 7개의 블록으로 구성됩니다. 비익스텐트 파일(또는 플렉스 파일)은 “abc”가 포함된 블록 하나만 포함하며, DAE-16 파일은 “abc” 블록 하나와 그 뒤에 이진 0으로 채워진 15개의 블록으로 구성됩니다.
compare_files 명령에 -compare_blocks 옵션을 사용하면, 모든 파일이 동일한 파일 데이터를 나타내더라도 이 파일들이 서로 다른 것으로 표시됩니다. 릴리스 18.0에서는 이러한 상황에 대비해 -compare_all_blocks 옵션을 사용할 수 있습니다. 이 옵션을 사용하면 copy_file이 비교 대상 파일에서 누락된 블록을 논리적으로 생성하므로, 스파스성으로 인한 차이를 제거한 진정한 블록 단위 비교가 이루어집니다. stream64 파일에서 누락된 블록은 모두 이진 0으로 간주되는 반면, fixed(또는 기타 모든 파일 유형)에서는 이진 -1(모두 FFFF)로 간주됩니다.
파일 내 빈 공간이 매우 많은 경우, 이 방법은 -compare_blocks 옵션을 사용할 때보다 비교 속도가 훨씬 느려질 수 있지만, 기본 기록 단위 비교 방식보다는 여전히 훨씬 빠릅니다. 일반적으로는 익스텐트가 서로 다른 파일의 블록을 비교할 때만 필요하지만, 앞서 언급한 바와 같이 스파스성이 다를 수 있는 다른 경우도 있습니다. 또한 익스텐트가 서로 다른 고정 파일의 경우에도 유용합니다.