KR20060045646A - 정보 처리 장치 및 정보 처리 방법과, 프로그램 및 기록매체 - Google Patents

정보 처리 장치 및 정보 처리 방법과, 프로그램 및 기록매체 Download PDF

Info

Publication number
KR20060045646A
KR20060045646A KR1020050030599A KR20050030599A KR20060045646A KR 20060045646 A KR20060045646 A KR 20060045646A KR 1020050030599 A KR1020050030599 A KR 1020050030599A KR 20050030599 A KR20050030599 A KR 20050030599A KR 20060045646 A KR20060045646 A KR 20060045646A
Authority
KR
South Korea
Prior art keywords
file
data
drive
irp
command
Prior art date
Application number
KR1020050030599A
Other languages
English (en)
Other versions
KR101116433B1 (ko
Inventor
신 기무라
가즈히사 쯔찌야
노부히로 사까이
가즈히꼬 와따나베
Original Assignee
소니 가부시끼 가이샤
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 소니 가부시끼 가이샤 filed Critical 소니 가부시끼 가이샤
Publication of KR20060045646A publication Critical patent/KR20060045646A/ko
Application granted granted Critical
Publication of KR101116433B1 publication Critical patent/KR101116433B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0613—Improving I/O performance in relation to throughput
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/0674—Disk device
    • G06F3/0677—Optical disk device, e.g. CD-ROM, DVD
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/11—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information not detectable on the record carrier
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327—Table of contents
    • G11B27/329—Table of contents on a disc [VTOC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/765—Interface circuits between an apparatus for recording and another apparatus
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00—Details of television systems
    • H04N5/76—Television signal recording
    • H04N5/84—Television signal recording using optical recording
    • H04N5/85—Television signal recording using optical recording on discs or drums

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Software Systems (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

내부에 파일 시스템을 갖는 기록 또는 재생 장치를 용이하게 취급한다. PC(1)의 파일 시스템 드라이버인 PD_FS(54)에서는, 어플리케이션이 파일 조작에 관한 API 함수를 호출하는 것에 의해 공급되는 IRP(I/O Request Packet)가, 드라이브(2)와의 IEEE1394 통신에 있어서 파일 시스템을 취급하는 것이 가능한, SBP2를 확장한 PD-SBP2의 커맨드로 변환되는 사용자 정의의 IOCTL을 발행하는 함수 IoCallDriver()로 변환된다. 그리고, 그 함수 IoCallDriver가 호출되는 것에 의해, PD 스토리지(55)는, PD-SBP2의 커맨드를, 드라이브(2)에 출력한다. 이것에 의해, PC(1)로부터는, 드라이브(2)의 가상 파일 시스템(62)을 그대로 이용할 수 있다. 본 발명은, 예를 들면, 파일 시스템 드라이버에 적용할 수 있다.
파일 시스템, 정보 처리 장치, 기록 매체, 프로그램

Description

정보 처리 장치 및 정보 처리 방법과, 프로그램 및 기록 매체{INFORMATION PROCESSING APPARATUS AND METHOD, AND PROGRAM AND RECORDING MEDIUM}
도 1은 본 발명을 적용한 정보 처리 시스템의 일 실시형태의 구성예를 도시하는 블록도.
도 2는 PC(1)의 하드웨어 구성예를 도시하는 블록도.
도 3은 CPU(12)가 실행하는 프로그램을 도시하는 도면.
도 4는 OS(30)의 내부 구성예(파일 시스템)를 도시하는 블록도.
도 5는 OS(30)가 행하는 처리의 개요를 설명하는 플로우차트.
도 6은 드라이브(2)의 파일 시스템과, 드라이브(2)에서 채용되고 있는 프로토콜에 대해서 설명하기 위한 도면.
도 7은 가상 파일 시스템(62)을 설명하기 위한 도면.
도 8은 SCSI command block ORB의 포맷을 도시하는 도면.
도 9는 SBP2 status block의 포맷을 도시하는 도면.
도 10은 확장 커맨드를 도시하는 도면.
도 11은 PD-SBP2에 의한 파일의 판독 시퀀스를 설명하는 플로우차트.
도 12는 PD-SBP2에 의한 파일의 기입 시퀀스를 설명하는 플로우차트.
도 13은 사용자 정의의 IOCTL을 도시하는 도면.
도 14는 PD_FS(54)의 처리를 설명하는 플로우차트.
도 15는 복수 동시 오픈 기능을 설명하기 위한 도면.
도 16은 복수 동시 오픈 기능의 처리를 설명하는 플로우차트.
<도면의 주요 부분에 대한 부호의 설명>
1 : PC
2 : 드라이브
3 : 광 디스크
4 : 1394 케이블
11 : 버스
12 : CPU
13 : ROM
14 : RAM
15 : 하드디스크
16 : 출력부
17 : 입력부
18 : 통신부
19 : 드라이브
20 : 입출력 인터페이스
21 : 리무버블 기록 매체
22 : IEEE1394 I/F
30 : OS
31 : 어플리케이션
51 : Win32 서브 시스템
52 : NT 입출력 매니저
53 : FS 필터 드라이버
54 : PD_FS
54A : 파일 핸들 리소스 매니저
55 : PD 스토리지
56 : SBP2 드라이버
57 : 1394 버스 드라이버
58 : 레지스트리
59 : NT 캐쉬 매니저
61 : 실제 파일 시스템
62 : 가상 파일 시스템
<특허문헌 1> 일본 특개 2004-005895호 공보
본 발명은, 정보 처리 장치 및 정보 처리 방법과, 프로그램 및 기록 매체에 관한 것으로, 특히, 예를 들면, 내부에 파일 시스템을 갖는 디스크 드라이브 등의 기록 또는 재생 장치를, 범용의 컴퓨터로, 용이하게 취급할 수 있도록 하는 정보 처리 장치 및 정보 처리 방법과, 프로그램 및 기록 매체에 관한 것이다.
최근, 예를 들면, 광 디스크에, 고 비트 레이트의 AV(Audio Visual) 데이터를 기록하고, 재생하는 것이 요청되고 있다.
그래서, 예를 들면, 비디오 데이터나, 그것에 부수하는 오디오 데이터 등의 복수의 데이터 계열 각각을, 주기적으로, 또한, 그 경계가 광 디스크의 섹터 등의 경계와 일치하도록, 광 디스크에 기록하는 디스크 드라이브를 본건 출원인은 앞서 제안하고 있다(예를 들면, 특허 문헌1 참조).
이 디스크 드라이브에 의하면, 비디오 데이터나 오디오 데이터가, 어느 정도 통합되어, 광 디스크 상의 연속된 기록 영역에 기록되므로, 그 통합된 데이터를, 씨크없이 기입 및 판독할 수 있다.
또한, 비디오 데이터와 오디오 데이터와의 경계가, 광 디스크의 섹터의 경계와 일치하기 때문에, 1개의 섹터에, 비디오 데이터와 오디오 데이터가 혼재하지 않는다. 이 때문에, 예를 들면, 비디오 데이터만, 또는 오디오 데이터만을 판독할 수 있다. 즉, 예를 들면, 비디오 데이터만을 필요로 할 때에, 광 디스크로부터, 비디오 데이터만을 판독할 수 있어, 1개의 섹터에, 비디오 데이터와 오디오 데이터가 혼재하는 경우에 비해서, 비디오 데이터만을 효율좋게(고속으로) 판독할 수 있다. 오디오 데이터에 대해서도 마찬가지이다.
본건 출원인은, 또한, 예를 들면, 광 디스크의 기록 영역 상의 소정의 크기 이상의 연속된 빈 영역 중, 직전에 데이터가 기록된 기록 영역에 가장 가까운 위치의 빈 영역을 예약하고, 그 빈 영역에, 데이터를 기록하는 디스크 드라이브도 제안하고 있다.
이 경우, 이상적으로는, 어떤 일련의 데이터는, 광 디스크 상의 연속된 기록 영역에, 말하자면 일필(一筆) 기입되도록 기록된다. 따라서, 데이터의 기록 재생시에, 씨크의 발생을 억제할 수 있어, 고 비트 레이트의 AV 데이터를, 리얼타임으로 광 디스크에 기록하고, 또한, 광 디스크로부터 고 비트 레이트의 AV 데이터를, 리얼타임으로 재생할 수 있다.
여기서, 이와 같이, 광 디스크의 기록 영역 상의 소정의 크기 이상의 연속된 빈 영역 중, 직전에 데이터가 기록된 기록 영역에 가장 가까운 위치의 빈 영역을 예약하여, 데이터를 기록하는 것에 의해서, 데이터의 기록 재생시에 발생하는 씨크의 발생을 억제하는 디스크 드라이브를, 이하, 적절하게, 프로페셔널 디스크 드라이브라고 한다.
또, 프로페셔널 디스크 드라이브에 의해서, 데이터가 기록된 광 디스크를, 이하, 적절하게, 프로페셔널 디스크라고 한다. 또한, 프로페셔널 디스크를, 이하, 적절하게, PD(Professional Disc)라고 약기한다. 또, 광 디스크 상의 연속된 기록 영역에 일필 기입되는 데이터의 기록을, 이하, 적절하게, 일필 기입 기록이라고 한다.
PD 드라이브에서는, 파일 시스템(File System)으로서, 예를 들면, UDF(Universal Disk Format)가 채용되고, 또한, AV 데이터를 UDF의 형식으로 일필 기입 기록하는 제어가 행해진다. 또, PD 드라이브에서는, 파일의 할당(File Allocation) 관리나, 광 디스크(PD)에 있어서의 디펙트(Defect)에 대한 디펙트 처리, 빈 영역 관리 등도 행해진다.
여기서, PD 드라이브의 파일 시스템은, 상술한 바와 같은 일필 기입 기록의 제어나, 파일의 할당 관리, 디펙트 처리, 빈 영역 관리 등을 행하는 기능을 갖고 있고, 이 기능의 처리를 행하는 부분을, 이하, 적절하게, PD 할당 매니저라고 한다.
그런데, 최근에는, 고속의 CPU(Central Processing Unit)나, 대용량의 메모리의 저가격화 등에 수반하여, 고 기능이고 저가격인 컴퓨터가 실현되고 있다. 또한, 그러한 컴퓨터에 있어서, 대용량의 AV 데이터의 편집과 그 밖의 처리를 행하는 어플리케이션(프로그램)(이하, 적절하게, AV 어플리케이션이라고 함)도 실현되고 있다.
그리고, 컴퓨터에 대해서, 예를 들면, 내장하는 형태로, 또는 외부 부착의 형태로 PD 드라이브를 접속하고, AV 어플리케이션으로부터, PD 드라이브에 액세스해서, PD에 대한 AV 데이터의 기입 및 판독을 행하는 것의 요청이 높아져 오고 있다.
컴퓨터의 AV 어플리케이션으로부터, PD 드라이브(의 PD)에 대한 AV 데이터의 기록이나 재생을 행하기 위해서는, PD 드라이브를, 컴퓨터(에 인스톨되어 있는 OS(Operating System))에 탑재(Mount)할 필요가 있다.
PD 드라이브의 탑재 방법으로서는, 예를 들면, 컴퓨터에 인스톨되어 있는 OS에서 준비되어 있는 범용의 파일 시스템인 UDF나, NTFS(New Technology File System), FAT(File Allocation Table) 등으로, PD 드라이브를 탑재하는 방법이 있다.
그러나, PD 드라이브를, OS에서 준비되어 있는 범용의 파일 시스템으로 탑재하면, PD 드라이브에 있어서, 일필 기입 기록의 제어 등이 행해지지 않고, 그 결과, AV 데이터를 리얼타임으로 기입 및 판독하는 것이 보증되지 않게 된다. 즉, 일필 기입 기록의 제어가 행하여지지 않는 경우에는, AV 데이터가, 말하자면 잘게 잘린 상태로 떨어진 위치에 기록되는 경우가 발생하고, 그 결과, 씨크가 다발하여, 고 비트 레이트의 AV 데이터의 리얼타임으로 기입 및 판독하는 것이 곤란하게 된다.
또한, PD 드라이브의 내부의 파일 시스템으로서, 상술한 바와 같이, UDF가 채용되고 있는 경우에, PD 드라이브를, UDF 드라이버로 컴퓨터에 탑재하면, 컴퓨터 상의 어플리케이션으로부터는, PD 드라이브에 있어서의 PD 상의 UDF 형식의 파일이, 말하자면, 그대로 보이게 된다.
따라서, PD 상의 AV 데이터의 파일이, 예를 들면, MXF(Material eXchange Format) OP-Atom 형식으로, 동일 콘텐츠의 비디오 데이터와 오디오 데이터가 별도 파일로 되어 있고, 또한, 오디오 데이터에 대해서는, 채널마다 별도 파일로 되어 있는 경우에는, 컴퓨터 상의 어플리케이션으로부터는, 어떤 콘텐츠의 AV 데이터가, 비디오 데이터의 파일과, 각 채널의 오디오 데이터의 파일로서 보이게 되어, 취급 이 불편하게 된다.
한편, PD 드라이브가 내부에 갖는 파일 시스템은, 상술한 바와 같이, 일필 기입 기록의 제어나, 파일의 할당 관리, 디펙트 처리, 빈 영역 관리 등을 행하는 PD 할당 매니저를 갖고 있다. 따라서, PD 드라이브의 파일 시스템을 그대로 이용할 수 있으면, 컴퓨터(의 어플리케이션)로부터, PD 드라이브를, 용이하게 취급할 수 있다.
본 발명은, 이러한 상황을 감안하여 이루어진 것으로, 내부에 파일 시스템을 갖는 디스크 드라이브 등의 기록 또는 재생 장치를, 용이하게 취급할 수 있도록 하는 것이다.
본 발명의 정보 처리 장치는, 오퍼레이팅 시스템이 제공하는 커맨드를, 기록 또는 재생 장치와의 통신에서 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 수단을 구비하는 것을 특징으로 한다.
기록 또는 재생 장치가 1개의 파일 핸들만을 취급하는 경우에는, 정보 처리 장치에는, 기록 또는 재생 장치의 1개의 파일 핸들에 대한 액세스의 배타 제어를 행하는 배타 제어 수단을 더 설치할 수 있다.
정보 처리 장치는, 기록 또는 재생 장치의 파일 시스템에 의해서 행해지는 파일 관리를 행하지 않는 파일 시스템 드라이버로 할 수 있다.
기록 또는 재생 장치에서 파일에 기입 및 판독되는 데이터는, AV 데이터를, 적어도 포함하는 것으로 할 수 있다.
기록 또는 재생 장치는, 기록 매체의 기록 영역 상의 소정의 크기 이상의 연속된 빈 영역 중, 직전에 데이터가 기록된 기록 영역에 가장 가까운 위치의 빈 영역을 예약하여, 데이터를 기록하는 것으로 할 수 있다.
본 발명의 정보 처리 방법은, 오퍼레이팅 시스템이 제공하는 커맨드를, 기록 또는 재생 장치와의 통신에서 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 단계를 포함하는 것을 특징으로 한다.
본 발명의 프로그램은, 오퍼레이팅 시스템이 제공하는 커맨드를, 기록 또는 재생 장치와의 통신에서 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 단계를 포함하는 것을 특징으로 한다.
본 발명의 기록 매체에 기록되어 있는 프로그램은, 오퍼레이팅 시스템이 제공하는 커맨드를, 기록 또는 재생 장치와의 통신에서 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 단계를 포함하는 것을 특징으로 한다.
본 발명에 있어서는, 오퍼레이팅 시스템이 제공하는 커맨드가, 기록 또는 재생 장치와의 통신에 있어서 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환된다.
[발명을 실시하기 위한 최선의 형태]
이하에, 본 발명의 실시형태를 설명하지만, 청구항에 기재된 구성 요건과, 발명의 실시형태에 있어서의 구체예와의 대응 관계를 예시하면, 다음과 같이 된다. 이 기재는, 청구항에 기재되어 있는 발명을 서포트하는 구체예가, 발명의 실시형태 에 기재되어 있는 것을 확인하기 위한 것이다. 따라서, 발명의 실시형태 중에는 기재되어 있지만, 구성 요건에 대응하는 것으로서, 여기에는 기재되어 있지 않은 구체예가 있다고 하더라도, 그것은, 그 구체예가, 그 구성 요건에 대응하는 것이 아니라는 것을 의미하는 것은 아니다. 반대로, 구체예가 구성 요건에 대응하는 것으로서 여기에 기재되어 있다고 하더라도, 그것은, 그 구체예가, 그 구성 요건 이외의 구성 요건에는 대응하지 않는 것이라는 것을 의미하는 것도 아니다.
또한, 이 기재는, 발명의 실시형태에 기재되어 있는 구체예에 대응하는 발명이, 청구항에 모두 기재되어 있는 것을 의미하는 것은 아니다. 바꾸어 말하면, 이 기재는, 발명의 실시형태에 기재되어 있는 구체예에 대응하는 발명으로서, 이 출원의 청구항에는 기재되어 있지 않은 발명의 존재, 즉, 장래, 분할 출원되거나, 보정에 의해 추가되는 발명의 존재를 부정하는 것은 아니다.
본 발명의 정보 처리 장치는,
파일 시스템(예를 들면, 도 6의 실제 파일 시스템(61) 또는 가상 파일 시스템(62))을 갖는 기록 또는 재생 장치(예를 들면, 도 6의 드라이브(2))와 접속되는 정보 처리 장치(예를 들면, 도 6의 PD_FS(54))로서,
어플리케이션으로부터의 파일 조작에 관한 요구(예를 들면, API 함수의 호출)에 따라서 오퍼레이팅 시스템이 제공하는 커맨드(예를 들면, IRP)를 수신하는 수신 수단(예를 들면, 도 14의 단계 S101의 처리를 행하는 도 6의 PD_FS(54))와,
상기 오퍼레이팅 시스템이 제공하는 커맨드를, 상기 기록 또는 재생 장치와의 통신(예를 들면, IEEE1394의 규격에 준거한 통신)에서 상기 파일 시스템을 취급 하는 것이 가능한 통신 프로토콜(예를 들면, SBP2)의 커맨드로 변환되는 요구(예를 들면, 사용자 정의의 IOCTL을 발행하는 함수 IoCallDriver())로 변환하는 변환 수단(예를 들면, 도 14의 단계 S102의 처리를 행하는 도 6의 PD_FS(54))를 구비하는 것을 특징으로 한다.
본 발명의 정보 처리 장치는,
상기 기록 또는 재생 장치가 1개의 파일 핸들만을 취급하는 경우에,
상기 기록 또는 재생 장치의 1개의 파일 핸들에 대한 액세스의 배타 제어를 행하는 배타 제어 수단(예를 들면, 도 15의 파일 핸들 리소스 매니저(54A))를 더 구비하는 것을 특징으로 한다.
본 발명의 정보 처리 방법은,
파일 시스템을 갖는 기록 또는 재생 장치와 접속되는 정보 처리 장치의 정보 처리 방법으로서,
어플리케이션으로부터의 파일 조작에 관한 요구에 따라서 오퍼레이팅 시스템이 제공하는 커맨드를 수신하는 수신 단계(예를 들면, 도 14의 단계 S101)와,
상기 오퍼레이팅 시스템이 제공하는 커맨드를, 상기 기록 또는 재생 장치와의 통신에서 상기 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 단계(예를 들면, 도 14의 단계 S102)를 포함하는 것을 특징으로 한다.
본 발명의 프로그램 및 본 발명의 기록 매체에 기록되어 있는 프로그램은,
파일 시스템을 갖는 기록 또는 재생 장치와 접속되는 컴퓨터가 행하도록 하 는 프로그램으로서,
어플리케이션으로부터의 파일 조작에 관한 요구에 따라서 오퍼레이팅 시스템이 제공하는 커맨드를 수신하는 수신 단계(예를 들면, 도 14의 단계 S101)와,
상기 오퍼레이팅 시스템이 제공하는 커맨드를, 상기 기록 또는 재생 장치와의 통신에 있어서 상기 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 단계(예를 들면, 도 14의 단계 S102)를 포함하는 것을 특징으로 한다.
이하, 도면을 참조하여, 본 발명의 실시형태에 대해서 설명한다.
도 1은, 본 발명을 적용한 정보 처리 시스템의 일 실시형태의 구성예를 나타내고 있다.
도 1에 있어서, 정보 처리 시스템은, PC(Personal Computer)(1)와 드라이브(2)로 구성되어 있다.
PC(1)는, OS(Operating System)나, 어플리케이션(프로그램)을 기억하고 있고, OS의 제어하에서, 어플리케이션을 실행함으로써, 각종의 처리를 행한다.
드라이브(2)는, 예를 들면, 상술한 PD(Professional Disc) 드라이브로서, 1394 케이블(4)을 통하여, PC(1)와 접속되어 있다. 드라이브(2)는, PD인 광 디스크(3)의 착탈이 가능하게 되어 있고, PC(1) 사이에서, IEEE(Institute of Electronic and Electronics Engineers)1394의 규격에 준거한 통신을 행하는 것에 의해, 광 디스크(3)에 대해서, AV 데이터와 그 밖의 데이터의 기입 및 판독을 행한다.
또한, 드라이브(2)는, PD 드라이브일 필요는 없고, 광 디스크도 PD일 필요는 없다. 또한, PC(1)와 드라이브(2) 사이에서는, IEEE1394 이외의 규격에 준거한 통신을 행하는 것이 가능하다.
다음으로, 도 2는, 도 1의 PC(1)의 하드웨어 구성예를 나타내고 있다.
PC(1)는, CPU(Central Processing Unit)(12)를 내장하고 있다. CPU(12)에는, 버스(11)를 통하여, 입출력 인터페이스(20)가 접속되어 있고, CPU(12)는, 입출력 인터페이스(20)를 통하여, 사용자에 의해서, 키보드나, 마우스, 마이크 등으로 구성되는 입력부(17)가 조작되는 등에 의해 명령이 입력되면, 그것에 따라서, ROM(Read Only Memory)(13)에 저장되어 있는 프로그램을 실행한다. 혹은, 또한, CPU(12)는, 하드디스크(15)에 저장되어 있는 프로그램, 위성 혹은 네트워크로부터 전송되고, 통신부(18)에서 수신되어 하드디스크(15)에 인스톨된 프로그램, 또는 드라이브(19)에 장착된 리무버블 기록 매체(21)로부터 판독되어 하드디스크(15)에 인스톨된 프로그램을, RAM(Random Access Memory)(14)에 로드하여 실행한다. 이것에 의해, CPU(12)는, 후술하는 플로우차트에 따른 처리, 혹은 후술하는 블록도의 구성에 의해 행해지는 처리를 행한다. 그리고, CPU(12)는, 그 처리 결과를, 필요에 따라, 예를 들면, 입출력 인터페이스(20)를 통하여, LCD(Liquid Crystal Display)나 스피커 등으로 구성되는 출력부(16)로부터 출력시키거나, 혹은, 통신부(18)로부터 송신시키거나, 또는, 하드디스크(15)에 기록 등을 시킨다.
또, PC(1)에 있어서는, 입출력 인터페이스(20)에, IEEE1394의 규격에 준거한 통신 제어를 행하는 IEEE1394 I/F(InterFace)(22)가 접속되어 있다. IEEE1394 I/F(22)에는, 1394 케이블(4)을 통하여, 드라이브(2)가 접속되어 있다. CPU(12)는, 버스(11), 입출력 인터페이스(20), IEEE1394 I/F(22), 및 1394 케이블(4)을 통하여, 드라이브(2)에 액세스하여, 그 드라이브(2)에 장착되어 있는 광 디스크(3)에 대해서, 데이터를 기입 및 판독할 수 있다.
여기서, CPU(12)는, OS나 각종의 어플리케이션의 프로그램을 실행하지만, 이들의 프로그램은, PC(1)에 내장되어 있는 기록 매체로서의 하드디스크(15)나 ROM(13)에 미리 기록해 둘 수 있다.
혹은, 프로그램은, 플렉시블 디스크, CD-ROM(Compact Disc Read Only Memory), MO(Magneto Optical) 디스크, DVD(Digital Versatile Disc), 자기 디스크, 반도체 메모리 등의 리무버블 기록 매체(21)에, 일시적 혹은 영속적으로 저장(기록)해 둘 수 있다. 이러한 리무버블 기록 매체(21)는, 소위 패키지 소프트웨어로서 제공할 수 있다.
또한, 프로그램은, 상술한 바와 같은 리무버블 기록 매체(21)로부터 PC(1)에 인스톨하는 것 외에, 다운로드 사이트로부터, 디지털 위성 방송용의 인공위성을 통하여, PC(1)에 무선으로 전송하거나, LAN(Local Area Network), 인터넷과 같은 네트워크를 통하여, PC(1)에 유선으로 전송하고, PC(1)에서는, 그와 같이 해서 전송되어 오는 프로그램을, 통신부(18)에서 수신하여, 내장된 하드디스크(15)에 인스톨할 수 있다.
다음으로, 도 3은, 도 2의 CPU(12)가 실행하는 프로그램을 도시하는 도면이다.
예를 들면, OS(30) 및 어플리케이션(31)(의 프로그램)이, 적어도, 도 2의 하드디스크(15)에 인스톨되어 있고, CPU(12)는, PC(1)의 전원이 온으로 되면, 하드디스크(15)로부터 RAM(14)에, OS(30)를 로드하여 실행한다. 또한, 예를 들면, 사용자가 입력부(17)를 조작하는 등을 행하여, 어플리케이션(31)의 기동을 요구하면, CPU(12)는, 하드디스크(15)로부터 RAM(14)에, 어플리케이션(31)을 로드하여, OS(30)의 제어하에서 실행한다.
그리고, 어플리케이션(31)이, 예를 들면, 드라이브(2)에 장착된 광 디스크(3)에 대한 파일 조작에 관한 요구인 액세스 요구를 행하면, OS(30)는, 그 액세스 요구를 처리한다. 이것에 의해, 드라이브(2)에 있어서, 어플리케이션(31)으로부터의 액세스 요구에 의해서 기록이 요구된 데이터가, 광 디스크(3)에 기록된다. 혹은, 드라이브(2)에 있어서, 어플리케이션(31)으로부터의 액세스 요구에 의해서 재생(판독)이 요구된 데이터가, 광 디스크(3)로부터 판독되어, OS(30)를 통하여, 액세스 요구를 행한 어플리케이션(31)에 전달된다.
또한, 도 2의 하드디스크(15)에 인스톨하는 어플리케이션은, 어플리케이션(31)의 1개에 한정되는 것은 아니고, 2개 이상이라도 된다.
또, 어플리케이션(31)은, 예를 들면, 외부로부터의 AV 데이터의 취입이나, AV 데이터의 편집, 기록, 재생 등을 행하는 AV 어플리케이션인 것으로 한다. 단, 어플리케이션(31)은, AV 어플리케이션일 필요는 없다. 즉, 어플리케이션(31)은, 예를 들면, 텍스트 데이터의 편집 등을 행하는 어플리케이션이라도 되고, 파일의 표시를 행하는 어플리케이션(예를 들면, 「익스플로러」나 「파일 매니저」 등과 같은 파일 유틸리티)이라도 된다.
다음으로, OS(30)로서는, 예를 들면, Unix(R)나, Linux, 또는, 마이크로소프트사의 Windows(R)라고 불리고 있는 것, 그 밖의 임의의 OS를 채용할 수 있지만, 여기서는, 예를 들면, Windows(R)의 NT계의 OS가 채용되고 있다. 또한, Windows(R)의 NT계의 OS로서는, 현재, "Windows(R) NT", "Windows(R) 2000", "Windows(R) XP"가 있다.
도 4는, OS(30)로서, Windows(R)의 NT계의 OS가 채용되고 있는 경우의, 드라이브(2)(의 광 디스크(3))에의 액세스에 관한 부분의 OS(30)의 구성예를 나타내고 있다.
또한, 도 4에서는, 특히, OS(30)에 있어서의 디바이스 드라이버의 레이어(layer) 구성을, 어플리케이션(31)과의 관계를 알 수 있도록 도시하고 있다.
Windows(R)의 NT계의 OS인 OS(30)는, 커널(58)에, 하드웨어에 의존하는 처리 등의 필요 최소한의 처리를 행하는 부분만을 남기고, 서비스를 분리하고, 그 분리한 서비스를, 서브 시스템에 의해서 실장하고 있다.
Win32 서브 시스템(Win32 SubSystem)(51)은, 서브 시스템중 하나로, 어플리케이션(31)에 대해서, 각종 API(함수)를 제공하고, 예를 들면, 메모리 관리, 프로세스 관리, 그래픽스 묘화 등을 행한다.
즉, Win32 서브 시스템(51)은, 어플리케이션(31)(을 실행하고 있는 프로세스 또는 쓰레드)로부터, 예를 들면, I/O(Input/Output) 관계의 API 함수가 호출되면, 그 API 함수에 따른 I/O 요구를, NT 입출력 매니저(NT I/O Manager)(52)에 출력한 다.
또한, Win32 서브 시스템(51)이 제공하는 API 함수로서는, 예를 들면, 파일의 생성을 행하는(파일을 오픈하는) CreateFile(), 파일(파일에 기록된 데이터)의 판독을 행하는 ReadFile(), 파일(파일에의 데이터)의 기입을 행하는 WriteFile(), 파일을 클로즈하는 CloseFile(), 그 밖의 각종 처리를 행하는 DeviceIoControl() 등이 있다.
NT 입출력 매니저(52)는, 레이어 구조의 디바이스 드라이버(Device Driver)에 대해서, IRP(I/O Request Packet)를 전달하기 위한 서비스를 제공한다.
여기서, IRP는, 디바이스 드라이버에 대해서 요구하는 처리의 정보를 갖는 패킷으로, IRP에는, 예를 들면, 요구의 내용을 분류하는 코드(code), 데이터(파일)의 판독(재생)을 요구하는 IRP_MJ_READ, 데이터의 기입(기록)을 요구하는 IRP_MJ_WRITE, 파일의 오픈을 요구하는 IRP_MJ_CREATE, 파일의 클로즈를 요구하는 IRP_MJ_CLOSE, 그 밖의 각종 처리를 요구하는 IRP_MJ_DEVICE_CONTROL 등이 있다. IRP_MJ_DEVICE_CONTROL의 IRP에서는, 서브 코드(sub code)로서, IOCTL(I/O Control)이 지정되지만, 이 IOCTL은, 사용자(User) 정의가 가능하게 되어 있다.
NT 입출력 매니저(52)에서는, Win32 서브 시스템(51)에 의한, 예를 들면, CreateFile()에 따른 I/O 요구는, IRP_MJ_CREATE의 IRP로 변환된다. 또, 예를 들면, ReadFile()과 WriteFile()은, 각각, IRP_MJ_READ와 IRP_MJ_WRITE의 IRP로 변환되고, DeviceIoControl()은, IRP_MJ_DEVICE_CONTROL의 IRP로 변환된다.
여기서, Windows(R)의 NT계의 OS에서는, IRP는, 스토리지 클래스 드라이버 (Storage Class Driver)의 레이어 이상의 레이어에서 사용된다.
도 4에서는, 스토리지 클래스 드라이버의 레이어 이상의 레이어의 디바이스 드라이버로서, 스토리지 클래스 드라이버인 PD 스토리지(55), 스토리지 클래스 드라이버의 1개 상위의 레이어의 파일 시스템 드라이버(FileSystem Driver)인 PD_FS(54), 및 파일 시스템 드라이버의 1개 상위의 레이어의 파일 시스템 필터 드라이버(FileSystem Filter Driver)인 FS 필터 드라이버(53)의 3개의 디바이스 드라이버가 존재한다.
따라서, 본 실시의 형태에서는, NT 입출력 매니저(52)는, 이들의 FS 필터 드라이버(53), PD_FS(54), PD 스토리지(55)에 대해서, IRP를 전달하기 위한 서비스를 제공한다.
구체적으로 설명하면, NT 입출력 매니저(52)는, Win32 서브 시스템(51)으로부터의 I/O 요구를, IRP로 변환하여, 예를 들면, FS 필터 드라이버(53)에 출력한다. 그리고, FS 필터 드라이버(53)가, NT 입출력 매니저(52)로부터의 IRP 에 따른 요구를, 예를 들면, NT 입출력 매니저(52)에 출력하고, NT 입출력 매니저(52)는, FS 필터 드라이버(53)로부터의 요구를, IRP로 변환하여, 그 1개 하위의 레이어의 PD_FS(54)에 출력한다. 또한, PD_FS(54)가, NT 입출력 매니저(52)로부터의 IRP에 따른 요구를, 예를 들면, NT 입출력 매니저(52)에 출력하고, NT 입출력 매니저(52)는, PD_FS(54)로부터의 요구를, IRP로 변환하여, 그 1개 하위의 레이어의 PD 스토리지(55)에 출력한다.
FS(FileSystem) 필터 드라이버(53)는, 후술하는 PD_FS(54)의 상위의 파일 시 스템 필터 드라이버이다. FS 필터 드라이버(53)는, 어플리케이션(31)으로부터, Win32 서브 시스템(51) 및 NT 입출력 매니저(52)를 통하여 공급되는, 파일 시스템에 관련된 파일 시스템 요구와 그 밖의 요구(request)의 필터링을 행하고, 그 필터링의 결과, PD_FS(54)에 전달할 요구를 얻어, NT 입출력 매니저(52)를 통하여, PD_FS(54)에 출력하는 등의 처리를 행한다. 또한, FS 필터 드라이버(53)로서는, 예를 들면, OS(30)로서의 Windows(R)의 NT계의 OS에 표준의 파일 시스템 필터 드라이버를 이용할 수 있다.
PD_FS(54)는, PD 드라이브인 드라이브(2)용의, 파일 관리를 행하기 위한 파일 시스템 드라이버로서, FS 필터 드라이버(53)로부터 NT 입출력 매니저(52)를 통하여 요구된 파일의 기입이나 판독 등의 요구를, NT 입출력 매니저(52)를 통하여, PD 스토리지(55)에 출력한다.
또한, 후술하는 바와 같이, 논리 블록 단위에서의 데이터의 기입 및 판독 제어, 파일의 할당 관리, 디펙트 처리, 빈 영역 관리 등의 파일 관리는, 드라이브(2)의 파일 시스템에서 행해지기 때문에, PD_FS(54)는, 이들의 파일 관리(드라이브(2)의 파일 시스템에서 행해지는 파일 관리)는 행하지 않는다. 단, 어플리케이션(31)으로부터는, 드라이브(2)의 파일 시스템에서 행해지는 파일 관리가, PD_FS(54)에서 행해지고 있는 것처럼 보인다. 따라서, PD_FS(54)는, 드라이브(2)의 파일 시스템을 위장하고 있다고 할 수 있고, 이러한 관점에서는, 위장 파일 시스템이라고 할 수 있다.
여기서, 파일 시스템 드라이버는, 일반적으로, 파일 스트림(File Stream)(파 일에 기록되는(기록된) 데이터의 파일)이나 파일 메타(File Meta) 정보의 캐쉬(Cache) 기능을 갖고, 이 캐쉬 기능에 따르면, 예를 들면, 캐쉬된 파일 스트림이나 파일 메타 정보에 대해서는, 광 디스크(3)에 실제로 액세스하지 않고, 고속으로 얻을 수 있다.
Windows(R)의 NT계의 OS에서는, NT 캐쉬 매니저(NT Cache Manager)(59)가, 캐쉬 기능을 갖고 있고, PD_FS(54)는, NT 캐쉬 매니저(59)를 이용하여, 캐쉬 기능을 제공한다.
또한, PD_FS(54)는, 파일 핸들 리소스 매니저(54A)를 갖고, 이 파일 핸들 리소스 매니저(54A)는, 후술하는 배타 제어를 행한다.
PD 스토리지(55)는, PD 드라이브인 드라이브(2)의 실제의 디바이스 드라이버에 해당하는 스토리지 클래스 드라이버로서, 상위의 레이어의 디바이스 드라이버인 PD_FS(54)로부터, NT 입출력 매니저(52)를 통하여 공급되는 요구로서의 IRP를, 예를 들면, SCSI(Small Computer System Interface) 코드(SCSI Code)로 변환하여, SBP(Serial Bus Protocol)2 드라이버(56)에 출력한다.
여기서, PD 스토리지(55)에 있어서, IRP를 SCSI 코드로 변환하는 것은, SCSI 코드가, 후단의 SBP2 드라이버(56)에서 취급되는 SBP2와, 말하자면 친화성이 좋기 때문이다.
SBP2 드라이버(56)는, PD 스토리지(55)로부터의 SCSI 코드를, SBP2에 준거한 데이터인 SBP2 데이터로 변환하여(SBP2 프로토콜로 변환하여), 1394 버스 드라이버(IEEE1394 bus Driver)(57)에 공급한다.
여기서, 본 실시의 형태에서는, SBP2 드라이버(56)의 후단의 1394 버스 드라이버(57)에 의해 제어되는 IEEE1394의 규격에 준거한 통신에 있어서 파일 시스템을 취급할 수 있는 프로토콜로서, SBP2를 채용하고 있지만, SBP2 이외의 프로토콜을 채용하는 것도 가능하다.
1394 버스 드라이버(57)는, IEEE1394 I/F(22)(도 2)를 제어하는 것에 의해, SBP2 드라이버(56)로부터의 SBP2 데이터 등을, 드라이브(2)에 송신하고, 또, 드라이브(2)로부터 송신되어 오는, 광 디스크(3)로부터 판독된 데이터를 수신한다.
여기서, 본 실시의 형태에서는, PC(1)와 드라이브(2) 사이에서, IEEE1394의 규격에 준거한 통신을 행하는 것으로 하고 있지만, PC(1)와 드라이브(2) 사이에서는, 그 이외의 통신을 행하는 것이 가능하다. 이 경우, 1394 버스 드라이버(57) 대신에, PC(1)와 드라이브(2) 사이의 통신에 대응한 버스 드라이버가 이용된다.
또한, AV 어플리케이션인 어플리케이션(31)은, PD 드라이브인 드라이브(2)를 사용하는 데 필요한 PD_FS(54), 및 PD 스토리지(55)와 함께, 예를 들면, 리무버블 기록 매체(21)(도 2)에 기록해서 판매할 수 있다. 또, 어플리케이션(31), PD_FS(54), 및 PD 스토리지(55)가 기록된 리무버블 기록 매체(21)는, 단체(單體)로 판매하는 것 외에, 예를 들면, 드라이브(2)에 포함시켜, 드라이브(2)의 부속품으로서 판매할 수 있다.
여기서, 도 4에 있어서, 어플리케이션(31)과, Win32 서브 시스템(51)은, 사용자 모드(User Mode)에서 동작하고, NT 입출력 매니저(52), FS 필터 드라이버(53), PD_FS(54), PD 스토리지(55), SBP2 드라이버(56), 1394 버스 드라이버(57), 커널(58) 및 NT 캐쉬 매니저(59)는, 커널 모드(Kernel Mode)에서 동작한다.
또한, 도 4에서는, NT 입출력 매니저(52)가, IRP를, 파일 시스템 필터 드라이버인 FS 필터 드라이버(53)나, 파일 시스템 드라이버인 PD_FS(54)를 전달하는 것에 의해서, 파일 시스템 필터 드라이버나 파일 시스템 드라이버에 대해서, 처리의 요구를 행하는 것으로 했지만, Windows(R)의 NT계의 OS의 NT 입출력 매니저(52)는, IRP 이외에, FastIO를, 파일 시스템 필터 드라이버나 파일 시스템 드라이버에 전달하는 것에 의해, 처리의 요구를 행하는 것이 가능하다.
즉, NT 입출력 매니저(52)는, 파일 시스템 필터 드라이버나 파일 시스템 드라이버에 대해서, IRP 이외에, FastIO를 전달하기 위한 서비스도 제공하고, 이것에 의해, 파일 시스템 필터 드라이버나 파일 시스템 드라이버에 대해서, 처리의 요구를 행한다.
따라서, Windows(R)의 NT계의 OS의 파일 시스템 필터 드라이버나 파일 시스템 드라이버는, 일반적으로, IRP와 FastIO의 양쪽을 서포트한다.
단, FastIO에 의하면, 예를 들어, 파일의 판독(Read)이나 기입(Write)이, NT 캐쉬 매니저(59)에 대해서 즉시 행해진다.
또한, 이하에서는, IRP와 FastIO 중의, 예를 들면, IRP를 이용하는 것으로 한다. 단, 이하, 설명하는 기능은, FastIO에 의해서도 실현할 수 있다.
다음으로, 도 5의 플로우차트를 참조하여, 어플리케이션(31)으로부터 광 디스크(3)에 대한 액세스가 요구되었을 때에 도 4의 OS(30)에서 행해지는 FS 필터 드라이버(53), PD_FS(54), PD 스토리지(55), SBP2 드라이버(56), 1394 버스 드라이버 (57)의 처리의 개요에 대해서 설명한다.
또한, 이하의 설명과 도 5 이후의 도면에 있어서는, 각각, Win32 서브 시스템(51) 및 NT 입출력 매니저(52)의 설명과 도시를, 적절하게 생략한다.
어플리케이션(31)이, 예를 들면, 광 디스크(3)에 대한 액세스를 요구하는 API 함수를 호출하면, 그 API 함수에 따른 요구가, Win32 서브 시스템(51)으로부터 NT 입출력 매니저(52)에 공급되고, NT 입출력 매니저(52)는, Win32 서브 시스템(51)으로부터의 요구에 따른 IRP가, FS 필터 드라이버(53)에 공급된다.
FS 필터 드라이버(53)는, 단계 S1에 있어서, NT 입출력 매니저(52)로부터의 IRP를 수신하고, 단계 S2로 진행한다. FS 필터 드라이버(53)는, 단계 S2에 있어서, NT 입출력 매니저(52)로부터의 IRP를 필터링하고, 단계 S3으로 진행하여, PD_FS(54)에 공급할 IRP를 큐잉한다. 즉, FS 필터 드라이버(53)는, 도시하지 않은 큐에, NT 입출력 매니저(52)로부터의 IRP를 공급하고 기억시킨다.
또한, FS 필터 드라이버(53)는, 큐에 기억된 IRP를 판독하여, NT 입출력 매니저(52)를 통하여, PD_FS(54)에 공급하고, 단계 S4로 진행한다.
또한, FS 필터 드라이버(53) 내의 처리는, 필터의 성질에 따라서 다르기 때문에, 여기서는 그 일례를 나타내고 있고, 이것에 한정되는 것은 아니다.
단계 S4에서는, PD_FS(54)는, FS 필터 드라이버(53)로부터의 IRP에 의해서 요구되고 있는 데이터에 대해서, NT 캐쉬 매니저(59)의 캐쉬 기능을 이용하는 데 필요한 처리로서의 캐쉬 처리를 행하고, 단계 S5로 진행하여, 예를 들면, FS 필터 드라이버(53)로부터의 IRP에 의해서 요구되고 있는 데이터가, NT 캐쉬 매니저(59) 에 캐쉬되어 있는지의 여부를 판정한다.
단계 S5에 있어서, FS 필터 드라이버(53)로부터의 IRP에 의해서 요구되고 있는 데이터가, NT 캐쉬 매니저(59)에 캐쉬되어 있다고 판정된 경우, 단계 S6으로 진행하고, PD_FS(54)는, FS 필터 드라이버(53)로부터의 IRP에 의해서 요구되고 있는 데이터를, NT 캐쉬 매니저(59)로부터 수신하는 등을 행하여, 그 IRP에 대한 응답을, FS 필터 드라이버(53) 및 Win32 서브 시스템을 통하여, 그 IRP에 대응하는 API 함수를 호출한 어플리케이션(31)에 회신한다.
한편, 단계 S5에 있어서, FS 필터 드라이버(53)로부터의 IRP에 의해서 요구되고 있는 데이터가, NT 캐쉬 매니저(59)에 캐쉬되어 있지 않다고 판정된 경우, 단계 S7로 진행하여, PD_FS(54)는, FS 필터 드라이버(53)로부터의 IRP를, 후술하는 바와 같이 커맨드 변환하여, NT 입출력 매니저(52)를 통하여, PD 스토리지(55)에 공급하고, 단계 S8로 진행한다.
단계 S8에서는, PD 스토리지(55)는, PD_FS(54)으로부터의 IRP를, 대응하는 SCSI 코드로 변환하여, SBP2 드라이버(56)에 공급하고, 단계 S9로 진행한다. 단계 S9에서는, SBP2 드라이버(56)는, PD 스토리지(55)로부터의 SCSI 코드를, SBP2 데이터로 변환하여, 1394 버스 드라이버(57)에 공급하고, 단계 S10으로 진행한다.
단계 S10에서는, 1394 버스 드라이버(57)는, IEEE1394 I/F(22)(도 2)를 제어하는 것에 의해, SBP2 드라이버(56)로부터의 SBP2 데이터를, 드라이브(2)에 송신한다.
그리고, 1394 버스 드라이버(57)는, 드라이브(2)로부터, 단계 S10에서 송신 한 SBP2 데이터에 대한 응답이 송신되어 오는 것을 대기하고, 단계 S11에 있어서, 그 응답을 수신하여, SBP2 드라이버(56), PD 스토리지(55), PD_FS(54), FS 필터 드라이버(53), 및 Win32 서브 시스템(51)을 통하여, 단계 S1에서 수신된 IRP를 송신해 온 어플리케이션(31)으로 회신한다.
다음으로, 도 6을 참조하여, 드라이브(2)가 내부에 갖는 전용의 파일 시스템과, 드라이브(2)에서 채용되고 있는 프로토콜에 대해서 설명한다.
드라이브(2)는, 상술한 바와 같이, 고 비트 레이트의 AV 데이터의 리얼타임에서의 기록 또는 재생이 가능한 PD 드라이브이며, 전용의 파일 시스템으로서, 실제 파일 시스템(61)과 가상 파일 시스템(62)을 갖는다. 또한, 드라이브(2)는, 기록만, 또는 재생만 행하는 드라이브라도 되지만, 여기서는, 기록과 재생의 양쪽이 가능한 드라이브인 것으로 한다.
실제 파일 시스템(61)은, 광 디스크(3) 상의 실제 파일을, 예를 들면 UDF에 따라서 관리하고, 광 디스크(3)에 대한, 논리 블록 단위에서의 데이터의 기입 및 판독을 제어한다. 또, 실제 파일 시스템(61)은, 상술한 PD 파일 할당 매니저(도시 생략)를 갖고 있고, PD 파일 할당 매니저는, 일필 기입 기록의 제어나, 광 디스크(3) 상의 파일의 할당 관리, 디펙트 처리, 빈 영역 관리 등을 행한다.
가상 파일 시스템(62)은, 실제 파일 시스템(61)의 실제 파일을 필터링하는 등의 처리를 행하여, 그 결과 얻어지는, 후술하는 파일(가상 파일)을, 드라이브(2)의 외부에 제공한다. 따라서, 드라이브(2)의 외부에는, 가상 파일 시스템(62)이 제공된다. 이 때문에, 드라이브(2)는, 실제 파일 시스템(61)에서 관리되는 실제 파일을, 가상 파일 시스템(62)에서 관리되는 가상 파일로서 외부에 제공할 수 있는 프로토콜에 의한 통신 기능을 갖고 있다.
여기서, 드라이브(2)에 있어서는, AV 데이터나, 텍스트 데이터, 그 밖의 임의의 데이터를, 가상 파일 시스템(62)을 통하여 기입 및 판독할 수 있다.
드라이브(2)에서는, 가상 파일 시스템(62)(에서 관리되는 가상 파일)을 외부에 제공할 수 있는 프로토콜로서, 예를 들면, IEEE1394 통신(IEEE1394의 규격에 준거한 통신)에 있어서 주변 장치를 제어할 수 있는 프로토콜인 SBP2(IEEE1394 SBP2 Protocol)를 커맨드 확장한 프로토콜이 채용되고 있다.
현재, 이 SBP2를 커맨드 확장한 프로토콜을, PD-SBP2라는 것으로 하면, PD-SBP2는, PC(1) 상의 어플리케이션의 레이어의 어플리케이션(31) 등이 파일에 액세스할 때에 OS(30)의 Win32 서브 시스템(51)(도 4)이 제공하는 인터페이스(API)와 마찬가지의 기능을 제공한다. 따라서, PD-SBP2에 의하면, 예를 들면, 파일명을 지정하고, 그 파일명의 파일에 대해서, 파일 스트림의 기입 및 판독(Read/Write)을 행할 수 있고, 또, 파일의 메타 정보를, 그 파일의 파일명 및 경로명을 바탕으로 취득할 수 있다.
PD-SBP2는, 상술한 바와 같이, IEEE1394 통신에서 이용되는 SBP2(IEEE1394 SBP2 Protocol)를 커맨드 확장한 프로토콜이기 때문에, 그러한 프로토콜을 채용하는 드라이브(2)는, PC(1)측에 있어서 IEEE1394 통신을 제어하는 1394 버스 드라이버(57)에 접속되고, 또한, 1394 버스 드라이버(57)는, SBP2을 실장하는 SBP2 드라이버(56)에 접속된다.
또한, OS(30)가 Windows(R)의 NT계의 OS인 경우에는, SBP2 드라이버(56)와 1394 버스 드라이버(57)로서는, 모두 그 OS에 부속된 것을 사용할 수 있다.
다음으로, 도 7을 참조하여, 도 6의 가상 파일 시스템(62)의 처리에 대해서 설명한다.
도 7의 우측은, 실제 파일 시스템(61)에 의해 관리되고 있는 실제 파일을 나타내고 있고, 도 7의 좌측은, 가상 파일 시스템(62)으로부터 드라이브(2)의 외부에 제공되는 가상 파일을 나타내고 있다.
우선, 도 7의 우측의 실제 파일 시스템(62)의 실제 파일에 대해서 설명한다.
또한, 이하에 있어서, 「디렉토리」 후에 이어지는 영문자 등은, 그 디렉토리의 디렉토리명을 나타낸다. 마찬가지로, 「파일」 후에 이어지는 영문자 등은, 그 파일의 파일명을 나타낸다. 또한, 파일명 중의, 피리어드(.)에 이어지는 영문자 등은, 파일의 확장자이다. 예를 들면, 확장자 "XML"은, XML(eXtensible Markup Language)의 파일인 것을 나타낸다. 또, 예를 들면, 확장자 "MXF"는, MXF의 파일인 것을 나타낸다.
루트 디렉토리 ROOT에는, 비디오 데이터나 오디오 데이터 등의 소재 데이터에 관한 정보나, 소재 데이터의 편집 결과를 나타내는 에디트 리스트 등이 저장되는 디렉토리, 그 밖의 AV 데이터에 관련된 파일(디렉토리)이 배치되는 디렉토리 PROAV와, AV 데이터에 관련된 파일 이외의 임의의 데이터의 파일인, 예를 들면, 파일 Document.txt나, Infomation.doc, EditData.xls가 저장되는 제너럴 디렉토리 General이 배치되어 있다.
또한, 여기서는, AV 데이터에 관련된 파일로서, 예를 들면, MXF의 파일(MXF File)을 채용하는 것으로 한다. 또, 실제 파일 시스템(61)에 의해 관리되고 있는 실제 파일로서의 MXF의 파일은, 예를 들면, 비디오 데이터와 오디오 데이터가 별도의 파일로 되는 MXF OP-Atom의 파일인 것으로 하고, 가상 파일 시스템(62)에 의해 관리되고, 외부에 제공되는 가상 파일은, 예를 들면, 비디오 데이터와 오디오 데이터가 인터리브되어 1개의 파일로 되는 MXF OP-1a의 파일인 것으로 한다.
디렉토리 PROAV에는, 인덱스 파일 INDEX.XML 및 INDEX.BUP, 디스크 인포메이션 파일 DISCINFO.XML 및 DISKINFO.BUP와 디스크 메타 파일 DISCMETA.XML이 배치되어 있다.
인덱스 파일 INDEX.XML 및 INDEX.BUP는, 광 디스크(3)에 기록되어 있는 모든 클립 및 에디트 리스트를 관리하기 위한 관리 정보 등을 포함한다.
또한, 클립은, 예를 들면, 1회의 기록으로 광 디스크(3)에 기록된 비디오 데이터 등의 통합된 비디오 데이터와, 그 비디오 데이터에 대응하는 오디오 데이터의 세트이다. 또, 에디트 리스트는, 소위 비선형 편집이 행해졌을 때의 편집 수순의 리스트로서, 예를 들면, 비선형 편집에 있어서, 어떤 파일의 AV 데이터가 컷트 편집된 경우에는, 그 파일을 특정하는 정보로서의 파일명이나, 인 점 및 아웃 점 등의 정보가, 에디트 리스트에 기록된다.
디스크 인포메이션 파일 DISCINFO.XML 및 DISKINFO.BUP는, 광 디스크(3)에 기록되어 있는 데이터 전체에 대한 메타 데이터이고, 예를 들면, 디스크 속성이나, 재생 개시 위치 등의 정보를 포함하는 파일이다.
또한, 디스크 인포메이션 파일 DISKINFO.BUP는, 디스크 인포메이션 파일 DISCINFO.XML의 백업 파일(카피)이다. 마찬가지로, 상술한 인덱스 파일 INDEX.BUP도, 인덱스 파일 INDEX.XML의 백업 파일이다.
디스크 메타 파일 DISCMETA.XML은, 광 디스크(3)에 기록되어 있는 모든 소재 데이터에 대한 타이틀이나 코멘트, 또, 광 디스크(3)에 기록되어 있는 모든 비디오 데이터의 대표로 되는 프레임인 대표 화상에 대응하는 비디오 데이터의 경로 등의 정보를 포함하는 파일이다.
또, 디렉토리 PROAV에는, 상술한 파일 이외에, 클립의 데이터가 하위의 디렉토리에 배치되는 클립 루트 디렉토리 CLPR, 에디트 리스트의 데이터가 하위의 디렉토리에 배치되는 에디트 리스트 루트 디렉토리 EDTR이 배치되어 있다.
클립 루트 디렉토리 CLPR에는, 광 디스크(3)에 기록되어 있는 클립의 데이터가, 클립마다 서로 다른 디렉토리로 나누어 관리되고 있고, 예를 들면, 도 7의 우측에서는, 3개의 클립의 데이터가, 클립 디렉토리 C0001, C0002, C0003의 3개의 디렉토리로 나뉘어 관리되고 있다.
즉, 광 디스크(3)에 기록된 최초의 클립 #1의 각 데이터는, 클립 디렉토리 C0001의 파일로서 관리되고, 2번째로 광 디스크(3)에 기록된 클립 #2의 각 데이터는, 클립 디렉토리 C0002의 파일로서 관리되고, 3번째로 광 디스크(3)에 기록된 클립 #3의 각 데이터는, 클립 디렉토리 C0003의 파일로서 관리되고 있다.
클립 디렉토리 C0001에는, 최초로 광 디스크(3)에 기록된 클립 #1의 각 데이터의 파일이 배치되어 있다.
도 7의 우측에서는, 클립 디렉토리 C0001에는, 클립 #1을 관리하는 파일인 클립 인포메이션 파일 C0001C01.SMI, 클립 #1의 비디오 데이터를 포함하는 파일인 비디오 데이터 파일 C0001V01.MXF, 클립 #1의 8채널의 오디오 데이터 각각의 파일인 8개의 오디오 데이터 파일 C0001A01.MXF 내지 C0001A08.MXF, 클립 #1의 저 비트 레이트의 비디오 데이터를 포함하는 파일인 저 해상도 데이터 파일 C0001S01.MXF, 클립 #1의 소재 데이터에 대응하는, 예를 들면, LTC(Longitudinal Time Code)와 프레임 번호를 대응시키는 변환 테이블 등의, 리얼타임성을 요구받지 않는 메타 데이터인 클립 메타 데이터를 포함하는 파일인 클립 메타 데이터 파일 C0001M01.XML, 및 클립 #1의 소재 데이터에 대응하는, 예를 들면 LTC 등의, 리얼타임성을 요구받는 메타 데이터인 프레임 메타 데이터를 포함하는 파일인 프레임 메타 데이터 파일 C0001R01.BIM이 배치되어 있다.
또한, 도 7의 우측의 다른 클립 디렉토리 C0002와 C0003에도, 클립 #2와 #3에 대해서, 각각 클립 디렉토리 C0001과 마찬가지의 파일이 배치되어 있다.
디렉토리 PROAV 하의 에디트 리스트 루트 디렉토리 EDTR에는, 광 디스크(3)에 기록되어 있는 에디트 리스트가, 그 편집 처리마다 서로 다른 디렉토리로 나누어 관리되고 있고, 도 7의 우측에서는, 4개의 에디트 리스트가, 에디트 리스트 디렉토리 E0001, E0002, E0003 및 E0004의 4개의 디렉토리로 나누어 관리되고 있다. 즉, 광 디스크(3)에 기록된 클립의 1회째의 편집 결과를 나타내는 에디트 리스트 #1은, 에디트 리스트 디렉토리 E0001의 파일로서 관리되고, 2회째의 편집 결과를 나타내는 에디트 리스트 #2는, 에디트 리스트 디렉토리 E0002의 파일로서 관리되 고, 3회째의 편집 결과를 나타내는 에디트 리스트 #3는, 에디트 리스트 디렉토리 E0003의 파일로서 관리되고, 4회째의 편집 결과를 나타내는 에디트 리스트 #4는, 에디트 리스트 디렉토리 E0004의 디렉토리의 파일로서 관리되고 있다.
도 7의 우측에서는, 에디트 리스트 디렉토리 E0001에는, 에디트 리스트 #1의 파일인 에디트 리스트 파일 E0001E01.SMI와, 에디트 리스트 #1에 따른 편집의 편집 후의 소재 데이터(편집에 이용된 전체 클립의 소재 데이터 중, 편집후의 데이터로서 추출된 부분)에 대응하는 클립 메타 데이터, 또는, 그 클립 메타 데이터에 기초하여 새롭게 생성된 클립 메타 데이터를 포함하는 파일인 에디트 리스트용 클립 메타 데이터 파일 E0001M01.XML이 배치되어 있다.
여기서, 에디트 리스트용 클립 메타 데이터 파일 E0001M01.XML은, 편집에 사용된 클립의 클립 메타 데이터(클립 루트 디렉토리 CLPR의 하위의 디렉토리에 존재하는 클립 메타 데이터 파일(도 7의 우측에서는, 예를 들면, 디렉토리 C0001의 클립 메타 데이터 파일 C0001M01.XML))에 기초하여 생성된 새로운 클립 메타 데이터를 포함하는 파일이다. 예를 들면, 클립 #1을 대상으로 한 편집이 행해지면, 클립 메타 데이터 파일 C0001M01.XML에 포함되는 클립 메타 데이터로부터, 편집 후의 소재 데이터에 대응하는 부분이 추출되고, 이들을 이용하여, 편집 후의 소재 데이터를 1클립으로 하는 새로운 클립 메타 데이터가 재구성되어, 에디트 리스트용 클립 메타 데이터 파일로서 관리된다. 즉, 편집 후의 소재 데이터에는, 편집 후의 소재 데이터를 1클립으로 하는 새로운 클립 메타 데이터가 부가되고, 그 클립 메타 데이터가 1개의 에디트 리스트용 클립 메타 데이터 파일로서 관리된다. 따라서, 에디 트 리스트용 클립 메타 데이터 파일은, 편집마다 생성된다.
또한, 도 7의 우측의 다른 에디트 리스트 디렉토리 E0002 내지 E0004에도, 에디트 리스트 #2 내지 #4에 대해서, 각각 에디트 리스트 디렉토리 E0001과 마찬가지의 파일이 배치되어 있다.
이상과 같은 도 7의 우측에 도시한, 실제 파일 시스템(61)에 의해 관리되고 있는 실제 파일은, 가상 파일 시스템(62)에 있어서, 도 7의 좌측에 도시하는 형태로, 드라이브(2)의 외부에 제공된다.
즉, 가상 파일 시스템(62)에서는, 루트 디렉토리 ROOT에는, 인덱스 파일 INDEX.XML과 디스크 메타 파일 DISCMETA.XML이 배치됨과 함께, 디렉토리 Clip, Edit, Sub, 및 General이 배치된다.
가상 파일 시스템(62)에 있어서, 루트 디렉토리 ROOT에 배치되는 인덱스 파일 INDEX.XML과 디스크 메타 파일 DISCMETA.XML은, 각각 실제 파일 시스템(61)에서 관리되고 있는 디렉토리 PROAV의 인덱스 파일 INDEX.XML과 디스크 메타 파일 DISCMETA.XML이다.
또, 가상 파일 시스템(62)에서는, 디렉토리 Clip에, 실제 파일 시스템(61)에서 관리되고 있는 디렉토리 CLPR의 하위 디렉토리에 있는 클립의 데이터의 파일이 배치된다.
즉, 도 7의 좌측에서는, 디렉토리 Clip에, 도 7의 우측의 디렉토리 C0001, C0002, C0003에 있는 클립의 데이터의 파일로서, 각각 파일 C0001.MXF, C0002.MXF, C0003.MXF가 배치되어 있다.
여기서, 실제 파일 시스템(61)에서는, 클립의 데이터는, 상술한 바와 같이, 비디오 데이터와 오디오 데이터가 별도의 파일인 MXF OP-Atom의 파일로 된다.
즉, 도 7의 우측의 디렉토리 C0001에서는(디렉토리 C0002, C0003에 대해서도 마찬가지), 클립 #1의 데이터가, 그 클립 #1의 비디오 데이터를 포함하는 비디오 데이터 파일 C0001V01.MXF와, 클립 #1의 8채널의 오디오 데이터 각각의 오디오 데이터 파일 C0001A01.MXF 내지 C0001A08.MXF로 나뉘어져 있다.
한편, 가상 파일 시스템(62)에서는, 클립의 데이터는, 상술한 바와 같이, 비디오 데이터와 오디오 데이터가 인터리브되어 1개의 파일로 되어 있는 MXF OP-1a의 파일로 된다.
도 7의 좌측의 디렉토리 Clip에 있는 파일 C0001.MXF는, 도 7의 우측의 디렉토리 C0001에 있는 클립 #1의 비디오 데이터와 오디오 데이터가 인터리브된 1개의 파일이다.
즉, 파일 C0001.MXF는, 디렉토리 C0001의 비디오 데이터 파일 C0001V01.MXF의 비디오 데이터와, 오디오 데이터 파일 C0001A01.MXF 내지 C0001A08.MXF 각각의 8채널의 오디오 데이터를 인터리브하여 배치한 파일이다.
마찬가지로, 디렉토리 Clip에 있는 파일 C0002.MXF는, 디렉토리 C0002에 있는 클립 #2의 비디오 데이터와 오디오 데이터가 인터리브된 1개의 파일이고, 파일 C0003.MXF는, 디렉토리 C0003에 있는 클립 #3의 비디오 데이터와 오디오 데이터가 인터리브된 1개의 파일이다.
도 7의 좌측의 디렉토리 Clip에는, 또, 각 클립의 클립 메타 데이터 파일도 배치된다.
여기서, 도 7의 좌측의 디렉토리 Clip에는, 클립 메타 데이터 파일 C0001M01.XML, C0002M01.XML, C0003M01.XML이 배치되어 있다. 디렉토리 Clip의 클립 메타 데이터 파일 C0001M01.XML은, 클립 #1의 클립 메타 데이터 파일로서, 도 7의 우측의 디렉토리 C0001에 있는 클립 메타 데이터 파일 C0001M01.XML이다.
마찬가지로, 디렉토리 Clip의 클립 메타 데이터 파일 C0002M01.XML은, 클립 #2의 클립 메타 데이터 파일로서, 도 7의 우측의 디렉토리 C0002에 있는 클립 메타 데이터 파일이다. 또한, 마찬가지로, 디렉토리 Clip의 클립 메타 데이터 파일 C0003M01.XML은, 클립 #3의 클립 메타 데이터 파일로서, 도 7의 우측의 디렉토리 C0003에 있는 클립 메타 데이터 파일이다.
도 7의 좌측의 루트 디렉토리 ROOT 중의 디렉토리 Edit에는, 도 7의 우측의 디렉토리 EDTR의 하위 디렉토리에 있는 파일이 배치된다.
여기서, 디렉토리 Edit에는, 파일 E0001E01.SMI와 E0001M01.XML, 파일 E0002E01.SMI와 E0002M01.XML, 파일 E0003E01.SMI와 E0003M01.XML, 및 파일 E0004E01.SMI와 E0004M01.XML이 배치되어 있다.
도 7의 좌측의 디렉토리 Edit 중의 파일 E0001E01.SMI와 E0001M01.XML은, 각각 도 7의 우측의 에디트 리스트 #1의 디렉토리 E0001 중의 파일 E0001E01.SMI와 E0001M01.XML이다.
마찬가지로, 디렉토리 Edit 중의 파일 E0002E01.SMI와 E0002M01.XML은, 에디트 리스트 #2의 디렉토리 E0002 중의 파일이고, 디렉토리 Edit 중의 파일 E0003E01.SMI와 E0003M01.XML은, 에디트 리스트 #3의 디렉토리 E0003 중의 파일이고, 디렉토리 Edit 중의 파일 E0004E01.SMI와 E0004M01.XML은, 에디트 리스트 #4의 디렉토리 E0004의 중의 파일이다.
도 7의 좌측의 디렉토리 Sub에는, 각 클립의 저해상도 데이터 파일이 배치된다.
여기서, 도 7의 좌측의 디렉토리 Sub에는, 저해상도 데이터 파일 C0001S01.MXF, C0002S01.MXF, C0003S01.MXF가 배치되어 있다. 디렉토리 Sub의 저해상도 데이터 파일 C0001S01.MXF는, 클립 #1의 저해상도 데이터 파일로서, 도 7의 우측의 디렉토리 C0001에 있는 저해상도 데이터 파일 C0001S01.MXF이다.
마찬가지로, 디렉토리 Sub의 저해상도 데이터 파일 C0002S01.MXF는, 클립 #2의 저해상도 데이터 파일로서, 도 7의 우측의 디렉토리 C0002에 있는 저해상도 데이터 파일이다. 또한, 마찬가지로, 디렉토리 Sub의 저해상도 데이터 파일 C0003S01.MXF는, 클립 #3의 저해상도 데이터 파일로서, 도 7의 우측의 디렉토리 C0003에 있는 저해상도 데이터 파일이다.
도 7의 좌측의 디렉토리 General에는, 도 7의 우측의 디렉토리 GeneralSub에 있는 파일 Document.txt, Infomation.doc, EditData.xls가 배치된다.
가상 파일 시스템(62)(도 6)은, 실제 파일 시스템(61)에서 관리되고 있는 별도의 파일의 클립의 비디오 데이터와 오디오 데이터를, 1개의 파일(가상 파일)로 하여, 외부에 제공한다.
또한, 가상 파일 시스템(62)은, 실제 파일 시스템(61)에서 관리되고 있는 파 일 중의, 드라이브(2)의 내부에서만 사용하는 파일 등의, 외부(어플리케이션, 혹은 사용자 등)에 제공할 필요가 없는 파일을 필터링하여, 그러한 파일을, 외부에 보이지 않게 되어 있다.
여기서, 도 7에서는, 가상 파일 시스템(62)의 필터링에 의해서, 백업의 파일 INDEX.BUP 및 DISCINFO.BUP나, 디스크 인포메이션 파일 DISCINFO.XML, 클립 인포메이션 파일 C0001C01.SMI, 프레임 메타 데이터 파일 C0001R01.BIM 등이, 외부에서 보이지 않게 되어 있다.
이상과 같이, 가상 파일 시스템(62)에 의하면, 실제 파일 시스템(61)에서 관리되고, 별도의 파일로 되어 있는 비디오 데이터와 오디오 데이터의 MXF OP-Atom의 파일이, 비디오 데이터와 오디오 데이터가 인터리브되어 1개의 파일로 되어 있는 MXF OP-1a의 파일로서, 외부에 제공되므로, 사용자나 어플리케이션(31)에 있어서의 취급이 용이하게 된다.
즉, 실제 파일 시스템(61)에서 관리되고, 별도의 파일로 되어 있는 비디오 데이터와 오디오 데이터의 MXF OP-Atom의 파일이, 외부에 제공되는 경우, 예를 들면, 사용자가, 예를 들면, 클립 #1을 재생 대상으로서 지정하여, 어플리케이션(31)에 재생시키기 위해서는, 사용자는, 예를 들면, 클립 #1의 비디오 데이터의 파일 C0001V01.MXF와, 클립 #1의 오디오 데이터의 8채널분의 파일 C0001A01.MXF 내지 C0001A08.MXF를 지정해야 한다. 또한, 어플리케이션(31)은, 사용자에 의해서 지정된 파일 C0001V01.MXF와 파일 C0001A01.MXF 내지 C0001A08.MXF의 합계 9개의 파일을 오픈하고, 그 파일 핸들을 취득하여, 비디오 데이터나 오디오 데이터의 판독을 행해야 한다.
이에 반해, 가상 파일 시스템(62)에 의하면, 클립 #1의 파일 C0001V01.MXF의 비디오 데이터와, 클립 #1의 파일 C0001A01.MXF 내지 C0001A08.MXF의 8채널분의 오디오 데이터가, 1개의 파일 C0001.MXF로서 제공되므로, 사용자는, 재생 대상으로서, 1개의 파일 C0001.MXF를 지정하면 되고, 또한, 어플리케이션은, 그 파일 C0001.MXF의 파일 핸들을 취득하여, 데이터의 판독을 행하는 것만으로 된다.
또한, 가상 파일 시스템(62)에 의하면, 실제 파일 시스템(61)에서 관리되고 있는 파일을 대상으로 해서, 필터링이 행해지므로, 예를 들면, 디스크 인포메이션 파일 DISCINFO.XML 등의, 드라이브(2)의 내부에서만 사용하는 파일 등이, 외부로부터, 말하자면 은폐된다.
따라서, 드라이브(2)의 내부에서만 사용하는 파일 등이, 사용자의 오조작 등에 의해서 삭제되거나, 또는 재기입되는 것을 방지할 수 있다. 또한, 사용자에게 필요 없는 파일이 보이는 것에 의해, 사용자가 필요한 파일을 찾을 때의 방해로 되는 것을 방지할 수 있다.
다음으로, 드라이브(2)에서는, 도 6에서 설명한 바와 같이, IEEE1394 통신에서 이용되는 SBP2(IEEE1394 SBP2 Protocol)를 커맨드 확장한 프로토콜인 PD-SBP2를, 가상 파일 시스템(62)을 외부에 제공하기 위한 프로토콜로서 채용한다.
여기서, SBP2에서는, 이니시에이터(Initiator)라고 불리는 장치가, 타깃(Target)이라고 불리는 장치에 대해서, 커맨드를 송신하고, 타깃이, 이니시에이터로부터의 커맨드에 대해서, 응답을 회신한다.
도 8은, 이니시에이터로부터 타깃에 대해서 커맨드를 송신할 때의 SBP2 데이터인 SCSI command block ORB(Operation Request Blocks)의 포맷을 나타내고 있다. 또한, SBP2에 있어서, SCSI command block ORB는, 데이터 전송이나 디바이스 제어에 사용된다.
도 8에 있어서, next_ORB 필드에는, 다음의 ORB의 어드레스(address), 또는 NULL이 세트된다.
data_descriptor 필드는, data_size 필드가 0 이외일 때 유효하고, 데이터 버퍼(data buffer)의 어드레스, 또는 페이지 테이블(pate table)의 어드레스가 세트된다.
n(notify bit) 필드에는, 타깃에 의한 완료의 통지가 필요한지의 여부의 정보가 세트된다.
rq_fmt 필드에는, ORB 포맷(format)의 정보가 세트된다.
r(reserved) 필드는, 소위 예약 영역이다.
d(direction bit) 필드에는, 데이터(Data) 전송의 방향이 세트된다. 즉, d 필드가 0인 경우에는, 타깃으로부터의 데이터의 판독(target read transactions)을 표시하고, d 필드가 1인 경우에는, 타깃에의 데이터의 기입(target write transactions)을 표시한다.
spd(speed) 필드에는, 타깃의 데이터 전송 처리 스피드(Speed)가 세트된다.
max_payload 필드에는, 최대 데이터 전송량(length)이 세트된다. 또한, 최대 데이터 전송량은, 2의 (max_payload+2)승으로 된다.
p(page_table_present bit) 필드에는, 0 또는 1이 세트된다. 즉, data_descriptor 필드에 있어서, 데이터 버퍼의 어드레스가 세트되어 있는 경우에는, p 필드에 0이 세트된다. 또, data_descriptor 필드에 있어서, 페이지 테이블의 어드레스가 세트되어 있는 경우에는, p 필드에 1이 세트된다.
page_size 필드에는, p 필드가 1인 경우에, 데이터 버퍼로서의 메모리(memory)의 페이지 사이즈(page size)가 세트된다. 또한, 페이지 사이즈는, 2의 (page_size+8)승으로 된다.
data_size 필드에는, p 필드가 0인 경우에, 데이터 버퍼의 사이즈(size)가 세트된다.
cdb(SCSI command descriptor blocks) 필드, 즉, 12의 cdb[0] 내지 cdb[11] 필드에는, SCSI 커맨드(코드)(SCSI command)가 세트된다.
SBP2에서는, CDB[0] 필드에 세트할 수 있는 값 중의, C0h 내지 FFh(h는, 그 앞의 영숫자가 16진수인 것을 나타냄)가, 벤더 스페시픽(Vender Specific) 에리어로 되어 있다.
따라서, PD-SBP2에서는, 벤더 스페시픽 에리어의 값을 이용하여, 커맨드 확장(새로운 커맨드의 정의)이 되어 있다.
즉, PD-SBP2에서는, CDB[0] 필드에, 확장 커맨드(의 오퍼레이션 코드)가 세트된다. 또, PD-SBP2에서는, CDB[1] 내지 CDB[11] 필드에, 커맨드(확장 커맨드)의 인수(오퍼랜드)가 필요에 따라 세트된다.
다음으로, 도 9는, 타깃이, 이니시에이터로부터의 커맨드에 대해서 회신하는 응답으로서의 SBP2 데이터인 SBP2 스테이터스 블록(SBP2 status block)의 포맷을 나타내고 있다. 또한, SBP2에 있어서, SBP2 스테이터스 블록은, SCSI sense data를 위한 스테이터스 블록으로, 타깃이 요구의 완료나, 스테이터스(status)의 변화를 회신할 때에 사용된다.
도 9에 있어서, src 필드에는, SBP2 스테이터스 블록의 origin을 나타내는 플래그(flag)가 세트된다.
resp(respose status) 필드에는, 응답 상태를 나타내는 정보가 세트된다.
d(dead bit)에는, 페치 에이전트(fetch agent)가 에러(error)에 의해 dead state로 변한 것을 나타내는 플래그가 세트된다.
len 필드에는, SBP2 스테이터스 블록의 사이즈가 세트된다. SBP2 스테이터스 블록의 사이즈는, len 필드에 세트된 값에, 1quadlets(32 비트)를 가산한 값이다.
sbp_status 필드에는, resp에 수반하는 추가적 정보가 세트된다.
ORB_offset_hi 필드와 ORB_offset_lo 필드에는, SBP2 스테이터스 블록의 바탕으로 되는 ORB의 정보가 세트된다.
r(reserved) 필드는, 예약 영역이다.
sfmt 필드에는, SBP2 스테이터스 블록의 포맷의 정보가 세트된다.
status 필드에는, SCSI 스테이터스(SCSI status)가 세트된다.
v(valid bit)에는, 후술하는 infomation 필드의 내용(content)의 유효 또는 무효를 나타내는 플래그가 세트된다.
m 필드에는, SCSI 마크 비트(SCSI mark bit)가 세트되고, e 필드에는, SCSI eom bit가 세트된다. i 필드에는, SCSI illegal_length_indicator bit가 세트되고, sense_key 필드에는, SCSI sense key가 세트된다. sense_code 필드에는, SCSI additional sense code가 세트되고, sense_qualifier 필드에는, SCSI additional sense code qualifier가 세트된다.
infomation 필드, CDB-dependent 필드, fru 필드, sense_key_dependent 필드, 및 vender-dependent 필드에는, 모두 디바이스 타입(device type)이나 커맨드(command) 등에 의존한 정보가 세트된다.
PD-SBP2에서는, information 필드에, 확장 커맨드에 대한 리턴값이 세트된다.
다음으로, 도 10은, PD-SBP2의 커맨드(확장 커맨드)의 일람을 나타내고 있다.
도 10에 있어서, 커맨드 FILE OPEN은, 파일명과 파일 오픈 모드(File Open Mode)를 인수로 하고, 인수의 파일명에 의해서 특정되는 파일을, 인수의 파일 오픈 모드에서 오픈(Open)한다. 커맨드 FILE OPEN에 대해서는, 오픈된 파일의 파일 핸들(파일 핸들)이 회신된다.
커맨드 FILE CLOSE는, 파일 핸들을 인수로 하고, 그 파일 핸들에 의해 특정되는 파일을 클로즈(Close)한다.
커맨드 FILE READ는, 파일 핸들과 리드 사이즈(Size)를 인수로 하고, 인수의 파일 핸들에 의해서 특정되는 파일의 데이터(File Stream data)를, 인수의 리드 사 이즈분만큼 판독한다(Read한다).
커맨드 FILE WRITE는, 파일 핸들과 라이트 사이즈(Size)를 인수로 하고, 인수의 파일 핸들에 의해서 특정되는 파일에 대해서, 데이터(File Stream data)를, 인수의 라이트 사이즈분만큼 기입한다(Write한다).
커맨드 FILE LOGICAL SEEK은, 파일 핸들과, 논리적인 위치를 인수로 하고, 인수의 파일 핸들에 의해서 특정되는 파일의 파일 포인터(Current File Pointer)를, 인수의 논리적인 위치로 변경한다.
커맨드 SET EOF는, 파일 핸들을 인수로 하고, 인수의 파일 핸들에 의해서 특정되는 파일의 파일 포인터가 표시하는 위치로, EOF(End Of File)를 변경한다.
커맨드 DELETE는, 파일명을 인수로 하고, 그 파일명의 파일을 삭제(Delete)한다.
커맨드 RENAME은, 변경 전의 파일명(또는 디렉토리명)과, 변경 후의 파일명(또는 디렉토리명)을 인수로 하고, 변경 전의 파일명을, 변경 후의 파일명으로 변경한다.
커맨드 MAKE DIRECTORY는, 디렉토리명을 인수로 하고, 그 디렉토리명의 디렉토리를 생성(작성)한다.
커맨드 REMOVE DIRECTORY는, 디렉토리명을 인수로 하고, 그 디렉토리명의 디렉토리를 삭제한다.
커맨드 LIST OPEN은, 파일명(또는 디렉토리명)을 인수로 하고, 그 파일명의 파일 리스트(File List)와 파일 메타(File Meta) 정보를 얻기 위한 핸들(Handle)을 회신한다.
커맨드 LIST READ는, 커맨드 LIST OPEN이 회신하는 핸들을 인수로 하고, 그 핸들에 의해서 특정되는 파일 리스트와 파일 메타 정보를 판독한다.
커맨드 FORMAT는, 드라이브(2)에 장착되어 있는 광 디스크(3)를 포맷(Format)한다.
커맨드 EJECT는, 드라이브(2)에 장착되어 있는 광 디스크(3)를 이젝트(Eject)한다.
커맨드 DISC INFO는, 드라이브(2)에 장착되어 있는 광 디스크(3)에 관한 정보, 즉, 예를 들면, 광 디스크(3)의 빈 용량 등을 회신한다.
커맨드 SYSTEM은, 드라이브(2)에 관한 정보(Sytem 정보)를 회신한다.
커맨드 SETUP은, 드라이브(2)에 의한 PD-SBP2의 커맨드의 수신을 가능하게 한다. 즉, 드라이브(2)는, 커맨드 SETUP를 수신하는 것에 의해, 도 10의 다른 커맨드의 접수가 가능하게 된다.
다음으로, 도 11을 참조하여, PD-SBP2에 의한 파일의 판독 시퀀스(PD-SBP2 Protocol File Read Sequence)를 설명한다.
PC(1)의 어플리케이션(31)(도 4)에 있어서, 드라이브(2)의 광 디스크(3)로부터 데이터를 판독하는 경우, PC(1)의 SBP2 드라이버(56)가 이니시에이터로 되고, 드라이브(2)가 타깃으로 된다.
그리고, 이니시에이터인 PC(1)(의 SBP2 드라이버(56))는, 단계 S21에 있어서, 커맨드 FILE OPEN을, 타깃인 드라이브(2)에 송신하고, 드라이브(2)는, 단계 S41에 있어서, 그 커맨드 FILE OPEN을 수신하고, 단계 S42로 진행한다.
단계 S42에서는, 드라이브(2)는, PC(1)로부터의 커맨드 FILE OPEN에 의해서 지정된 파일을 오픈하고, 그 파일 핸들을, PC(1)로 회신한다. 여기서, 커맨드 FILE OPEN에 의해서 지정된 파일은, 드라이브(2)가 가상 파일 시스템(62)을 통하여 외부에 제공하는 파일이고, 드라이브(2)가 회신하는 파일 핸들도, 드라이브(2)가 가상 파일 시스템(62)을 통하여 외부에 제공하는 파일의 파일 핸들이다.
PC(1)는, 단계 S22에 있어서, 드라이브(2)로부터의 파일 핸들을 수신하고, 단계 S23으로 진행하여, 그 파일 핸들에 의해서 특정되는 파일의 파일 포인터를, 판독하고자 하는 데이터의 선두 위치로 이동시킬 것을 요구하는 커맨드 FILE LOGICAL SEEK를, 드라이브(2)에 송신한다.
드라이브(2)는, 단계 S43에 있어서, PC(1)로부터의 커맨드 FILE LOGICAL SEEK를 수신한다. 또한, 드라이브(2)는, 단계 S42에서 오픈한 파일의 파일 포인터를, PC(1)로부터의 커맨드 FILE LOGICAL SEEK에 의해서 지정되어 있는 위치로 이동시킨다.
그리고, 드라이브(2)는, 단계 S43로부터 S44로 진행하여, 파일 포인터의 이동에 성공한 경우에는, 그 취지를 나타내는 응답 GOOD를 PC(1)에 회신하고, 파일 포인터의 이동에 실패한 경우에는, 그 취지를 나타내는 응답 ERROR를 PC(1)로 회신한다.
PC(1)는, 단계 S24에 있어서, 드라이브(2)로부터의 응답을 수신한다. 그리고, PC(1)는, 드라이브(2)로부터의 응답이, 파일 포인터의 이동에 실패한 것을 나 타내는 ERROR인 경우에는, 예를 들면, 처리를 종료한다.
또한, PC(1)는, 드라이브(2)로부터의 응답이, 파일 포인터의 이동에 성공한 것을 나타내는 GOOD인 경우에는, 단계 S24로부터 S25로 진행하여, 데이터의 판독을 요구하는 커맨드 FILE READ를, 드라이브(2)에 송신한다.
드라이브(2)는, 단계 S45에 있어서, PC(1)로부터의 커맨드 FILE READ를 수신하고, 단계 S43으로 이동한 파일 포인터의 위치로부터 데이터를 판독한다.
그리고, 단계 S461 내지 S46N으로 순차적으로 진행하여, 드라이브(2)는, 단계 S45에서 판독한 데이터를, PC(1)에 송신한다.
즉, 드라이브(2)로부터 PC(1)에 대해서, 한 번에 송신할 수 있는 데이터의 최대 사이즈는 제한되어 있고, PC(1)로부터의 커맨드 FILE READ에 의해서 판독이 요구된 데이터의 사이즈가, 드라이브(2)가 한 번에 송신할 수 있는 데이터의 최대 사이즈보다 큰 경우에는, 드라이브(2)는, PC(1)로부터의 커맨드 FILE READ에 의해서 판독이 요구된 데이터를, 예를 들면, 한 번에 송신할 수 있는 데이터의 최대 사이즈로 나누어 송신한다. 도 11의 실시형태에서는, 드라이브(2)로부터 PC(1)에 대해서, 단계 S461 내지 S46N의 N회로 나누어, 데이터가 송신되고 있다.
PC(1)는, 단계 S261 내지 S26N에 있어서, 드라이브(2)가 단계 S461 내지 S46N에서 송신되어 오는 데이터를 각각 수신하고, 이것에 의해, 커맨드 FILE READ에 의해서 요구한 데이터의 모든 수신이 완료하면, 단계 S27로 진행하여, 단계 S21에서 송신한 커맨드 FILE OPEN에 의해서 오픈을 요구한 파일의 클로즈를 요구하는 커맨 드 FILE CLOSE를, 드라이브(2)에 송신한다.
드라이브(2)는, 단계 S47에 있어서, PC(1)로부터의 커맨드 FILE CLOSE를 수신하고, 그 커맨드 FILE CLOSE에 의해서 지정된 파일을 클로즈한다.
또한, 드라이브(2)는, 단계 S47로부터 S48로 진행하여, 파일의 클로즈에 성공한 경우에는, 그 취지를 나타내는 응답 GOOD를 PC(1)로 회신하고, 파일의 클로즈에 실패한 경우에는, 그 취지를 나타내는 응답 ERROR를 PC(1)로 회신한다.
다음으로, 도 12를 참조하여, PD-SBP2에 의한 파일의 기입 시퀀스(PD-SBP2 Protocol File Write Sequence)를 설명한다.
PC(1)의 어플리케이션(31)(도 4)에 있어서, 드라이브(2)의 광 디스크(3)에 데이터를 기입하는 경우, PC(1)의 SBP2 드라이버(56)가 이니시에이터로 되고, 드라이브(2)가 타깃으로 된다.
그리고, 이니시에이터인 PC(1)(의 SBP2 드라이버(56))는, 단계 S61에 있어서, 커맨드 FILE OPEN을, 타깃인 드라이브(2)에 송신하고, 드라이브(2)는, 단계 S81에 있어서, 그 커맨드 FILE OPEN을 수신하고, 단계 S82로 진행한다.
단계 S82에서는, 드라이브(2)는, PC(1)로부터의 커맨드 FILE OPEN에 의해서 지정된 파일을 오픈하고, 그 파일 핸들을 PC(1)로 회신한다.
PC(1)는, 단계 S62에 있어서, 드라이브(2)로부터의 파일 핸들을 수신하고, 단계 S63로 진행하여, 그 파일 핸들에 의해서 특정되는 파일의 파일 포인터를, 데이터를 기입하는 선두 위치로 이동시킬 것을 요구하는 커맨드 FILE LOGICAL SEEK를, 드라이브(2)에 송신한다.
드라이브(2)는, 단계 S83에 있어서, PC(1)로부터의 커맨드 FILE LOGICAL SEEK을 수신한다. 또한, 드라이브(2)는, 단계 S82에서 오픈한 파일의 파일 포인터를, PC(1)로부터의 커맨드 FILE LOGICAL SEEK에 의해서 지정되어 있는 위치로 이동시킨다.
그리고, 드라이브(2)는, 단계 S83으로부터 S84로 진행하여, 파일 포인터의 이동에 성공한 경우에는, 그 취지를 나타내는 응답 GOOD를 PC(1)에 회신하고, 파일 포인터의 이동에 실패한 경우에는, 그 취지를 나타내는 응답 ERROR를 PC(1)로 회신한다.
PC(1)는, 단계 S64에 있어서, 드라이브(2)로부터의 응답을 수신한다. 그리고, PC(1)는, 드라이브(2)로부터의 응답이, 파일 포인터의 이동에 실패한 것을 나타내는 ERROR인 경우에는, 예를 들면, 처리를 종료한다.
또, PC(1)는, 드라이브(2)로부터의 응답이, 파일 포인터의 이동에 성공한 것을 나타내는 GOOD인 경우에는, 단계 S64로부터 S65로 진행하여, 데이터의 기입을 요구하는 커맨드 FILE WRITE를, 드라이브(2)에 송신한다.
또한, PC(1)는, 단계 S661 내지 S66N으로 순차적으로 진행하여, 기입 대상인 데이터를, 드라이브(2)에 송신한다.
즉, PC(1)로부터 드라이브(2)에 대해서, 한 번에 송신할 수 있는 데이터의 최대 사이즈는 제한되어 있고, PC(1)가 기입하려고 하고 있는 데이터(기입 대상 데이터)의 사이즈가, PC(1)가 한 번에 송신할 수 있는 데이터의 최대 사이즈보다 큰 경우에는, PC(1)는, 기입 대상인 데이터를, 예를 들면, 한 번에 송신할 수 있는 데이터의 최대 사이즈로 나누어 송신한다. 도 12의 실시형태에서는, PC(1)로부터 드라이브(2)에 대해서, 단계 S661 내지 S66N의 N회로 나누어, 데이터가 송신되고 있다.
드라이브(2)는, 단계 S85에 있어서, PC(1)로부터의 커맨드 FILE WRITE를 수신하고, 단계 S861 내지 S86N으로 순차적으로 진행하여, 단계 S661 내지 S66N에서 PC(1)로부터 송신되어 오는 데이터를 수신하고, 단계 S83에서 이동한 파일 포인터의 위치로부터, 순차적으로 데이터를 기입한다.
그 후, PC(1)는, 단계 S67로 진행하여, 단계 S61에서 송신한 커맨드 FILE OPEN에 의해서 오픈을 요구한 파일의 클로즈를 요구하는 커맨드 FILE CLOSE를, 드라이브(2)에 송신한다.
드라이브(2)는, 단계 S87에 있어서, PC(1)로부터의 커맨드 FILE CLOSE를 수신하고, 그 커맨드 FILE CLOSE에 의해서 지정된 파일을 클로즈한다.
또한, 드라이브(2)는, 단계 S87로부터 S88로 진행하여, 파일의 클로즈에 성공한 경우에는, 그 취지를 나타내는 응답 GOOD를 PC(1)로 회신하고, 파일의 클로즈에 실패한 경우에는, 그 취지를 나타내는 응답 ERROR를 PC(1)로 회신한다.
그런데, SBP2 드라이버(56)(도 4, 도 6)는, 상술한 바와 같이, PD 스토리지(55)로부터의 SCSI 코드(SCSI 커맨드)를, 도 10에 도시한 PD-SBP2의 커맨드(확장 커맨드)가 cbd[0] 필드에 배치되는 도 8의 SCSI command block ORB(SBP2 데이터)로 변환한다.
또, PD 스토리지(55)는, 상술한 바와 같이, 그 상위의 레이어의 디바이스 드라이버인 PD_FS(54)로부터, NT 입출력 매니저(52)를 통하여 공급되는 IRP를, SCSI 코드로 변환하여, SBP2 드라이버(56)에 출력한다.
따라서, PD_FS(54)가 출력하는 IRP는, PD 스토리지(55)에 있어서 SCSI 코드로 변환되어, SBP2 드라이버(56)에 출력된다. 또한, SBP2 드라이버(56)에서는, PD 스토리지(55)로부터의 SCSI 코드가 SBP2 데이터(SCSI command block ORB)로 변환된다.
즉, SBP2 드라이버(56)는, PD 스토리지(55)가 출력하는 SCSI 코드를, 도 8의 SCSI command block ORB의 cbd[0] 필드에 배치한 SBP2 데이터로 변환한다.
PD-SBP2에서는, 도 8의 SCSI command block ORB의 cbd[0] 필드에, 도 10의 확장 커맨드가 배치된다. 따라서, PD 스토리지(55)가 출력하는 SCSI 코드는, 도 10의 확장 커맨드 중의 어느 하나이고, 말하자면 특별한 SCSI 코드이다. 이 때문에, PD_FS(54)가 NT 입출력 매니저(52)를 통하여 출력하는 IRP는, PD 스토리지(55)에 있어서 특별한 SCSI 코드로 변환되는 특별한 IRP가 아니면 안된다.
한편, Win32 서브 시스템(51)(도 4)이 어플리케이션(31)에 대해서 제공하는, 파일 조작을 위한 API 함수의 호출이 있었던 경우에, Win32 서브 시스템(51)이, NT 입출력 매니저(52), FS 필터 드라이버(53), 및 NT 입출력 매니저(52)를 통하여 PD_FS(54)에 공급하는 IRP는, 미리 결정되어 있다.
즉, Win32 서브 시스템(51)은, 예를 들면, 파일을 오픈하는 API 함수 CreateFile(), 파일로부터 데이터를 판독하는 API 함수 ReadFile(), 파일에 데이터를 기입하는 API 함수 WriteFile() 등을, 어플리케이션(31)에 제공한다.
그리고, 어플리케이션(31)이, 예를 들면, API 함수 CreateFile()을 호출한 경우, NT 입출력 매니저(52)로부터 PD_FS(54)에는, API 함수 CreateFile()에 대해서 미리 결정되어 있는 IRP_MJ_CREATE의 IRP가 공급된다.
마찬가지로, 어플리케이션(31)이, 예를 들면, API 함수 ReadFile(), 또는 WriteFile()을 호출한 경우, NT 입출력 매니저(52)로부터 PD_FS(54)에는, API 함수 ReadFile()에 대해서 미리 결정되어 있는 IRP_MJ_READ, 또는 API 함수 WriteFile()에 대해서 미리 결정되어 있는 IRP_MJ_WRITE의 IRP가 각각 공급된다.
이 경우, PD_FS(54)가, NT 입출력 매니저(52)를 통하여 공급되는 IRP를, NT 입출력 매니저(52)를 통하여, PD 스토리지(55)에 공급해 버리면, NT 입출력 매니저(52)를 통하여 공급되는 IRP, 즉, 예를 들면, IRP_MJ_CREATE나, IRP_MJ_READ, IRP_MJ_WRITE 등의 IRP는, 미리 결정되어 있는, 말하자면 표준의 IRP이기 때문에, PD 스토리지(55)에서는, 그 IRP가, 그 IRP에 대응하는 SCSI 코드, 확장 커맨드가 아닌 SCSI 코드(특별한 SCSI 코드가 아닌 SCSI 코드)로 변환되게 된다.
그래서, PD_FS(54)는, NT 입출력 매니저(52)를 통하여 공급되는 IRP를 변환하고, 이것에 의해, NT 입출력 매니저(52)를 통하여 PD 스토리지(55)에 대해서, 확장 커맨드인 SCSI 코드(특별한 SCSI 코드)로 변환되는 특별한 IRP를 공급한다.
특별한 IRP로서는, 사용자 정의의 IOCTL이 지정되는 IRP_MJ_DEVICE_CONTROL의 IRP가 이용된다.
도 13은, PD_FS(54)이, NT 입출력 매니저(52)를 통하여 PD 스토리지(55)에 출력하는 특별한 IRP로서의 IRP_MJ_DEVICE_CONTROL의 IRP에서 지정되는 사용자 정의의 IOCTL을 나타내고 있다.
도 13의 IOCTL은, 도 10에 도시한 PD-SBP2의 커맨드(확장 커맨드) 중의 SETUP을 제외한 것과 일대일의 관계로 되어 있다.
즉, 도 13에 있어서, IOCTL_PD_FILE_OPEN, IOCTL_PD_FILE_CLOSE, IOCTL_PD_FILE_READ, IOCTL_PD_FILE_WRITE, IOCTL_PD_FILE_LOGICAL_SEEK, IOCTL_PD_SET_EOF, IOCTL_PD_DELETE, IOCTL_PD_RENAME, IOCTL_PD_MAKE_DIRECTORY, IOCTL_REMOVE_DIRECTORY, IOCTL_PD_LIST_OPEN, IOCTL_PD_LIST_READ, IOCTL_PD_FORMAT, IOCTL_PD_EJECT, IOCTL_PD_DISC_INFO, IOCTL_PD_SYSTEM은, 도 10의 커맨드 FILE OPEN, FILE CLOSE, FILE READ, FILE WRITE, FILE LOGICAL SEEK, SET EOF, DELETE, RENAME, MAKE DIRECTORY, REMOVE DIRECTORY, LIST OPEN, LIST READ, FORMAT, EJECT, DISC INFO, SYSTEM에, 각각 대응하고 있다.
PD 스토리지(55)는, PD_FS(55)로부터 NT 입출력 매니저(52)를 통하여 공급되는 IRP가, 도 13의 IOCTL이 지정되어 있는 IRP(IRP_MJ_DEVICE_CONTROL의 IRP)인 경우, 그 IOCTL에 대응하는 확장 커맨드(특별한 SCSI 코드)를, SBP2 드라이버(56)에 출력한다.
그리고, SBP2 드라이버(56)는, PD 스토리지(55)로부터의, IOCTL에 대응하는 확장 커맨드를, 그 확장 커맨드가 cbd[0] 필드에 배치된 도 8의 SCSI command block ORB(SBP2 데이터)로 변환한다.
다음으로, 도 14의 플로우차트를 참조하여, 도 6(도 4)의 PD_FS(54)에 의한 IRP의 처리에 대해서, 또 설명한다. 또한, 여기서는, 설명을 간단히 하기 위해서, NT 캐쉬 매니저(59)(도 4)가 제공하는 캐쉬 기능의 이용은, 생각하지 않는 것으로 한다.
예를 들면, 어플리케이션(31)이, Win32 서브 시스템(51)이 제공하는 파일 조작에 관한 API 함수를 호출하는 것에 의해, 그 API 함수에 대응하는 IRP가, 도 4의 Win32 서브 시스템(51), NT 입출력 매니저(52), FS 필터 드라이버(53), 및 NT 입출력 매니저(52)를 통하여, PD_FS(54)에 송신되어 오면, 단계 S101에 있어서, PD_FS(54)는, 그 IRP를 수신하고, 단계 S102로 진행한다.
단계 S102에서는, PD_FS(54)는, 단계 S101에서 수신한 IRP를, 드라이브(2)와의 IEEE1394 통신에 있어서 파일 시스템을 취급하는 것이 가능한 PD-SBP2의 커맨드(도 10의 확장 커맨드)로 변환되는 도 13의 IOCTL을 발행하는 함수 IoCallDriver()로 변환한다.
여기서, 함수 IoCallDriver()는, 사용자 모드에서 동작하는 Win32 서브 시스템(51)이 제공하는 API 함수 DeviceIoControl과 마찬가지의 기능의 함수로서, 커널 모드에서 사용된다.
그 후, PD_FS(54)는, 단계 S103에 있어서, 단계 S102에서 얻은 함수 IoCallDriver()를 호출하고, 다음의 IRP가 송신되어 오는 것을 대기하고, 단계 S101로 되돌아가서, 이하, 마찬가지의 처리를 반복한다.
이상과 같이, 단계 S103에 있어서, PD_FS(54)가, 함수 IoCallDriver()를 호 출하면, NT 입출력 매니저(52)는, 그 함수 IoCallDriver()에 의해서 발행되는 IOCTL이 지정된 IRP(IRP_MJ_DEVICE_CONTROL의 IRP)를, PD 스토리지(55)에 출력한다. PD 스토리지(55)는, 그 IRP에서 지정되어 있는 IOCTL(도 13)에 대응하는 특별한 SCSI 코드로서의 확장 커맨드(도 10)를, SBP2 드라이버(56)에 출력한다.
SBP2 드라이버(56)에서는, PD 스토리지(55)로부터의, IOCTL에 대응하는 확장 커맨드가, 그 확장 커맨드를 cbd[0] 필드에 배치한 도 8의 SCSI command block ORB(SBP2 데이터)로 변환되어, 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 송신된다.
이상과 같이, PD_FS(54)에서는, 어플리케이션(31)이 파일 조작에 관한 API 함수를 호출하는 것에 의해 공급되는 IRP가, 드라이브(2)와의 IEEE1394 통신에 있어서 파일 시스템을 취급하는 것이 가능한 PD-SBP2의 커맨드(도 10의 확장 커맨드)로 변환되는 도 13의 IOCTL을 발행하는 함수 IoCallDriver()로 변환되므로, 드라이브(2)의 실제 파일 시스템(61) 및 가상 파일 시스템(62)을 그대로 이용하여, 드라이브(2)를, 용이하게 취급할 수 있다.
즉, 예를 들면, OS(30)나, 어플리케이션(31)에 있어서, 일필 기입 기록의 제어를 행하지 않아도, 드라이브(2)에 있어서, 일필 기입 기록의 제어가 행해지므로, AV 데이터의 리얼타임에서의 기록이나 재생이 가능하게 된다.
또한, 어플리케이션(31)으로부터는, 드라이브(2)의 가상 파일 시스템(62)이 PC(1)에 탑재되어 있는 것처럼 보이므로, 그 가상 파일 시스템(62)에 의해 관리되는 파일을, 예를 들면, NTFS나 FAT 등의 범용의 파일 시스템에 의해 관리되는 파일 과 마찬가지로 취급할 수 있다.
그런데, PD 드라이브인 드라이브(2)는, 고 비트 레이트의 AV 데이터의 리얼타임에서의 기입 및 판독을, 그 주목적으로 하고 있고, 이러한 목적의 용도에서는, 기입 및 판독의 대상으로 되는 것은, 일반적으로 1개의 스트림뿐이다.
즉, PD 드라이브에 있어서는, 복수의 스트림을 동시에 기입 및 판독하는 것도 가능하지만, 일필 기입 기록의 성질상, 복수의 스트림을 동시에(시분할로) 기입 및 판독하는 경우에는, 기입 및 판독 대상의 스트림의 변경시에, 씨크가 발생하고, 그 씨크에 의해서 리얼타임성이 방해를 받는다. 따라서, 리얼타임성을 확보하기 위해서는, 씨크에 필요한 시간만큼, AV 데이터(스트림)의 비트 레이트를 억제할 필요가 있다.
또, 기입 및 판독 대상을 1개의 스트림만으로 한 경우에, 어떤 고 비트 레이트에서의 AV 데이터의 리얼타임에서의 기입 및 판독이 가능하다고 하면, 기입 및 판독 대상을, 복수인 M개의 스트림으로 한 경우, 단순하게는, 기입 및 판독 대상의 스트림이 1개뿐인 경우의 1/M 이하의 비트 레이트의 스트림이 아니면, 리얼타임으로 기입 및 판독을 할 수 없고, 따라서 기입 및 판독을 할 수 있는 스트림이, 저화질 또는 저음질의 AV 데이터로 된다.
이상으로부터, 고 비트 레이트의 AV 데이터의 리얼타임에서의 기입 및 판독을 하기 위해서는, 광 디스크(3)에 대해서 기입 및 판독하는 AV 데이터의 스트림은, 1개로 제한하는 것이 바람직하다. 그리고, 이 제한은, 예를 들면, 드라이브(2)에 있어서 1개의 파일 핸들밖에 취급하지 않는 것으로 함으로써 실현할 수 있 다.
한편, 컴퓨터의 범용의 OS에서는, 일반적으로, 파일의 오픈은 복수 행할 수 있다.
따라서, PC(1)에 드라이브(2)를 접속한 경우에는, 어플리케이션(31)으로부터는, 드라이브(2)에 장착된 광 디스크(3) 상의 파일의 오픈을 복수 행하고, 그 오픈된 파일에 대한 조작을 행할 수 있는 것이 바람직하다.
따라서, PD_FS(54)에는, 드라이브(2)가 1개의 파일 핸들만을 취급하는 경우에도, 어플리케이션(31)이, 외관상, 파일의 오픈을 복수 동시에 행할 수 있도록 하는 기능(이하, 적절하게, 복수 동시 오픈 기능이라고 함)을 갖게 할 수 있다.
도 15는, 복수 동시 오픈 기능을 설명하기 위한 도면이다.
즉, 도 15는, 어플리케이션(31)이, 파일의 오픈을 복수회 행한 경우의, 커널(58)의 상태를, 모식적으로 나타내고 있다.
어플리케이션(31)이 파일을 오픈하면, 커널(58)의 내부에는, 그 파일의 오픈에 대응해서, 파일 오브젝트(File Object)가 작성된다.
도 15에서는, 3개의 파일 오브젝트(81, 82, 83)가, 커널(58)의 내부에 작성되어 있다.
여기서, 파일 오브젝트(81)는, 어플리케이션(31)이, API 함수 CreateFile()을 호출하고, 예를 들면, 도 7의 좌측에 도시한 가상 파일 시스템(62)이 관리하는 파일 C0001.MXF를 오픈하는 것에 의해 작성된 파일 오브젝트이다.
파일 오브젝트(82)도, 파일 오브젝트(81)와 마찬가지로, 어플리케이션(31) 이, API 함수 CreateFile()을 호출하고, 파일 C0001.MXF를 오픈하는 것에 의해 작성된 파일 오브젝트이다.
파일 오브젝트(83)는, 어플리케이션(31)이, API 함수 CreateFile()을 호출하고, 예를 들면, 도 7의 좌측에 도시한 가상 파일 시스템(62)이 관리하는 파일 C0002.MXF를 오픈하는 것에 의해 작성된 파일 오브젝트이다.
따라서, 도 15에서는, 어플리케이션(31)이, 파일 C0001.MXF를 오픈하는 API 함수 CreateFile을 2회 호출함과 함께, 파일 C0002.MXF를 오픈하는 API 함수 CreateFile을 1회 호출하는 것에 의해, 3개의 파일 오브젝트(81) 내지 (83)가, 커널(58)의 내부에 작성되어 있다.
또한, 파일 오브젝트(81~83) 각각은, 대응하는 파일의 파일명(File Name), 파일 핸들(File System File Handle), 및 파일 포인터(File Pointer)를 갖는다.
복수 동시 오픈 기능은, PD_FS(54)이 내장하는 파일 핸들 리소스 매니저(PD-SBP2 File Handle Resource Manager)(54A)가 제공한다.
즉, 드라이브(2)로부터 PD-SBP2에 의해 회신되는 파일 핸들은, 말하자면 리소스(Resource)적인 특징, 즉, 복수가 동시에 유효하게 될 수 없는(복수를 동시에 사용할 수 없는) 성질을 갖는 것이다.
그래서, 파일 핸들 리소스 매니저(54A)는, 드라이브(2)로부터 PD-SBP2에 의해 회신되는 파일 핸들에 대한, 커널(58)의 내부에 작성된 복수의 파일 오브젝트로부터의 액세스의 배타 제어를 행한다. 또한, 배타 제어는, 세마포어(semaphore)와 그 밖의 임의의 방법으로 행할 수 있다.
즉, 파일 핸들 리소스 매니저(54A)는, 드라이브(2)로부터 PD-SBP2에 의해 회신되는 파일 핸들(이하, 적절하게, PD-SBP2 파일 핸들이라고 한다)과, 그 PD-SBP2 파일 핸들을 사용하는 파일 오브젝트에의 포인터를 기억한다.
그리고, 파일 핸들 리소스 매니저(54A)는, 현재 기억하고 있는 PD-SBP2 파일 핸들에 의해서 특정되는 파일과 서로 다른 파일의 오픈을 요구하는 API 함수 FileCreate(), 데이터의 판독을 요구하는 API 함수 ReadFile(), 또는 데이터의 기입을 요구하는 API 함수 WriteFile()이, 어플리케이션(31)에 의해서 호출되면, 현재 기억하고 있는 PD-SBP2 파일 핸들에 의해서 특정되는 파일을 클로즈한다.
또한, 파일 핸들 리소스 매니저(54A)는, 어플리케이션(31)에 의한 API 함수의 호출에 의해서, 오픈, 데이터의 판독, 또는 데이터의 기입이 요구된 파일의 오픈을, 드라이브(2)에 요구하고, 그 요구에 따라서 드라이브(2)가 회신하는 PD-SBP2 파일 핸들을, 지금까지 기억하고 있던 PD-SBP2 파일 핸들 대신에 새롭게 기억한다. 또, 파일 핸들 리소스 매니저(54A)는, 새롭게 기억한 PD-SBP2 파일 핸들을 사용하는 파일 오브젝트에의 포인터를, 지금까지 기억하고 있던 포인터 대신에 새롭게 기억한다.
이상과 같은, PD_FS(54)(의 파일 핸들 리소스 매니저(54A))에 의한 복수 동시 오픈 기능에 의해, 어플리케이션(31)은, 파일의 오픈을, (외관상) 복수 동시에 행할 수 있다.
다음으로, 도 16의 플로우차트를 참조하여, 복수 동시 오픈 기능에 대해서, 또 설명한다. 또한, 여기서도, 설명을 간단히 하기 위해서, NT 캐쉬 매니저(59)( 도 4)가 제공하는 캐쉬 기능의 이용은, 생각하지 않는 것으로 한다.
예를 들면, 어플리케이션(31)이, 단계 S111에 있어서, 파일 A(File "A")의 오픈을 요구하는 API 함수 CreateFile()을 호출하면, Win32 서브 시스템(51)(도 4)이, 그 호출에 따른 요구를, NT 입출력 매니저(52)에 출력하고, NT 입출력 매니저(52)가, Win32 서브 시스템(51)으로부터의 요구에 따라서, 파일 A의 오픈을 요구하는 API 함수 CreateFile()에 대응하는 IRP_MJ_CREATE(의 IRP)를, PD_FS(54)에 출력한다.
PD_FS(54)(의 파일 핸들 리소스 매니저(54A))는, 단계 S131에 있어서, 어플리케이션(31)이 단계 S111에서 API 함수를 호출하는 것에 의해 공급되는, 파일 A의 오픈을 요구하는 IRP_MJ_CREATE를 수신하고, 단계 S132로 진행하여, 그 IRP_MJ_CREATE에 따라서, 파일 A의 오픈을 요구하는 IOCTL인 IOCTL_PD_FILE_OPEN(도 13)을 발행하는 함수 IoCallDriver()를 호출한다.
NT 입출력 매니저(52)는, PD_FS(54)에 의한, 단계 S132에서의 함수 IoCallDriver()의 호출에 따라서, IOCTL_PD_FILE_OPEN이 지정되어 있는 IRP_MJ_DEVICE_CONTROL(의 IRP)를, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S171에 있어서, PD_FS(54)가 단계 S132에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_OPEN이 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE OPEN(도 10)을, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 A(가상 파일 시스템(62)이 외부에 보이는 파일 A)가 오픈된다.
그 후, 예를 들면, 어플리케이션(31)이, 단계 S112에 있어서, 파일 A로부터의 데이터의 판독을 요구하는 API 함수 ReadFile()를 호출하면, Win32 서브 시스템(51)이, 그 호출에 따른 요구를, NT 입출력 매니저(52)에 출력하고, NT 입출력 매니저(52)가, Win32 서브 시스템(51)으로부터의 요구에 따라서, 파일 A로부터의 데이터의 판독을 요구하는 API 함수 ReadFile()에 대응하는 IRP_MJ_READ(의 IRP)를, PD_FS(54)에 출력한다.
PD_FS(54)는, 단계 S133에 있어서, 어플리케이션(31)이 단계 S112에서 API 함수를 호출하는 것에 의해 공급되는, 파일 A로부터의 데이터의 판독을 요구하는 IRP_MJ_READ를 수신하고, 단계 S134로 진행하여, 그 IRP_MJ_READ에 따라서, 파일 A로부터의 데이터의 판독을 요구하는 IOCTL인 IOCTL_PD_FILE_READ(도 13)를 발행하는 함수 IoCallDriver()를 호출한다.
NT 입출력 매니저(52)는, PD_FS(54)에 의한, 단계 S134에서의 함수 IoCallDriver()의 호출에 따라서, IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL(의 IRP)을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S172에 있어서, PD_FS(54)가 단계 S134에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE READ(도 10)를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 A로부터 데이터가 판독된다. 드라이브(2)에 있어서 판독된 데이터는, 1394 버스 드라이버(57), SBP2 드라이버(56), PD 스토리지(55), PD_FS(54), 및 FS 필터 드라이버(53)를 통하여, 어플리케이션(31)에 공급된다.
여기서, PD 스토리지(55)에는, 데이터의 기입 및 판독을 위한 도시하지 않은 리드 라이트 버퍼(Read/Write Buffer)가 준비되어 있다. 리드 라이트 버퍼의 사이즈는, 예를 들면, 페이징시의 페이지 사이즈(page size)(예를 들면, 4 KB(kilo byte))와 동일하게 되어 있고, 한번에 기입 및 판독을 할 수 있는 데이터의 최대 사이즈는, 이 리드 라이트 버퍼의 사이즈에 제한된다.
이 때문에, PD_FS(54)는, 어플리케이션(31)으로부터의 IRP_MJ_READ(어플리케이션(31)이 API 함수 ReadFile()을 호출하는 것에 의해서 공급되는 IRP_MJ_READ)에 의해서 판독이 요구되는 데이터의 사이즈가, 리드 라이트 버퍼의 사이즈를 초과하고 있는 경우에는, 어플리케이션(31)으로부터의 IRP_MJ_READ를, 리드 라이트 버퍼의 사이즈 이내의 데이터의 판독을 요구하는 복수의 IRP_MJ_DEVICE_CONTROL로 분할하여, PD 스토리지(55)에 출력한다. 즉, PD_FS(54)는, 어플리케이션(31)으로부터의 IRP_MJ_READ에 따라서, 리드 라이트 버퍼의 사이즈 이내의 데이터의 판독을 요구하는 IOCTL_PD_FILE_READ를 발행하는 함수 IoCallDriver()를, 복수회 호출하고, 이것에 의해, PD 스토리지(55)에는, 복수의, IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL이 공급된다.
또한, 이것은, 어플리케이션(31)으로부터의, 파일에의 데이터의 기입을 요구하는 IRP_MJ_WRITE에 대해서도, 마찬가지이다.
도 16에서는, PD_FS(54)가, 단계 S133에서 수신한 IRP_MJ_READ에 따라, 단계 S134 내지 S136 각각에 있어서, 파일 A로부터의 데이터의 판독을 요구하는 IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL이, PD 스토리지(55)에 출력되고 있다. 즉, IOCTL_PD_FILE_READ가, 3회에 나누어, PD_FS(54)로부터 PD 스토리지(55)에 출력되고 있다.
PD 스토리지(55)는, 단계 S172 내지 S174 각각에 있어서, PD_FS(54)가 단계 S134 내지 S136에서 출력하는, IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE READ를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력함으로써, 3회에 나누어, 파일 A로부터 데이터를 판독한다.
그 후, 단계 S113에 있어서, 어플리케이션(31)이, 드라이브(2)에 있어서 현재 오픈되어 있는 파일 A와 서로 다른 파일 B(FILE "B")의 오픈을 요구하는 API 함수 CreateFile()을 호출하면, 단계 S111에 있어서의 경우와 마찬가지로 해서, 파일 B의 오픈을 요구하는 API 함수 CreateFile()에 대응하는 IRP_MJ_CREATE가, PD_FS(54)에 공급된다.
PD_FS(54)는, 단계 S137에 있어서, 어플리케이션(31)으로부터의 IRP_MJ_CREATE(어플리케이션(31)이 API 함수 CreateFile()을 호출하는 것에 의해 공급되는, 파일 B의 오픈을 요구하는 IRP_MJ_CREATE)를 수신하고, 단계 S138로 진 행하여, 그 IRP_MJ_CREATE에 따라서, 파일 A의 클로즈를 요구하는 IOCTL인 IOCTL_PD_FILE_CLOSE(도 13)를 발행하는 함수 IoCallDriver()를 호출한다.
즉, 상술한 바와 같이, 드라이브(2)가 취급할 수 있는 파일 핸들은, 1개뿐이므로, PD_FS(54)는, 파일 B의 오픈을 요구하기 전에, 현재 오픈되어 있는 파일 A의 클로즈를 요구한다.
PD_FS(54)에 의한, 단계 S138에서의 함수 IoCallDriver()의 호출에 따라서, NT 입출력 매니저(52)는, 파일 A의 클로즈를 요구하는 IOCTL_PD_FILE_CLOSE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S175에 있어서, PD_FS(54)가 단계 S138에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_CLOSE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE CLOSE(도 10)를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 A가 클로즈된다.
PD_FS(54)는, 단계 S138의 처리 후, 단계 S139로 진행하여, 단계 S137에서 수신한, 파일 B의 오픈을 요구하는 IRP_MJ_CREATE에 따라서, 파일 B의 오픈을 요구하는 IOCTL인 IOCTL_PD_FILE_OPEN(도 13)을 발행하는 함수 IoCallDriver()를 호출하는 것에 의해, 그 IOCTL_PD_FILE_OPEN이 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S176에 있어서, PD_FS(54)로부터의 IRP_MJ_DEVICE_CONTROL, 즉, PD_FS(54)가 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_OPEN이 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE OPEN(도 10)을, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 B(가상 파일 시스템(62)이 외부에 보이는 파일 B)가 오픈된다.
그 후, 예를 들면, 어플리케이션(31)이, 단계 S114에 있어서, 파일 B에의 데이터의 기입을 요구하는 API 함수 WriteFile()를 호출하면, Win32 서브 시스템(51)이, 그 호출에 따른 요구를, NT 입출력 매니저(52)에 출력하고, NT 입출력 매니저(52)가, Win32 서브 시스템(51)으로부터의 요구에 따라서, 파일 B에의 데이터의 기입을 요구하는 API 함수 WriteFile()에 대응하는 IRP_MJ_WRITE를, PD_FS(54)에 출력한다.
PD_FS(54)는, 단계 S140에 있어서, 어플리케이션(31)이 단계 S114에서 API 함수를 호출하는 것에 의해 공급되는, 파일 B에의 데이터의 기입을 요구하는 IRP_MJ_WRITE를 수신하고, 단계 S141로 진행하여, 그 IRP_MJ_WRITE에 따라서, 파일 B에의 데이터의 기입을 요구하는 IOCTL인 IOCTL_PD_FILE_WRITE(도 13)를 발행하는 함수 IoCallDriver()를 호출한다.
NT 입출력 매니저(52)는, PD_FS(54)에 의한, 단계 S141에서의 함수 IoCallDriver()의 호출에 따라서, IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S177에 있어서, PD_FS(54)가 단계 S141에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE WRITE(도 10)를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 B에 데이터가 기입된다.
여기서, 상술한 바와 같이, 한번에 기입 및 판독할 수 있는 데이터의 최대 사이즈는, PD 스토리지(55)에 있어서의 리드 라이트 버퍼의 사이즈에 제한된다.
이 때문에, PD_FS(54)는, 어플리케이션(31)으로부터의 IRP_MJ_WRITE(어플리케이션(31)이 API 함수 WriteFile()을 호출하는 것에 의해서 공급되는 IRP_MJ_WRITE)에 의해서 기입이 요구되는 데이터의 사이즈가, 리드 라이트 버퍼의 사이즈를 초과하고 있는 경우에는, 어플리케이션(31)으로부터의 IRP_MJ_WRITE를, 리드 라이트 버퍼의 사이즈 이내의 데이터의 기입을 요구하는 복수의 IRP_MJ_DEVICE_CONTROL로 분할하여, PD 스토리지(55)에 출력한다. 즉, PD_FS(54)는, 어플리케이션(31)으로부터의 IRP_MJ_WRITE에 따라서, 리드 라이트 버퍼의 사이즈 이내의 데이터의 기입을 요구하는 IOCTL_PD_FILE_WRITE를 발행하는 함수 IoCallDriver()를, 복수회 호출하고, 이것에 의해, PD 스토리지(55)에는, 복수의, IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL이 공급된다.
도 16에서는, PD_FS(54)가, 단계 S140에서 수신한 IRP_MJ_WRITE에 따라, 단 계 S141 내지 S143 각각에 있어서, 파일 B에의 데이터의 기입을 요구하는 IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL이, PD 스토리지(55)에 출력되고 있다. 즉, IOCTL_PD_FILE_WRITE가, 3회에 나누어, PD_FS(54)로부터 PD 스토리지(55)에 출력되고 있다.
PD 스토리지(55)는, 단계 S177 내지 S179 각각에 있어서, PD_FS(54)가 단계 S141 내지 S143에서 출력하는, IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE WRITE를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력함으로써, 3회에 나누어, 파일 B에 데이터를 기입한다.
그 후, 단계 S115에 있어서, 어플리케이션(31)이, 드라이브(2)에 있어서 현재 오픈되어 있는 파일 B와 다른 파일 A로부터의 데이터의 판독을 요구하는 API 함수 ReadFile()을 호출하면, 단계 S112에 있어서의 경우와 마찬가지로 해서, 파일 A로부터의 데이터의 판독을 요구하는 API 함수 ReadFile()에 대응하는 IRP_MJ_READ가, PD_FS(54)에 공급된다.
PD_FS(54)는, 단계 S144에 있어서, 어플리케이션(31)으로부터의 IRP_MJ_READ(어플리케이션(31)이 API 함수 ReadFile()을 호출하는 것에 의해 공급되는, 파일 A로부터의 데이터의 판독을 요구하는 IRP_MJ_READ)를 수신하고, 단계 S145로 진행하여, 그 IRP_MJ_READ에 따라서, 파일 B의 클로즈를 요구하는 IOCTL인 IOCTL_PD_FILE_CLOSE(도 13)를 발행하는 함수 IoCallDriver()를 호출한다.
즉, 상술한 바와 같이, 드라이브(2)가 취급할 수 있는 파일 핸들은, 1개뿐이 므로, PD_FS(54)는, 파일 A로부터의 데이터의 판독을 요구하기 전에, 현재 오픈되어 있는 파일 B의 클로즈를 요구한다.
PD_FS(54)에 의한, 단계 S145에서의 함수 IoCallDriver()의 호출에 따라서, NT 입출력 매니저(52)는, 파일 B의 클로즈를 요구하는 IOCTL_PD_FILE_CLOSE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S180에 있어서, PD_FS(54)가 단계 S145에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_CLOSE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE CLOSE(도 10)를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 B가 클로즈된다.
PD_FS(54)는, 단계 S145의 처리 후, 단계 S146로 진행하여, 단계 S144에서 수신한, 파일 A로부터의 데이터의 판독을 요구하는 IRP_MJ_READ에 따라서, 또, 파일 A의 오픈을 요구하는 IOCTL인 IOCTL_PD_FILE_OPEN(도 13)을 발행하는 함수 IoCallDriver()를 호출한다.
즉, 상술한 단계 S175에 있어서, PD 스토리지(55)가, 파일 A의 클로즈를 요구하는 확장 커맨드 FILE CLOSE(도 10)를, 드라이브(2)에 출력하는 것에 의해, 파일 A는, 현재 클로즈되어 있으므로, 파일 A로부터의 데이터의 판독을 행하기 위해, PD_FS(54)는, 파일 A의 오픈을 요구하는 IOCTL인 IOCTL_PD_FILE_OPEN을 발행하는 함수 IoCallDriver()를 호출한다.
PD_FS(54)에 의한, 단계 S146에서의 함수 IoCallDriver()의 호출에 따라서, NT 입출력 매니저(52)는, 파일 A의 오픈을 요구하는 IOCTL_PD_FILE_OPEN이 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S181에 있어서, PD_FS(54)가 단계 S146에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_OPEN이 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE OPEN(도 10)을, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 A가 오픈된다.
PD_FS(54)는, 단계 S146의 처리 후, 단계 S147로 진행하여, 단계 S144에서 수신한, 파일 A로부터의 데이터의 판독을 요구하는 IRP_MJ_READ에 따라서, 파일 A로부터의 데이터의 판독을 요구하는 IOCTL인 IOCTL_PD_FILE_READ(도 13)를 발행하는 함수 IoCallDriver()를 호출하는 것에 의해, 그 IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S182에 있어서, PD_FS(54)로부터 공급되는, IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE READ(도 10)를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 A로부터 데이터가 판독된다. 드라이브(2)에 있어서 판독된 데이터는, 1394 버스 드라이버(57), SBP2 드라이버(56), PD 스토리지(55), PD_FS(54), 및 FS 필터 드라이버(53)를 통하여, 어플리케이션(31)에 공급된다.
또한, 상술한 PD 스토리지(55)에 있어서의 리드 라이트 버퍼의 사이즈에 따른 기입 및 판독의 제한에 의해서, 도 16에서는, PD_FS(54)가, 단계 S144에서 수신한 IRP_MJ_READ에 따라, 단계 S147 내지 S149 각각에 있어서, 파일 A로부터의 데이터의 판독을 요구하는 IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL이, PD 스토리지(55)에 출력되고 있다. 즉, IOCTL_PD_FILE_READ가, 3회에 나누어, PD_FS(54)로부터 PD 스토리지(55)에 출력되고 있다.
PD 스토리지(55)는, 단계 S182 내지 S184 각각에 있어서, PD_FS(54)가 단계 S147 내지 S149에서 출력하는, IOCTL_PD_FILE_READ가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE READ를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력함으로써, 3회에 나누어, 파일 A로부터 데이터를 판독한다.
그 후, 단계 S116에 있어서, 어플리케이션(31)이, 드라이브(2)에 있어서 현재 오픈되어 있는 파일 A와 다른 파일 B에의 데이터의 기입을 요구하는 API 함수 WriteFile()을 호출하면, 단계 S114에 있어서의 경우와 마찬가지로 해서, 파일 B에의 데이터의 기입을 요구하는 API 함수 WriteFile()에 대응하는 IRP_MJ_WRITE가, PD_FS(54)에 공급된다.
PD_FS(54)는, 단계 S150에 있어서, 어플리케이션(31)으로부터의 IRP_MJ_WRITE(어플리케이션(31)이 API 함수 WriteFile()을 호출하는 것에 의해 공 급되는, 파일 B에의 데이터의 기입을 요구하는 IRP_MJ_WRITE)를 수신하고, 단계 S151로 진행하여, 그 IRP_MJ_WRITE에 따라서, 파일 A의 클로즈를 요구하는 IOCTL인 IOCTL_PD_FILE_CLOSE(도 13)를 발행하는 함수 IoCallDriver()를 호출한다.
즉, 상술한 바와 같이, 드라이브(2)가 취급할 수 있는 파일 핸들은, 1개뿐이므로, PD_FS(54)는, 파일 B에의 데이터의 기입을 요구하기 전에, 현재 오픈되어 있는 파일 A의 클로즈를 요구한다.
PD_FS(54)에 의한, 단계 S151에서의 함수 IoCallDriver()의 호출에 따라서, NT 입출력 매니저(52)는, 파일 A의 클로즈를 요구하는 IOCTL_PD_FILE_CLOSE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S185에 있어서, PD_FS(54)가 단계 S151에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_CLOSE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE CLOSE(도 10)를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 A가 클로즈된다.
PD_FS(54)는, 단계 S151의 처리 후, 단계 S152로 진행하여, 단계 S150에서 수신한, 파일 B에의 데이터의 기입을 요구하는 IRP_MJ_WRITE에 따라서, 또, 파일 B의 오픈을 요구하는 IOCTL인 IOCTL_PD_FILE_OPEN(도 13)을 발행하는 함수 IoCallDriver()를 호출한다.
즉, 상술한 단계 S180에 있어서, PD 스토리지(55)가, 파일 B의 클로즈를 요 구하는 확장 커맨드 FILE CLOSE(도 10)를, 드라이브(2)에 출력하는 것에 의해, 파일 B는, 현재 클로즈되어 있으므로, 파일 B에의 데이터의 기입을 행하기 위해, PD_FS(54)는, 파일 B의 오픈을 요구하는 IOCTL인 IOCTL_PD_FILE_OPEN을 발행하는 함수 IoCallDriver()를 호출한다.
PD_FS(54)에 의한, 단계 S152에서의 함수 IoCallDriver()의 호출에 따라서, NT 입출력 매니저(52)는, 파일 B의 오픈을 요구하는 IOCTL_PD_FILE_OPEN이 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S186에 있어서, PD_FS(54)가 단계 S152에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_OPEN이 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE OPEN(도 10)을, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 B가 오픈된다.
PD_FS(54)는, 단계 S152의 처리 후, 단계 S153으로 진행하여, 단계 S150에서 수신한, 파일 B로의 데이터의 기입을 요구하는 IRP_MJ_WRITE에 따라서, 파일 B에의 데이터의 기입을 요구하는 IOCTL인 IOCTL_PD_FILE_WRITE(도 13)를 발행하는 함수 IoCallDriver()를 호출하는 것에 의해, 그 IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S187에 있어서, PD_FS(54)로부터 공급되는, IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE WRITE(도 10)를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 B에 데이터가 기입된다.
또한, 상술한 PD 스토리지(55)에 있어서의 리드 라이트 버퍼의 사이즈에 따른 기입 및 판독의 제한에 의해서, 도 16에서는, PD_FS(54)가, 단계 S150에서 수신한 IRP_MJ_WRITE에 따라, 단계 S153 내지 S155 각각에 있어서, 파일 B에의 데이터의 기입을 요구하는 IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL이, PD 스토리지(55)에 출력되고 있다. 즉, IOCTL_PD_FILE_WRITE가, 3회에 나누어, PD_FS(54)로부터 PD 스토리지(55)에 출력되고 있다.
PD 스토리지(55)는, 단계 S187 내지 S189 각각에 있어서, PD_FS(54)가 단계 S153 내지 S155에서 출력하는, IOCTL_PD_FILE_WRITE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고, 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE WRITE를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력함으로써, 3회에 나누어, 파일 B에 데이터를 기입한다.
그 후, 단계 S117에 있어서, 어플리케이션(31)이, 파일 A의 클로즈를 요구하는 API 함수 CloseFile()을 호출하면, Win32 서브 시스템(51)(도 4)이, 그 호출에 따른 요구를, NT 입출력 매니저(52)에 출력하고, NT 입출력 매니저(52)가, Win32 서브 시스템(51)으로부터의 요구에 따라서, 파일 A에 관한 크린업을 요구하는 IRP_MJ_CLEANUP과, 파일 A의 클로즈를 요구하는 API 함수 CloseFile()에 대응하는 IRP_MJ_CLOSE를, PD_FS(54)에 출력한다.
PD_FS(54)는, 단계 S156과 S157에 있어서, 어플리케이션(31)이 단계 S117에서 API 함수를 호출하는 것에 의해 공급되는, 파일 A에 관한 크린업을 요구하는 IRP_MJ_CLEANUP과, 파일 A의 클로즈를 요구하는 IRP_MJ_CLOSE를, 각각 수신한다.
그리고, PD_FS(54)는, 파일 A에 관한 크린업을 요구하는 IRP_MJ_CLEANUP에 따라, 예를 들면, NT 캐쉬 매니저(59)(도 4)가 제공하는 캐쉬 기능에 의해 캐쉬된 데이터를 플러시(Flush)하는 등의 크린업 처리를 행한다. 또한, PD_FS(54)는, IRP_MJ_CLOSE에 의해서 클로즈가 요구된 파일 A가 오픈되어 있는 지의 여부를 판정한다(예를 들면, 도 15에서 설명한 PD-SBP2 파일 핸들을 사용하는 파일 오브젝트가, 파일 A의 파일 오브젝트로 되어 있는지의 여부를 판정한다).
도 16에서는, 상술한 단계 S185에 있어서, PD 스토리지(55)가, 파일 A의 클로즈를 요구하는 확장 커맨드 FILE CLOSE(도 10)를 드라이브(2)에 출력하는 것에 의해, 파일 A는 현재 클로즈되어 있으므로, PD_FS(54)에서는, IRP_MJ_CLOSE에 의해서 클로즈가 요구된 파일 A가, 이미 클로즈되어 있다고 판정된다. 이 경우, PD_FS(54)는, 파일 A의 클로즈를 요구하는 IRP_MJ_CLOSE에 대해서, 특별히 처리를 행하지 않는다.
그리고, 단계 S118에 있어서, 어플리케이션(31)이, 파일 B의 클로즈를 요구하는 API 함수 CloseFile()를 호출하면, Win32 서브 시스템(51)(도 4)이, 그 호출에 따른 요구를, NT 입출력 매니저(52)에 출력하고, NT 입출력 매니저(52)가, Win32 서브 시스템(51)으로부터의 요구에 따라서, 파일 B에 관한 크린업을 요구하 는 IRP_MJ_CLEANUP과, 파일 B의 클로즈를 요구하는 API 함수 CloseFile()에 대응하는 IRP_MJ_CLOSE를, PD_FS(54)에 출력한다.
PD_FS(54)는, 단계 S158과 S159에 있어서, 어플리케이션(31)이 단계 S118에서 API 함수를 호출하는 것에 의해 공급되는, 파일 B에 관한 크린업을 요구하는 IRP_MJ_CLEANUP과, 파일 B의 클로즈를 요구하는 IRP_MJ_CLOSE를 각각 수신한다.
그리고, PD_FS(54)는, 파일 B에 관한 크린업을 요구하는 IRP_MJ_CLEANUP에 따라, 예를 들면, 상술한 바와 같은 크린업 처리를 행한다. 또한, PD_FS(54)는, IRP_MJ_CLOSE에 의해서 클로즈가 요구된 파일 B가 오픈되어 있는 지의 여부를 판정한다.
도 16에서는, 상술한 단계 S186에 있어서, PD 스토리지(55)가, 파일 B의 오픈을 요구하는 확장 커맨드 FILE OPEN(도 10)을 드라이브(2)에 출력하는 것에 의해, 파일 B는 현재 오픈되어 있으므로, PD_FS(54)에서는, IRP_MJ_CLOSE에 의해서 클로즈가 요구된 파일 B가, 현재 오픈되어 있다고 판정된다.
이 경우, PD_FS(54)는, 단계 S159에서 수신한 파일 B의 클로즈를 요구하는 IRP_MJ_CLOSE에 따라서, 단계 S160으로 진행하여, 그 IRP_MJ_CLOSE에 따라서, 파일 B의 클로즈를 요구하는 IOCTL인 IOCTL_PD_FILE_CLOSE(도 13)를 발행하는 함수 IoCallDriver()를 호출한다.
PD_FS(54)에 의한, 단계 S160에서의 함수 IoCallDriver()의 호출에 따라서, NT 입출력 매니저(52)는, 파일 B의 클로즈를 요구하는 IOCTL_PD_FILE_CLOSE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을, PD 스토리지(55)에 공급한다.
PD 스토리지(55)는, 단계 S190에 있어서, PD_FS(54)가 단계 S160에서 함수 IoCallDriver()를 호출하는 것에 의해 공급되는, IOCTL_PD_FILE_CLOSE가 지정되어 있는 IRP_MJ_DEVICE_CONTROL을 수신하고 그 IRP_MJ_DEVICE_CONTROL에 대응하는 확장 커맨드 FILE CLOSE(도 10)를, SBP2 드라이버(56) 및 1394 버스 드라이버(57)를 통하여, 드라이브(2)에 출력한다.
이것에 의해, 드라이브(2)에서는, 광 디스크(3) 상의 파일 B가 클로즈된다.
이상과 같이, 복수 동시 오픈 기능에 따르면, 드라이브(2)에 있어서 현재오픈되어 있는 파일과 다른 파일에 액세스하는 액세스 요구가 있었던 경우에, PD_FS(54)(의 파일 핸들 리소스 매니저(54A))에 있어서, 현재 오픈되어 있는 파일을 클로즈하고, 액세스 요구가 있었던 파일을 오픈함으로써, 드라이브(2)가 취급하는 1개의 파일 핸들에 대한 액세스의 배타 제어를 행하도록 했으므로, 어플리케이션(31)에서는, 드라이브(2)가 1개의 파일 핸들밖에 취급할 수 없다는 것을 특별히 고려하지 않고, 복수의 파일에 대한 조작을 행할 수 있다.
또한, 본 실시의 형태에서는, 데이터의 기록이나 재생이 행해지는 기록 매체로서, 광 디스크를 채용하는 것으로 했지만, 본 발명은, 그 밖에, 예를 들면, 하드디스크와 그 밖의 기록 매체 등에 대해서 데이터의 기록이나 재생을 행하는 경우에 적용 가능하다.
또, 본 명세서에 있어서, PC(1)에 각종 처리를 행하게 하기 위한 프로그램을 기술하는 처리 단계는, 반드시 플로우차트로서 기재된 순서를 따라서 시계열로 처리할 필요는 없고, 병렬적 혹은 개별로 실행되는 처리(예를 들면, 병렬 처리 혹은 오브젝트에 의한 처리)도 포함하는 것이다.
본 발명에 따르면, 내부에 파일 시스템을 갖는 기록 또는 재생 장치를, 용이하게 취급할 수 있다.

Claims (8)

  1. 파일 시스템을 갖는 기록 또는 재생 장치와 접속되는 정보 처리 장치에 있어서,
    어플리케이션으로부터의 파일 조작에 관한 요구에 따라서 오퍼레이팅 시스템이 제공하는 커맨드를 수신하는 수신 수단과,
    상기 오퍼레이팅 시스템이 제공하는 커맨드를, 상기 기록 또는 재생 장치와의 통신에서 상기 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 수단
    을 구비하는 것을 특징으로 하는 정보 처리 장치.
  2. 제1항에 있어서,
    상기 기록 또는 재생 장치가 1개의 파일 핸들만을 취급하는 경우에,
    상기 기록 또는 재생 장치의 1개의 파일 핸들에 대한 액세스의 배타 제어를 행하는 배타 제어 수단을 더 구비하는 것을 특징으로 하는 정보 처리 장치.
  3. 제1항에 있어서,
    상기 정보 처리 장치는, 상기 기록 또는 재생 장치의 파일 시스템에 의해서 행해지는 파일 관리를 행하지 않는 파일 시스템 드라이버인 것을 특징으로 하는 정보 처리 장치.
  4. 제1항에 있어서,
    상기 기록 또는 재생 장치에서 파일에 기입 및 판독되는 데이터는, AV(Audio Visual) 데이터를, 적어도 포함하는 것을 특징으로 하는 정보 처리 장치.
  5. 제1항에 있어서,
    상기 기록 또는 재생 장치는, 기록 매체의 기록 영역 상의 소정의 크기 이상의 연속된 빈 영역 중, 직전에 데이터가 기록된 기록 영역에 가장 가까운 위치의 빈 영역을 예약하여, 데이터를 기록하는 것을 특징으로 하는 정보 처리 장치.
  6. 파일 시스템을 갖는 기록 또는 재생 장치와 접속되는 정보 처리 장치의 정보 처리 방법에 있어서,
    어플리케이션으로부터의 파일 조작에 관한 요구에 따라서 오퍼레이팅 시스템이 제공하는 커맨드를 수신하는 수신 단계와,
    상기 오퍼레이팅 시스템이 제공하는 커맨드를, 상기 기록 또는 재생 장치와의 통신에서 상기 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 단계
    를 포함하는 것을 특징으로 하는 정보 처리 방법.
  7. 파일 시스템을 갖는 기록 또는 재생 장치와 접속되는 컴퓨터가 행하도록 하 는 프로그램으로서,
    어플리케이션으로부터의 파일 조작에 관한 요구에 따라서 오퍼레이팅 시스템이 제공하는 커맨드를 수신하는 수신 단계와,
    상기 오퍼레이팅 시스템이 제공하는 커맨드를, 상기 기록 또는 재생 장치와의 통신에서 상기 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 단계
    를 포함하는 것을 특징으로 하는 프로그램.
  8. 파일 시스템을 갖는 기록 또는 재생 장치와 접속되는 컴퓨터가 행하도록 하는 프로그램이 기록되어 있는 기록 매체에 있어서,
    어플리케이션으로부터의 파일 조작에 관한 요구에 따라서 오퍼레이팅 시스템이 제공하는 커맨드를 수신하는 수신 단계와,
    상기 오퍼레이팅 시스템이 제공하는 커맨드를, 상기 기록 또는 재생 장치와의 통신에서 상기 파일 시스템을 취급하는 것이 가능한 통신 프로토콜의 커맨드로 변환되는 요구로 변환하는 변환 단계
    를 포함하는 것을 특징으로 하는 프로그램이 기록되어 있는 기록 매체.
KR1020050030599A 2004-04-15 2005-04-13 정보 처리 장치, 정보 처리 방법 및 기록 매체 KR101116433B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004119851A JP4241485B2 (ja) 2004-04-15 2004-04-15 情報処理装置および情報処理方法、並びにプログラムおよび記録媒体
JPJP-P-2004-00119851 2004-04-15

Publications (2)

Publication Number Publication Date
KR20060045646A true KR20060045646A (ko) 2006-05-17
KR101116433B1 KR101116433B1 (ko) 2012-03-07

Family

ID=34940794

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020050030599A KR101116433B1 (ko) 2004-04-15 2005-04-13 정보 처리 장치, 정보 처리 방법 및 기록 매체

Country Status (5)

Country Link
US (1) US7769920B2 (ko)
EP (1) EP1586988A3 (ko)
JP (1) JP4241485B2 (ko)
KR (1) KR101116433B1 (ko)
CN (1) CN100399310C (ko)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7647455B2 (en) 2004-04-15 2010-01-12 Sony Corporation Information processing apparatus and method, program, and program recording medium
EP1810294B1 (en) 2004-11-09 2018-11-28 Thomson Licensing Bonding contents on separate storage media
EP1669855A1 (en) 2004-12-02 2006-06-14 Deutsche Thomson-Brandt Gmbh Method for generating multi-language menus
JP2007257494A (ja) * 2006-03-24 2007-10-04 Sony Corp データ記録装置、接続装置、情報処理システム、及び情報処理方法
JP2008107965A (ja) * 2006-10-24 2008-05-08 Sony Corp 情報処理装置、情報処理方法、プログラム、プログラム記録媒体
JP4349441B2 (ja) * 2007-06-12 2009-10-21 ソニー株式会社 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP5034921B2 (ja) * 2007-12-14 2012-09-26 ソニー株式会社 情報処理装置、ディスク、および情報処理方法、並びにプログラム
US8943409B2 (en) 2008-12-26 2015-01-27 Sandisk Il Ltd. Storage device managing playable content
US8239395B2 (en) 2008-12-26 2012-08-07 Sandisk Il Ltd. Storage device presenting to hosts only files compatible with a defined host capability
US20100169395A1 (en) * 2008-12-26 2010-07-01 Sandisk Il Ltd. Device and method for filtering a file system
US8166067B2 (en) 2008-12-26 2012-04-24 Sandisk Il Ltd. Method and apparatus for providing access to files based on user identity
US9092597B2 (en) * 2009-12-09 2015-07-28 Sandisk Technologies Inc. Storage device and method for using a virtual file in a public memory area to access a plurality of protected files in a private memory area
JP2011203977A (ja) * 2010-03-25 2011-10-13 Hitachi-Lg Data Storage Inc ストレージ装置、及びストレージ装置におけるファイルシステムの生成方法
US9424271B2 (en) 2012-08-30 2016-08-23 International Business Machines Corporation Atomic incremental load for map-reduce systems on append-only file systems
CN104750605B (zh) * 2013-12-30 2018-08-14 伊姆西公司 将内核对象信息包括在用户转储中
KR101996266B1 (ko) * 2014-09-18 2019-10-01 삼성전자주식회사 호스트 및 이를 포함하는 컴퓨터 시스템
JP6767319B2 (ja) * 2017-07-31 2020-10-14 株式会社ソニー・インタラクティブエンタテインメント 情報処理装置およびファイルコピー方法
US11513691B2 (en) * 2021-01-09 2022-11-29 Western Digital Technologies, Inc. Systems and methods for power and performance improvement through dynamic parallel data transfer between device and host

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH025150A (ja) 1988-06-24 1990-01-10 Nec Corp 磁気ディスクボリューム空き領域管理方式
US5463772A (en) 1993-04-23 1995-10-31 Hewlett-Packard Company Transparent peripheral file systems with on-board compression, decompression, and space management
US5961582A (en) * 1994-10-25 1999-10-05 Acorn Technologies, Inc. Distributed and portable execution environment
CN1144127C (zh) * 1995-11-10 2004-03-31 索尼公司 信息处理装置及信息处理方法
US6292625B1 (en) * 1996-09-30 2001-09-18 Matsushita Electric Industrial Co., Ltd. Recording/reproducing method suitable for recording/reproducing AV data on/from disc, recorder and reproducer for the method, information recording disc and information processing system
JP2000148651A (ja) 1998-11-10 2000-05-30 Hitachi Ltd 共有ディスク装置
JP3511935B2 (ja) 1999-03-05 2004-03-29 日本電気株式会社 マルチスレッド・プログラムにおけるファイル書込方式
JP4501197B2 (ja) * 2000-01-07 2010-07-14 ソニー株式会社 情報携帯処理システム、情報携帯装置のアクセス装置及び情報携帯装置
US6823398B1 (en) * 2000-03-31 2004-11-23 Dphi Acquisitions, Inc. File system management embedded in a storage device
JP4419282B2 (ja) * 2000-06-14 2010-02-24 ソニー株式会社 情報処理装置、情報処理方法、および情報管理システム、並びにプログラム格納媒体
JP2002175286A (ja) 2000-12-05 2002-06-21 Hitachi Ltd 記憶装置、情報処理システムおよび排他制御方法
JP3629216B2 (ja) 2001-03-08 2005-03-16 株式会社東芝 デフラグメンテーション機能を有するディスク記憶システム、及び同システムにおけるデフラグメンテーション方法
US7266538B1 (en) * 2002-03-29 2007-09-04 Emc Corporation Methods and apparatus for controlling access to data in a data storage system
JP4045940B2 (ja) * 2002-04-05 2008-02-13 ソニー株式会社 記録制御装置および記録制御方法、プログラム、並びに記録媒体
US7493404B2 (en) * 2002-05-30 2009-02-17 Lsi Corporation Apparatus and method for providing transparent sharing of channel resources by multiple host machines utilizing mixed mode block and file protocols
JP2004030254A (ja) 2002-06-26 2004-01-29 Hitachi Ltd リモートｓｉ制御方式

Also Published As

Publication number Publication date
US20050232589A1 (en) 2005-10-20
EP1586988A3 (en) 2008-12-24
KR101116433B1 (ko) 2012-03-07
JP2005301853A (ja) 2005-10-27
CN100399310C (zh) 2008-07-02
CN1690993A (zh) 2005-11-02
JP4241485B2 (ja) 2009-03-18
US7769920B2 (en) 2010-08-03
EP1586988A2 (en) 2005-10-19

Similar Documents

Publication Publication Date Title
KR101116433B1 (ko) 정보 처리 장치, 정보 처리 방법 및 기록 매체
KR100942894B1 (ko) 물리적 기억 장치의 소프트웨어-이용 기억 장치 에뮬레이션
JP4406224B2 (ja) イメージファイル管理方法及びその記録媒体
TWI450110B (zh) 用於直接大量儲存裝置檔案索引之方法、電腦可讀取媒體及系統
JP3551045B2 (ja) データ送受信装置および方法
US8223600B2 (en) Network-attachable, file-accessible storage drive
JP2006048641A (ja) 長期間データアーカイブ用ファイルサーバ
US20080005145A1 (en) Data processing
CN101169795B (zh) 信息处理装置、信息处理方法、程序和程序记录介质
JP2009187544A (ja) 取り外し可能ディスクドライブ格納システム上の追記型モードの実装のための装置
JP2009087320A (ja) Ｎａｓ／ｃａｓ統一ストレージシステムのための方法および装置
JP6095012B2 (ja) メタ情報書込方法、メタ情報読出方法、ファイル管理システム、コンピュータ・システム、プログラムおよびデータ構造
JP2002055995A (ja) 情報処理方法及び装置
JP2007079774A (ja) ファイルシステムの構築方法
US6119144A (en) Apparatus and method for information transfer between a video server and a general purpose computer or the like
US20080016107A1 (en) Data processing
US8090925B2 (en) Storing data streams in memory based on upper and lower stream size thresholds
US20040264933A1 (en) Recording apparatus
KR101125929B1 (ko) 정보 처리 장치, 정보 처리 방법 및 프로그램 기록 매체
JP2005339262A (ja) ファイルシステムおよびその制御方法
JP2007122371A (ja) サーバ装置、データ処理方法、プログラムおよび通信方法
US8886656B2 (en) Data processing
JP2007108853A (ja) 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
JP4984677B2 (ja) 情報処理装置
JP4480592B2 (ja) ファイルシステム

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee