버퍼 사본 제거와 복원 및 검색

온라인 편집

IBM® Storage Protect 서버는 복원 및 검색을 통한 테이프 액세스 최적화를 기반으로 버퍼에 배치할 데이터의 양을 제어합니다. 이 방법은 데이터를 가져오는 보통 방법 보다 애플리케이션에 유용하지 않습니다. 프로토타입 작성 중 버퍼 사본 제거 방법의 성능을 확인하고 가치있는 개선을 확인하는 경우에만 이 방법을 사용하십시오.

IBM Storage Protect 서버가 리턴하는 단일 버퍼의 최대 데이터 양은 (256K 바이트 헤더 오버헤드) 입니다. 그 결과로, 작은 버퍼를 처리하는 애플리케이션만 이 데이터 검색 메커니즘의 이점을 작성합니다. 애플리케이션은 오브젝트 크기, 네트워크, 기타 경계 조건에 따라 버퍼의 바이트 수에 특별한 주의를 기울여야 합니다. 일부 경우에는 버퍼 사본 제거를 사용하면 실제로 일반적인 복원보다 결과가 나쁠 수 있습니다. API는 일반적으로 데이터를 캐시하고 고정된 길이를 애플리케이션으로 리턴합니다. 그런 다음, 애플리케이션은 디스크로의 데이터 다시 쓰기 수를 제어할 수 있습니다.

버퍼 사본 제거를 사용하는 경우, 선호되는 쓰기 버퍼 크기 보다 작은 버퍼에 대한 데이터 캐싱 메커니즘을 작성하십시오. 예를 들어, 애플리케이션이 64K 데이터 블록을 디스크에 쓰는 경우 애플리케이션은 다음 조치를 수행해야 합니다.
  1. dsmGetBufferData를 호출하십시오.
  2. 64KB의 블록 쓰기.
  3. 마지막 블록에서 나머지를 tempBuff에 복사하고 다른 dsmGetBufferData 호출을 실행하며 tempBuff를 나머지 데이터로 채우십시오.
  4. 64KB의 블록 쓰기를 계속하십시오.
dsmGetBufferData #1 get 226K        dsmGetBufferData #2 get 240K
Block1 64K - write to disk          Block1 30K - copy to tempbuff-write to disk
Block2 64K - write to disk          Block2 64K - write to disk
Block3 64K - write to disk          Block3 64K - write to disk
Block4 34K - copy to tempbuff       Block4 64K - write to disk
Block5 18K - write to tempbuff        etc

이 예제에서, 여섯 개의 디스크 쓰기가 직접적이고 1이 캐시됩니다.

복원 및 검색에 대한 호출의 전체 순서는 다음과 같습니다.

dsmInitEx(UseTsmBuffers = True numTsmBuffers = 애플리케이션이 할당하려는 버퍼 수).

dsmBeginGetData 
While obj id
  dsmGetObj (no data restored on this call- buffer set to NULL)
 While data to read
   dsmGetBufferData (returns the data in the data buffer)
  ...process data... 
  dsmReleaseBuffer  
dsmEndGetObj
dsmEndGetData

모든 dsmGetBufferData 호출의 경우, dsmReleaseBuffer 호출을 구현하십시오. dsmGetBufferData 및 해당 dsmReleaseBuffer 는 연속적일 필요가 없습니다. 애플리케이션은 다중 dsmGetBufferData 호출을 먼저 발행하여 여러 버퍼를 가져온 후 해당 dsmReleaseBuffer 호출을 나중에 발행할 수 있습니다. 이 함수를 사용하는 샘플 코드의 경우, API 샘플 디렉토리에서 callbuff.c를 참조하십시오.

제한사항: API는 버퍼를 제공하고 목표는 프로세서 활용도를 최소화하는 것이므로 버퍼에서 더 많은 데이터 처리가 허용되지 않습니다. 이러한 모든 조작에는 데이터 처리 및 사본이 필요하므로 버퍼 사본 제거로 암호화 및 압축을 사용할 수 없습니다.

정규 데이터 이동 경로와 버퍼 사본 제거를 둘 다 구현하여 사용자가 필요에 따라 두 경로 사이에서 전환할 수 있도록 설정하십시오. 사용자가 데이터를 압축하거나 암호화하는 경우, 기존 메커니즘을 사용하십시오. 프로세서 제한조건이 있는 경우 새 메커니즘을 사용하십시오. 이러한 두 메커니즘은 모두 보완적인 것이며 서로를 완전히 대체하지는 않습니다.