VOS 스트림 파일은 약 2GB로 성장한 것으로 제한됩니다. 이는 s$seq_position, s$get_port_status, s$lock_region 등의 인터페이스의 정의가 서명된 32비트 변수를 사용하여 파일의 위치를 나타내고 2**31을 나타낼 수 있는 가장 큰 값이기 때문입니다. 스트림 파일에서 위치는 다른 VOS 파일 조직에서와 같이 레코드 번호가 아닌 바이트 오프셋입니다.
64비트 스트림 파일은 릴리스 17.2로 제공되며 VOS 파일 시스템에서만 증가를 허용합니다(모든 파일의 최대 크기는 512GB). 성장 잠재력을 확장하는 것 외에도 이러한 파일은 특히 이진 데이터에 액세스할 때 다른 이점을 제공합니다. 일반 스트림 파일과 달리 모든 이진 제로를 포함하는 블록은 디스크의 공간을 차지하지 않으며 이러한 데이터를 읽으려면 디스크 액세스가 필요하지 않습니다.
Posix 호환 응용 프로그램은 소스 변경 없이 대규모 파일 인식을 위해 쉽게 구축 될 수 있습니다: 17.2+ 모듈에서 실행 되는 디스크에 생성 된 새로운 파일 64 비트 (종종 stream64라고도 함) 파일 및 사전 17.2 모듈에 일반 스트림 파일 될 것입니다. VOS s$ 인터페이스 또는 VOS 언어 I /O를 사용하는 응용 프로그램은 네이티브 응용 프로그램이라고하며 스트림 파일을 사용하는 응용 프로그램은 바이트 위치 지정 작업을 사용하지 않는 한 stream64 파일에 액세스 할 수 있습니다 (BOF 또는 EOF에 위치 지정하는 것은 바이트 위치 지정으로 간주되지 않습니다) 또는 파일이 스트림64 파일을 생성하기 위해 수정해야합니다.
다음은 64비트 스트림 파일을 사용하려는 경우/경우에 유용할 수 있는 몇 가지 정보입니다. 다음과 같이 구성됩니다.
기존 응용 프로그램 및 호환성
– 기존 Posix 응용 프로그램
– 기존 네이티브 응용 프로그램
– 호환성
– 오픈 소스 제품
스파스 할당
파일 변환
물리적 특성
– 익스텐트
– 범위가 스파스 할당에 미치는 영향
– 유연한 범위
도구
– 모듈에서 64비트 스트림 파일 찾기
– 블록 비교
– 스파스 파일 비교
기존 응용 프로그램 및 호환성
– 기존 Posix 응용 프로그램
릴리스 17.2를 기준으로 Posix 응용 프로그램을 빌드하여 대규모 파일 인식을 위해 빌드할 수 있으므로 대상이 17.2 이상에서 실행되는 디스크에 있는 경우 64비트 파일에 액세스하고 만들 수 있습니다. 응용 프로그램이 Posix를 준수하는 경우(예: 필요한 경우 int 대신 off_t 같은 형식을 사용하도록 코딩됨) 소스 변경이 필요하지 않습니다. OpenVOS POSIX.1 참조 매뉴얼R502에서 설명한 대로 빌드하기만 하면 "기존 응용 프로그램을 64비트 스트림 파일 환경으로 이식"합니다. 생성되는 파일이 17.2 이전을 실행하는 모듈의 디스크에 있는 경우 일반 스트림 파일이 만들어지며 파일을 늘리려는 경우에만 모든 문제가 발생합니다 . 따라서 Posix 응용 프로그램에서 대용량 파일을 사용하도록 설정하는 데는 상호 운용성 측면에서 비용이 들지 않습니다. 대부분의 VOS 지원 오픈 소스 제품은 릴리스 17.2로 64 비트 스트림 파일을 생산하고 적절하게 처리합니다.
Posix 호환 응용 프로그램은 소스 변경 없이 대규모 파일 인식을 위해 쉽게 구축 될 수 있습니다: 17.2+ 모듈에서 실행 되는 디스크에 생성 된 새로운 파일 64 비트 스트림 (종종 stream64라고도 함) 파일 및 사전 17.2 모듈에 일반 스트림 파일 될 것입니다. VOS s$ 인터페이스 또는 VOS 언어 I/O를 사용하는 응용 프로그램은 네이티브 응용 프로그램이라고 하며 스트림 파일을 사용하는 응용 프로그램은 바이트 위치 지정 작업을 사용하지 않는 한 stream64 파일에 액세스할 수 있습니다(BOF 또는 EOF에 위치 지정하는 것은 바이트 위치 지정으로 간주되지 않음) 또는 파일이 2GB보다 작은 경우.
– 기존 네이티브 응용 프로그램
많은 네이티브 응용 프로그램은 조직이 STREAM이 아닌 STREAM64임을 나타내기 위해 create_file 명령(또는 create_file)의 사용을 변경하기만 하면 됩니다. 응용 프로그램이 위치 지정 작업을 사용하고 파일이 2GB로 커지면 s$seq_position 더 큰 파일을 지원하려면 s$seq_position 호출을 s$seq_position_x 변경해야 하는 오류가 발생합니다. 다시 말하지만, _x 인터페이스를 사용하면 위치 인수가 지원되는 범위에 있는 한 _x 인터페이스를 지원하지 않을 수 있는 모듈에 존재하는 일반 스트림 파일을 참조하는 응용 프로그램의 기능을 방해하지 않습니다. 따라서 변경을 사용하면 모든 유형의 스트림 파일에 액세스할 수 있으며 상호 운용성에서 비용이 전혀 들지 않습니다.
바이트 위치를 통신하지 않는 인터페이스만 사용하는 기존 응용 프로그램: s$seq_read, s$seq_write, s$seq_position BOF/EOF는 수정 없이 stream64 파일을 처리할 수 있습니다. 많은 응용 프로그램은 ASCII 파일을 처리하기 위해 작성되어 순차적이든 스트림이든 크기에 관계없이 64비트 스트림 파일을 처리하기 위해 변경할 필요가 없습니다.
64비트 스트림 파일에인덱스가 없으므로 인덱싱된 스트림 파일을 stream64로 변환할 수 없습니다. 기존 인덱스 구현의 제한으로 인해 인덱싱된 스트림 파일은 > 2GB로 증가할 수 없습니다.
– 호환성
64비트 스트림 파일은 여러 가지 이점을 제공하기 때문에 인덱스가 필요하지 않은 경우 가능하면 채택해야 합니다.
파일이 증가하지 않는 한 > 2GB를 복사하거나 이전 버전의 VOS를 실행하는 모듈로 이동할 수 있으며 일반 스트림 파일로 표시됩니다. stream64 파일이 포함된 디스크를 이전 VOS로 이동할 수도 있으므로 파일이 "제한"되지 않습니다. 파일이 커지면 제한됩니다 > 2GB 또는 드물게 할당됩니다. 해당 디스크가 포함된 디스크가 17.2 이전 VOS로 이동되는 경우 이러한 파일을 열 수 없습니다(이러한 이동을 계획하는 경우 제한된 파일을 식별할 수 있는 도구를 사용할 수 있음). 그러나 이전 버전의 VOS를 실행하는 응용 프로그램은 네트워크를 통해 모든 종류의 stream64 파일을 열고 읽고 쓸 수 있습니다. 발생하는 모든 오류는 응용 프로그램이 17.2+에서 실행되는 것과 동일합니다(예: 파일이 2GB를 초과할 때 바이트 위치 지정에 대한 seq_position$seq_position 사용).
– 오픈 소스 제품
VOS에서 지원되는 대부분의 개방형 소프트웨어는 ftp, Sftp, 삼바 등과 같은 큰 파일 인식으로 변환되었습니다. 그것은 특정 의미를 갖는다. 릴리스 17.2를 사용하면 이제 스트림 파일을 VOS에 ftp화할 수 있으며 ftp 데몬이 stream64 파일을 생성하기 때문에 파일이 너무 커지는 것에 대해 걱정할 필요가 없습니다. ftp는 모든 바이트를 기록하고 따라서 결과 파일은 희소하지 않습니다 (다음 섹션 참조), 바이너리 제로의 대부분으로 구성된 경우에도. 전송된 파일을 복사하면 차지하는 디스크 공간이 크게 줄어들 수 있습니다. FTp'ed 파일에 인덱스를 추가할 계획이라면 먼저 일반 스트림 파일로 변환해야 합니다(물론 길이가 2GB를 초과해서는 안 됩니다).
스파스 할당
모든 이진 제로를 포함하는 블록은 항상 stream64 파일에 할당되지 않으므로 디스크 공간이 필요하지 않습니다. gnu "트런케이트" 명령(>system>gnu_library>bin)을 사용하여 스트림 파일의 크기를 트런케이트하고 확장할 수 있습니다. 18.0에서 VOS는 reset_eof라는 유사한 명령을 제공합니다. EOF와 함께 하는 데이터는 정의되지 않지만 EOF가 확장되면 현재 EOF 지점의 파일 내용은 항상 이진 제로로 설정됩니다.
일반 스트림 파일과 stream64 파일을 고려하십시오.
create_file stm -조직 스트림
create_file s64 -조직 스트림64
각 콘텐츠가 'abc'라고 가정합니다. 각 사용자가 20억 바이트를 차지하도록 파일을 확장하고자 합니다.
Bash
bash-4.2$ 트런케이트 -s 200000000 s64
bash-4.2$ 트런케이트 -s 200000000 stm
첫 번째 요청은 즉시 완료되며 2번째 요청은 몇 분 정도 걸립니다. 파일에는 논리적 동등성이 표시됩니다.
bash-4.2$ ls -l
총 244382
-rwxrwxrwx 1 아무도 아무도 200000000 2월 25 14:08 s64
-rwxrwxrwx 1 아무도 아무도 200000000 2월 25 14:11 stm
그러나 VOS 목록 명령에서 보여 주듯이 각 파일이 차지하는 디스크 블록 수는 매우 다릅니다.
목록
파일: 2, 블록: 488764
w 4 s64
w 488760 stm
릴리스 18.0에서 해당 작업은 VOS reset_eof 명령을 사용할 수 있습니다.
reset_eof s64 20000000000
VOS 명령은 이러한 비용이 많이 드는 작업이므로 일반 스트림 파일을 몇 천 개 이상의 블록으로 확장하도록 요청하는 경우 경고합니다.
reset_eof stm 20000000000
eof를 2000000000으로 확장하면 파일에 488281 블록이 추가됩니다. 199999996 바이트까지 stm을 확장하시겠습니까? (예, 아니요)
확장된 후 64비트 스트림 파일은 다음과 같습니다. 두 개의 데이터 블록으로 구성됩니다.
dump_file s64
블록 번호 1
000 6162630A 00000000 000000000 00000000000000000000000000000000000000..................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
블록 번호 488282
000 00000000 000000000 0000000000 000000000000000000000000000..............................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
일반 스트림 파일 STM을 덤프하면 이진 영점을 포함하는 대부분의 블록에 할당 된 모든 488282 블록을 표시합니다.
dump_file 스트롬
블록 번호 1
000 6162630A 00000000 000000000 00000000000000000000000000000000000000..................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
블록 번호 2
000 00000000 000000000 0000000000 000000000000000000000000000..............................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
블록 번호 3
...
블록 번호 488282
000 00000000 000000000 0000000000 000000000000000000000000000..............................
=
400 FFFFFF FFFFFF FFFFFF FFFFFF |..................
=
FF0 FFFFFF FFFFFF FFFFFF FFFFFF |...............
그럼에도 불구하고 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
결과 파일은 현재 희소하기 때문에 제한된(64비트/rstr)으로 표시됩니다. copy_file 명령은 희소 파일을 생성합니다. stream64 파일을 일반 스트림 파일로 변환하면 모든 블록이 인스턴스화되고 결과 파일이 원본보다 상당히 커질 수 있습니다.
stream64 파일에서는 이진 영점을 포함하는 블록이 디스크에 할당되거나 그렇지 않을 것이라는 보장은 없습니다. 예를 들어 블록에 일부 0을 작성한 다음 모든 제로가 되는 경우 블록은 할당된 상태로 유지되거나 프로그램이 블록 작성 을 위한 제로 데이터를 명시적으로 작성하는 경우. 기록되지 않은 블록만 할당되지 않은 상태로 유지됩니다. copy_file convert_stream_file 모든 이진 영하를 포함하는 블록을 작성하지 않습니다.
물리적 특성
– 익스텐트
VOS 파일의 실제 성장 제한은 범위 크기에 따라 결정되므로 어느 정도인지 이해하는 것이 중요합니다. VOS 파일 맵에는 파일의 각 4k 블록에 대한 디스크 주소가 포함되어 있습니다. 523792 개의 항목으로 제한되므로 익스텐트가없는 파일은 2145452032 (523792 * 4096) 바이트로 제한됩니다. 이는 2**31 미만이므로 일반 스트림 파일의 성장에 대한 실제 제한입니다.
범위는 N이 범위 크기인 디스크의 N 연속 블록 그룹입니다. 익스플로러 할당된 파일에 대한 파일 맵에는 익스텐타니의 첫 번째 블록 주소가 포함되어 있으므로 파일 맵이 훨씬 더 큰 파일을 나타낼 수 있습니다. 동적으로 할당 된 범위는 최대 256 GB를 포함하는 파일을 허용 (참고 : 256 보다 큰 범위 크기를 허용하는 정적 할당 범위는 페이징 파일과 함께 사용하는 경우를 제외하고 사용되지 않습니다; 이들은 일반적인 사용을 위해 다음 받아 들일 수없는 많은 제한 및 성능 문제가).
2GB를 초과하여 성장하려면 stream64 파일에 익스텐트를 가져야 하며, 그 값은 실제 성장 한도를 결정합니다. 예를 들어
create_file stm64 -조직 증기64 -extent_size 32
64GB로 늘어날 수 있는 파일을 만듭니다.
릴리스 17.2에서 Posix Runtime에서 만든 파일의 기본 범위 크기는 8으로 최대 16GB까지 성장할 수 있습니다. 이러한 파일은 한 번에 8 블록을 성장하므로 파일의 최소 크기는 8 블록입니다. 이 기본값은 모듈별로 시스템 관리자에 의해 변경될 수 있지만 성장 잠재력이 클수록 파일의 최소 크기가 커집니다. 더 큰 범위는 매우 작은 파일을 많이 생성하는 응용 프로그램에 대한 문제가 될 수 있습니다.
– 범위가 스파스 할당에 미치는 영향
일반적으로 기록되지 않은 블록은 stream64 파일에 할당되지 않습니다. 그러나 한 블록이 작성된 경우, 일부 블록에 모든 이진 영점을 포함하더라도 해당 범위의 모든 블록이 할당됩니다.
문자열 abc(stm1)가 포함된 비익 범위 파일이 범위 크기 8(stm8)이 있는 파일로 변환된 경우:
dump_file stm1
블록 번호 1
000 6162630A 00000000 000000000 00000000000000000000000000000000000000..................
010 00000000 000000000 000000000 0000000000000000000000000..........................................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
convert_stream_file stm1 stm8 -extent_size 8
dump_file stm8
블록 번호 1
000 6162630A 00000000 000000000 00000000000000000000000000000000000000..................
010 00000000 000000000 000000000 0000000000000000000000000..........................................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
블록 번호 2
000 00000000 000000000 0000000000 000000000000000000000000000..............................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
블록 번호 3
...
블록 번호 8
000 00000000 000000000 0000000000 000000000000000000000000000..............................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
-brief 옵션은 릴리스 18.0의 dump_file 추가되었으며 물리적으로 존재하는 블록을 보고 싶지만 "비어 있는" 블록(잠재적으로 존재하지 않는) 블록을 나타낼 때 유용할 수 있습니다. DAE-8 파일과 함께 해당 옵션을 사용하는 것은 다음과 같습니다.
dump_file stm8 -brief
블록 번호 1
000 6162630A 00000000 000000000 00000000000000000000000000000000000000..................
010 00000000 000000000 000000000 0000000000000000000000000..........................................
=
FF0 00000000 00000000 00000000 00000000000000000000000000000000000000.............................................
이것은 고정 된 파일의 친척에 대한 모든 -1's를 포함하는 "빈"블록을 숨기는 데효과.
– 유연한 범위
릴리스 18.0에 유연한 범위가 도입되어 작은 파일이 한 번에 한 블록씩 성장할 수 있습니다. 파일이 커지면 범위 값이 변경됩니다. 이것은 릴리스 18.0에서 Posix 응용 프로그램에서 만든 모든 파일에 대 한 기본 값이며 특정 범위 크기를 주지 않는 경우 create_file 명령으로 얻을 거 야.
create_file 플렉스 -조직 스트림64 -extent_size
유연한 범위를 가진 파일을 플렉스 파일이라고 합니다. stream64 파일만 유연한 범위를 가질 수 있습니다. display_file_status 명령은 플렉스 파일의 범위를 "플렉스"로 표시합니다.
플렉스 display_file_status
이름: %swsle#Raid4>플렉스
파일 조직: 스트림 파일(64비트)
최종 수정: 15-02-25 12:06:25 est
...
동적 범위: 예
익스텐트 크기: 플렉스
display_file_status 명령이 18.0 이전 모듈에서 실행되는 경우 다음을 보여 주면 다음과 같은 설명이 표시됩니다.
범위 크기: -1
플렉스 파일이 17.2 모듈의 디스크에 복사되는 경우 해당 모듈의 기본값이 있는 범위가 있습니다. 17.1 또는 이전에 복사한 경우 결과는 일반 스트림 파일입니다.
릴리스 17.2+에서 compare_files 스트림 파일 간의 범위 크기 차이가 표시되지 않으며 파일은 범위에 관계없이 동일하게 표시됩니다. 예를 들어 %swsle#m109_mas 17.2를 실행하는 모듈의 경우라고 가정해 보겠습니다.
copy_file 플렉스 %swsle #m109_mas>스트라투스
compare_files 플렉스 %swsle #m109_mas>Stratus>플렉스
준비 14:42:38 0.001 6
17.2 이전 모듈에서 compare_files 실행하면 다음을 차이점으로 표시합니다.
compare_files %swsle#Raid>플렉스 %swsle #m109_mas>Stratus>플렉스
A(%swsle#Raid4>플렉스는 B(%swsle#m109_mas>Stratus>플렉스)와 일치하지 않습니다.
– 두 파일의 일부 속성은 일치하지 않습니다 :
범위 크기 -1 8
플렉스 파일은 512GB 미만, 특히 540,142,534,656 바이트 대 549,235,720,192 대 DAE-256을 보유 할 수 있지만 작은 파일이 한 번에 한 블록씩 성장한 다음 8, 32, 256 블록과 는 달리 항상 256 블록과 는 반대로 256 블록이 있습니다.
18.0 이전 모듈에 플렉스 파일이 포함된 디스크를 장착해서는 안 됩니다. 플렉스 파일의 존재에 대 한 디스크를 쉽게 검사 할 수 있는 도구가 있다. 실수로 파일을 표시하지 않고 액세스할 수 없습니다. 이러한 파일이나 포함된 디렉터리는 삭제할 수 없으므로 디스크가 18.0+를 실행하는 모듈로 다시 이동하면 그대로 유지됩니다. 그러나 18.0 이전 모듈을 회수하면 모든 플렉스 파일이 제거되고 공간이 복구됩니다.
도구
– 모듈에서 64비트 스트림 파일 찾기
디스크를 이전 버전의 VOS로 이동해야 하는 경우 이전 릴리스와 호환되지 않는 파일을 찾아야 합니다. 이 작업을 수행할 수 있는 명령을 사용할 수 있습니다.
locate_stream_files 양식
—————————– locate_stream_files ————————-
directory_names:
- 깊이 :
-유형: 64비트
-간략한: 아니요
-롱: 아니요
-형식은 또한 플렉스, 스파스 또는 큰 (특정 특성을 가진 64 비트 스트림 파일을 찾습니다) 또는 모든 (모든 스트림 파일을 찾을 것)일 수 있습니다.
-depth에 따라 하위 디렉터리검색되고 파일에 속성(형식별로 지정되지 않음)이 있는 경우 해당 및 범위 크기에 대한 정보도 표시됩니다. 디렉터리 이름이 지정되지 않으면 모듈의 모든 디스크가 루트에서 검색됩니다. 예를 들어:
locate_stream_files -유형 64 비트
디스크 %swsle #raid0-1에 디렉토리 확인...
%swsle#raid0-1:
smb_test.stm64 (플렉스/대형)
smb_test.stmb
총 2 개의 64 비트 스트림 파일.
디스크 %swsle #raid0-2에 디렉토리 확인...
%swsle#raid0-2:
big_stream (플렉스)
smb_test.stm (플렉스)
smb_test.stm64a(플렉스/대형)
총 3 개의 64 비트 스트림 파일.
디스크 %swsle #Raid4에서 디렉토리 확인...
%swsle#Raid4>오토:
b3 (대8)
큰 (DAE-256/대형/스파스)
...
– 블록 비교
릴리스 17.2 및 18.0에서는 스트림 파일에 유용한 compare_files 명령에 새 옵션을 사용할 수 있습니다. VOS 구조화 된 파일 형식의 블록 비교에 의해 블록은 일반적으로 다른 값을 가진 두 블록이 동일한 논리 레코드를 나타내기 때문에 유용하지 않습니다. 예를 들어 상대 파일의 레코드에서 현재 길이를 지나 사용하지 않는 데이터는 예측할 수 없습니다. 또한 순차 파일에는 정의되지 않은 필러 바이트가 포함되어 있습니다. 동일한 논리 레코드를 나타내지만 레코드 크기가 다른 경우 확장 된 순차 파일의 블록 내용이 완전히 다릅니다.
그러나 블록 비교는 고정 및 스트림 파일에 유용할 수 있습니다. 문제는 compare_files 레코드 지향이며 편집기를 사용하여 위치할 수 있는 레코드 번호(또는 줄 번호)의 측면에서 차이를 표시하도록 설계되었다는 것입니다. 이것은 레코드 의 관점에서 구성되지 않은 바이너리 스트림 파일에 대한 문제를 제시했습니다. 모든 파일에 대한 레코드 크기는 32767 바이트로 제한되기 때문에 스트림 파일에 s$seq_read 사용하여 NL 레코드 디리미터가 개입하지 않고 32k 바이트 이상의 시퀀스가 발생하면 다음 32767 문자를 전달하고 다음 바이트가 NL인지 여부를 구분하지 않습니다. 이렇게 하면 NL 문자로 구분된 문자 시퀀스가 아니라 이진 값을 보유하는 스트림 파일에 대한 레코드 지향 비교가 모호합니다.
이 문제는 릴리스 17.2에서 처리되었습니다. compare_files 이전에 거짓 성공이 발생했을 수 있는 경우를 감지합니다 - 특히 NL이 뒤따르지 않는 NL 매치 32767자 다음에 32767자다음에 32767자씩 등장합니다. 이 경우 스트림 파일에 레코드가 포함되어 있음을 나타내는 오류가 보고됩니다 . 32767. 이 경우 레코드 지향 결과가 유효하며 신뢰할 수 있습니다. 그러나 어떤 경우에도 파일이 동일하다고 보장할 때 구조화되지 않은 파일의 블록을 레코드 지향 방법보다 훨씬 빠릅니다. 블록 비교의 문제는 가이드 포스트역할을 할 레코드가 없는 경우 첫 번째 불일치 후비교가 종종 의미가 없다는 것입니다.
릴리스 17.2에서 -compare_blocks 옵션이 이 목적을 위해 compare_files 명령에 추가되었습니다. 이렇게 하면 구조화되지 않은 파일이 동일한 블록에 대한 블록인지 여부를 빠르게 감지하고 서로 다른 블록을 식별합니다. 드물게 오버레이(삽입 또는 삭제되는 것과 는 반대로 수정되는 특정 바이트)와 나머지 파일이 동일한 경우 -계속 옵션도 사용할 수 있습니다. 이렇게 하면 파일의 나머지 부분에서 블록 범위가 다른 지 확인할 수 있습니다. 예를 들어 바이트가 삽입된 경우(오버레이가 아닌) 나머지 모든 블록은 다릅니다. 즉, 레코드 비교와 마찬가지로 다시 동기화'ing은 블록 비교와 함께 불가능합니다. 그러나 언급 된 경우,이 추가 정보는 유일한 차이점이 몇 블록에 일부 오버레이 바이트임을 확인할 수 있습니다, 아마도 타임 스탬프 같은 것을 나타내는.
-compare_blocks -계속의 예로:
compare_files 플렉스 dae256 -compare_blocks -계속
A(%swsle#m111_mas>Stratus>Newman>플렉스)는 B(%swsle#m111_mas>Stratus>Newman>dae256)와 일치하지 않습니다.
– 2에서 24까지의 데이터 블록이 다릅니다.
– 데이터 블록은 33에서 488까지 다릅니다.
– 파일 B의 272 개의 추가 블록.
– 스파스 파일 비교
compare_files 명령은 파일의 물리적으로 존재하는 모든 블록을 살펴봅니다. 이 문제는 스파스 파일의 문제가 될 수 있습니다., 바이너리 제로의 블록 은 한 파일에 할당 된 블록으로 나타날 수 있습니다., 아직 다른 에 존재 하지. 파일은 논리적으로 동일할 수 있지만 블록을 차단하지는 않습니다. 사실, copy_file 사용하면 대상에서 바이너리 제로 블록을 제거하고, 존재하는 경우 소스와 대상이 동일한 블록에 대한 블록이 되지 않도록 보장합니다.
이것은 또한 범위 기반 스트림 파일의 문제, 왜냐하면 모든 블록은 모든 이진 제로를 포함하더라도 항상 인스턴스화되기 때문입니다. 즉, 희소 범위 파일의 블록은 동일한 데이터를 나타내더라도 동일한 비익범위 파일의 블록이 다르게 보일 수 있습니다. copy_file 실행하면 블록이 어느 정도 제거할 수 없습니다.
위의 사용을 보여주는 예는 DAE-256 익스텐트와 다른 하나는 유연한 범위를 가지고 있다는 점을 제외하고는 실제로 두 개의 동일한 파일을 포함합니다.
따라서 내용 "abc"가있는 DAE-8 파일에는 "abc"가있는 블록이 하나 있으며 7 개의 이진 제로가 포함됩니다. 비익 파일(또는 플렉스 파일)에는 "abc"가 있는 블록이 하나뿐이며 DAE-16 파일에는 "abc" 블록이 있고 15블록의 이진 제로가 뒤따릅니다.
-compare_blocks compare_files 명령을 사용하면 모두 동일한 파일 데이터를 나타내더라도 이러한 모든 파일이 다른 것으로 표시됩니다. 릴리스 18.0에서는 이 상황에 대해 -compare_all_blocks 옵션을 사용할 수 있습니다. 이로 인해 copy_file 비교되는 파일에서 누락된 블록을 논리적으로 인스턴스화하여 희소성 제거로 인한 차이점과 비교하여 블록별 진정한 블록을 생성합니다. stream64 파일에서 누락된 블록은 고정된(또는 다른 모든 파일 유형)에 있는 동안 모든 이진 제로로 간주됩니다.
매우 드문 파일에서는 -compare_blocks 옵션을 사용하는 것보다 비교속도가 훨씬 느려지지만 기본 레코드 지향 비교를 사용하는 것보다 훨씬 빠릅니다. 일반적으로 다른 범위를 갖는 파일 블록을 비교할 때만 필요하지만, 희소점이 다를 수 있는 다른 경우도 있습니다. 이는 범위가 다른 고정 파일에도 유용합니다.