KR100604239B1

KR100604239B1 - 다양한 파일 록킹 프로토콜에 대한 단일 파일 록킹 의미론을 실시하여 파일 서버를 동작하는 방법 및 이 방법에 의해 동작되는 파일 서버

Info

Publication number: KR100604239B1
Application number: KR1019990020519A
Authority: KR
Inventors: 보르안드레아
Original assignee: 네트워크 어플라이언스 인코포레이티드
Priority date: 1999-06-03
Filing date: 1999-06-03
Publication date: 2006-07-24
Also published as: KR20010001364A

Abstract

본 발명은 단일의 다중 프로토콜 록킹 관리 시스템을 사용하여 다수의 다양화된 파일 서버 또는 파일 록킹 프로토콜의 정확한 상호동작을 위한 방법 및 시스템을 제공한다. 파일 서버는 클라이언트 장치가 데이타에 액세스하거나 록킹을 얻도록 하기 전에, 원래의 클라이언트 장치 또는 현재의 록킹에 대한 원래의 프로토콜과 무관하게, 현재의 록킹과 불일치하는지를 결정한다. 제1 프로토콜은 의무적인(mandatory) 파일 오픈과 파일 록킹을 기회적(opportunistic) 파일록킹 기법과 함께 실시하는 반면, 제2 프로토콜은 파일 오픈 의미론을 결여하고 있고 보충적인 바이트 범위 및 파일 록킹만을 제공한다. 파일 록킹을 실시하는 것은 NFS 클라이언트 장치에 의한 손상에 대해 파일 데이타를 보호한다. CIFS 클라이언트 장치는 파일을 오픈하자마자 "옵록(oplock)"(기회적 록킹)을 얻을 수 있다. 클라이언트 장치가 비 CIFS 프로토콜 요구(request)를 "옵록"을 갖는 파일에 대해 했을 때, 파일 서버는 "옵록-정지" 메시지를 CIFS 클라이언트 장치로 보내어, CIFS 클라이언트 장치로 하여금 캐시로 된 기입 동작을 플러시하고 파일을 가능한한 종료하게 한다. NFS 및 NLM 요구가 "옵록"을 정지하도록 하는 것은 파일 데이타의 보전성이 보호됨과 동시에 NFS 클라이언트 장치에 이용가능하게 파일 데이타가 남아있도록 한다. CIFS 클라이언트 장치는 파일 시스템내에 디렉토리에 대한 "변경 모니터" 록킹을 얻을 수 있어, 그 디렉토리에 변화가 있을 때마다 파일 서버에 의해 통지되도록 한다. 파일 서버는 CIFS 및 비CIFS에 의한 디렉토리에 대한 변화를 주목하고, "변경 모니터" 록킹을 갖는 CIFS 클라이언트 장치에 이러한 변화를 통지한다.

다중 프로토콜 록킹

Description

다양한 파일 록킹 프로토콜에 대한 단일 파일 록킹 의미론을 실시하여 파일 서버를 동작하는 방법 및 이 방법에 의해 동작되는 파일 서버{Method of operating a file server by enforcing a uniform file-locking semantics for diverse file-locking protocols, and a file server operated by the method}

도 1은 다중 프로토콜 파일 서버를 포함하는 시스템의 제1 블록도.

도 2는 다중 프로토콜 파일 서버를 포함하는 시스템의 제2 블록도.

도 3은 다중 프로토콜 파일 서버를 동작시키는 방법의 플로우도.

도 4는 다중 프로토콜 파일 서버에서 교차 프로토콜 록킹 관리자(cross-protocol lock manager)를 동작시키는 방법의 처리 플로우도.

도 5는 다중 프로토콜 파일 서버에서 "옵록" 관리자(oplock manager)를 동작시키는 방법의 처리 플로우도.

도 6은 다중 프로토콜 파일 서버에서 변경 통지 관리자(change-notify manager)를 동작시키는 방법의 처리 플로우도.

본 발명은 다중 프로토콜 파일 서버에서의 록킹(locking)에 관한 것이다.

통합 컴퓨터 네트워크에서, 많은 클라이언트 장치가 파일을 공유하는 것이 바람직하다. 한가지 공지된 방법은 그러한 클라이언트 장치로부터의 파일 서버 요구를 수신하고 응답할 수 있는, 파일을 저장하는 네트워크 파일 서버를 제공하는 것이다. 이러한 파일 서버 요구는 파일 서버 프로토콜을 사용하여 만들어지는데, 파일 서버와 클라이언트 장치 양자에 의해 인식되고 고정된다. 이러한 파일은 파일 서버에 저장되므로, 많은 클라이언트 장치가 파일에 대한 동시 액세스를 공유할 수 있는 기회를 갖는다.

이러한 분야의 한가지 문제점은 많은 다양화된 파일 서버 프로토콜 각각이 파일 동작에 대한 의미론(semantics)을 달리하는 점에 있다. 다중 파일 서버 프로토콜을 인식하는 단일(single) 파일 서버를 제공하는 것은 공지되어 있으나, 많은 파일 서버 프로토콜은 파일 록킹과 파일 공유에 대한 다른, 즉, 호환이 안되는 의미론을 갖는다. 호환불가능한 록킹 의미론은 다중의 다양화된 클라이언트 장치에 대해 단일 파일 시스템을 제공하는 데에 있어 장애물을 제공한다. 제1 클라이언트 장치가 제1 파일 서버 프로토콜(제1 파일 록킹 의미론을 갖는)에 기초할 때, 제2 파일 서버 프로토콜(다른 파일 록킹 의미론을 갖는)을 사용하는 제2 클라이언트 장치는 상기 제1 클라이언트 장치에서의 어플리케이션이 완전히 동작 불가능하게 한다. 따라서, 각 파일 서버 프로토콜의 정확한 동작은 다른 모든 파일 서버 프로토콜에 의해 그 파일 록킹 의미론이 일치(conformity)되는 것에 의존한다.

예를 들면, 유닉스 오퍼레이팅 시스템(또는 그 변형)을 사용하는 장치에 사용되는 한 프로토콜은 NFS("Network File System") 프로토콜이다. 윈도우 오퍼레이팅 시스템(또는 그 변형)을 사용하는 장치는 "PC NFS" 구현에 의해 상기 NFS 프로토콜을 또한 사용한다. 상기 NFS 프로토콜은 국적이 없도록 설계되며, 공유에 대하여 록킹되는 파일들에 대한 의미론, 또는 단일 클라이언트 장치에 제한되는 파일들에 대한 의미론을 제공하지 않는다. 한편, 윈도우 오퍼레이팅 시스템을 사용하는 장치에 공통적으로 사용되는 한 프로토콜은 CIFS("Common Internet File System") 프로토콜이다. 이 CIFS 프로토콜은 방대한 규정의 파일 록킹 의미론을 갖고 있으며, CIFS 클라이언트 장치는 그 의미론에 의존하고 그에 따를 것이 예상된다.

공지된 시스템에서, NFS 프로토콜은 부속(adjunct) NLM("Network Lock Manager") 파일 록킹 프로토콜에 의해 증대되어 있다. 그러나, NFS 프로토콜은 NLM 록킹을 단순히 보충적(advisory)으로 취급한다. 이러한 방법은, NFS 어플리케이션(파일 록킹 의미론을 사용)에 파일 록킹 의미론을 제공하는 목적을 달성하지만, NFS 어플리케이션이 이러한 파일 록킹 의미론을 무시하는 것을 방지하지 못하며, 클라이언트 장치가 다중의 다양한 파일 서버 프로토콜의 파일 록킹 의미론에 기초하는 것을 허용하지도 않는다.

따라서, 다중의 다양화된 파일 서버 프로토콜을 사용하는 클라이언트 장치에서 파일 록킹 의미론을 실시하기 위한 방법 및 시스템을 제공하는 것이 바람직하다. 이러한 장점은 파일 록킹 의미론의 단일세트(uniform set)가 다중 프로토콜 파일 서버의 커널로 통합되고 상기 서버에 의해 인식된 다양한 파일 서버 프로토콜 중 어느 하나를 사용하는 클라이언트 장치에 대해 실시되는 본 발명의 실시예를 통해 달성된다. 보다 바람직한 실시예에서, CIFS 프로토콜의 특정 파일 록킹 의미론은, 네트워크 파일 서버상에 위치하는 공유된 파일 시스템에 클라이언트가 액세스하는 동안 데이타 보전성(data integrity)을 유지하도록, NFS 클라이언트 장치가 CIFS 장치와 상호 동작하기 위해 구현된다.

본 발명은 다중의 다양화된 파일 서버 프로토콜의 정확한 상호동작을 위한 방법 및 시스템을 제공하는 것이다. 다중의 다양화된 파일 서버 프로토콜을 인식하는 파일 서버는 단일(uniform)의 다중 프로토콜 록킹 관리 시스템(단일의 파일 록킹 의미론을 포함하는)을 제공하는데, 그로 인해 모든 클라이언트 장치 및 모든 인식된 파일 서버 프로토콜에 대해 실시할 수 있다. 보다 바람직한 실시예에서, 제1 파일 서버 프로토콜(예를 들면, CIFS)은 의무적인 파일 오픈 및 파일 록킹 의미론을 기회적인 파일-록킹 기법과 함께 실시하는 반면, 제2 파일 서버 프로토콜(예를 들면, 보조 프로토콜 NLM과 함께 NFS)은 보충 바이트 범위 및 파일 록킹 의미론만을 제공한다.

단일 파일 록킹 의미론은 임의의 클라이언트 장치가 데이타를 기입 또는 판독하거나 새로운 파일 록킹 또는 바이트 범위 록킹을 얻도록 허용하기 전에, 현재의 록킹에 대한 원래의 파일 서버 프로토콜 또는 원래의 파일 록킹 프로토콜 및 원래의 클라이언트 장치에 무관하게, 새로운 록킹이 현재의 록킹과 불일치한지 여부를 결정하게 한다. CIFS 클라이언트 장치가 데이타를 기입 또는 판독하고자 할 경우, 파일 서버는 상기 클라이언트가 파일을 오픈할 때 상술한 체크를 수행한다. CIFS 클라이언트 장치가 바이트 범위 록킹을 요구하는 경우에는, 파일 서버는 상기 클라이언트 장치가 바이트 범위 록킹을 할 때 그러한 체크를 수행한다. NFS 클 라이언트 장치의 경우에는, 파일 서버는 상기 클라이언트 장치가 실제로 기입 또는 판독 요구를 보냈을 때 또는 NFS 클라이언트 장치가 그 바이트 범위를 기입 또는 판독하려는 의도를 나타내는 NLM 바이트 범위 록킹을 요구할 때 그러한 체크를 수행한다. 파일 록킹 의미론을 실시하는 것은 NFS 클라이언트 장치에 대한 파일 데이타를 보호한다.

본 발명의 제2 측면에서, CIFS 클라이언트 장치는 파일을 열자마자, "옵록"(oplock:기회적 록킹), 즉, 파일을 오직 그 한 클라이언트만이 판독 또는 기입할 수 있도록 하는 배타적 파일 록킹을 얻을 수 있다. 클라이언트 장치가 기회적 록킹 파일에 대한 비 CIFS 프로토콜(즉, NFS 또는 NLM) 요구를 할 때, 파일 서버는 옵록 정지 메시지(oplock-break message)를 보내어, CIFS 클라이언트 장치에 캐시 기입 동작을 플러시(flush)하고 파일을 종료하는 것이 가능하도록 하는 기회를 준다. NFS 및 NLM 요구가 "옵록"을 정지할 수 있도록 하는 것은 파일 데이타의 보전도를 유지함과 동시에 파일 데이타가 NFS 클라이언트 장치에 유용하게 남아있는 것을 보장한다.

본 발명의 제3 측면은, CIFS 클라이언트 장치가 파일 시스템내의 디렉토리에 대한 "변경 모니터" 록킹을 얻을 수 있어서, 그 디렉토리에 변경이 있을 때는 언제나 파일 서버에 의해 통지된다(디렉토리에 대한 변화는 그 디렉토리내의 파일을 생성하거나, 제거하거나, 이름을 바꾸거나, 혹은 파일을 그 디렉토리 내로 또는 밖으로 이동시키는 것을 포함한다). 파일 서버는 CIFS 클라이언트 장치 및 비 CIFS 클라이언트 장치에 의해 디렉토리에 대한 변경을 알게 되고 "변경 모니터" 록킹을 갖 는 CIFS 클라이언트 장치에 그러한 변경을 통지한다.

이하에서는, 본 발명의 바람직한 실시예가 바람직한 처리 단계와 데이타 구조에 관해 설명된다. 본 발명의 분야의 당업자는 본 발명의 실시예가 범용 프로세서, 특정 목적의 프로세서 또는 여기에 기재된 특정처리단계와 데이타 구조를 위한 다른 회로를 사용하여 구현될 수 있는 것과, 이하에 기재된 처리단계와 데이타 구조의 구현은 여타의 실험 등을 요하지 않는 것도 알 수 있을 것이다.

시스템 아키텍처(클라이언트/서버)

도 1은 다중 프로토콜 파일 서버를 포함하는 시스템의 제1 블록도이다.

시스템(100)은 파일 서버(110), 컴퓨터 네트워크(120) 및 복수의 클라이언트 장치(130)를 포함한다.

파일 서버(110)는 프로세서(111) 및 대용량 기억장치(112)를 포함한다. 대용량 기억장치(112)는 저장 및 검색용 데이타를 갖는 파일 세트(113)를 저장하고 검색할 수 있다. 프로세서(111)는 네트워크(120)로부터 요구 메시지(140) 시퀀스를 수신할 수 있고, 이러한 메시지를 데이타와 명령으로 분류하고 파일(113)을 대용량 기억장치(112)상에서 조정하고 상기 명령 및 데이타에 응하여 응답 메시지를 보낸다.

파일 서버(110)와 클라이언트 장치(130)는 네트워크(120)에 접속되고 상기 네트워크(120)상에 전달된 메시지(140)를 사용하여 통신한다. 이러한 메시지(140)는 파일 서버(110)로 클라이언트 장치(130)에 의해 전송된 파일 시스템 요구와 클라이언트 장치(130)로 파일 서버(110)에 의해 전송된 파일 시스템 응답을 포함한다.

시스템 아키덱처(파일 록킹 의미론)

도 2는 다중 프로토콜 파일 서버를 포함하는 시스템의 제2 블록도이다.

시스템(100)은 유닉스 클라이언트 장치(201), PC NFS 윈도우 클라이언트 장치(202) 및 CIFS 윈도우 클라이언트 장치(203)를 포함하는 클라이언트 장치(130) 세트를 포함한다. 유닉스 클라이언트 장치(201)는 유닉스 오퍼레이팅 시스템을 실행하고 유닉스/NFS 파일 서버 프로토콜을 사용한다. PC NFS 윈도우 클라이언트 장치(202)는 윈도우 오퍼레이팅 시스템을 실행하고 PC NFS 파일 서버 프로토콜을 사용한다. CIFS 윈도우 클라이언트 장치(203)는 윈도우 오퍼레이팅 시스템을 실행하고 CIFS 파일 서버 프로토콜을 사용한다.

유닉스 클라이언트 장치(201) 및 PC NFS 윈도우 클라이언트 장치(202)는 NFS 파일 서버 프로토콜을 사용하는 파일 서버(110)와 통신하며, 상기 프로토콜은 NFS 파일 서버 프로토콜 파서(212:NFS file server protocol parser)에 의해 파일 서버(110)에서 인식된다. CIFS 윈도우 클라이언트 장치(203)는 CIFS 파일 서버 프로토콜을 사용하는 파일 서버(110)와 통신하며, 그러한 프로토콜은 CIFS 파일 서버 프로토콜 파서(212)에 의해 파일 서버(110)에서 인식된다. NFS 파일 서버 프로토콜 및 CIFS 파일 서버 프로토콜 중 어느 하나를 사용하는 메시지는 프로세서(111)에 의해 파싱되고 "옵록" 관리자(220)에 의해 처리된다.

"옵록" 관리자(220)는 CIFS "옵록"을 갖는 파일(113)로의 액세스를 관리한다. 그 동작은 도 3 및 도 5를 참조하여 더 상세히 설명된다. "옵록" 관리자(220)는 교차 프로토콜 록킹 관리자(230)에 접속된다.

교차 프로토콜 록킹 관리자(230)는 파일 서버(110)의 파일 록킹 의미론을 관리한다. 관리자(230)는 4개의 형식의 록킹-CIFS 바이트 범위 록킹(241), CIFS 파일 록킹(242), PC NFS(NLM) 파일 록킹(243) 및 NLM 바이트 범위 록킹(244)-에 관한 정보를 처리하고 기록한다. 단일 파일-록킹 의미론을 실시하는데 있어서 교차 프로토콜 록킹 관리자(230)의 동작은 도 3 및 4를 참조하여 상세히 설명될 것이다.

서로 다른 파일 록킹 의미론

도 2를 참조하면 알 수 있듯이, 파일 서버 요구 메시지(140)는 유닉스 클라이언트 장치(201), PC NFS 윈도우 클라이언트 장치(202), 또는 CIFS 윈도우 클라이언트 장치(203)로부터 수신될 수 있고 NFS 파일 서버 프로토콜 또는 CIFS 파일 서버 프로토콜을 사용할 수 있다. 각각 서로 다른 파일 서버 프로토콜을 사용하는 것에 더하여, 각 클라이언트 장치(130)의 타입도 파일 서버(110)에 의해 제공된 파일 록킹의 다른 모델을 갖는다.

특히, NFS 파일 서버 프로토콜은 파일 오픈 또는 파일 종료(file-close) 의미론의 소정 형태없이 파일 시스템 동작을 수행하는 것을 제공한다. 이러한 NFS 파일 시스템 동작은 파일 데이타에 대한 기입 또는 판독 또는 파일 시스템 조정(즉, 디렉토리에 대한 기입 및 판독 동작)을 포함한다. 파일 시스템 조정은 파일 또는 디렉토리를 생성하는 것, 이름을 바꾸는 것, 한 디렉토리로부터 다른 디렉토리로 파일을 이동시키는 것 또는 파일 시스템으로부터 파일 또는 디렉토리를 제거하는 것을 포함한다.

이러한 NLM 보조 프로토콜은 파일에 대한 바이트 범위 록킹을 얻는 것과 해제하는 것을 제공한다. 이러한 바이트 범위 록킹은 다른 컴플라이언트(compliant) 어플리케이션(예를 들면, 다른 클라이언트 장치(130)에서)이 특정 바이트 범위에 기입하는 것을 방지하도록 유도하는 "판독 록킹"일 수 있다. 이러한 바이트 범위록킹은 또한 다른 컴플라이언트 어플리케이션이 특정 바이트 범위로부터 판독하거나 그에 기입하는 것을 방지하도록 유도할 수 있는 "기입 록킹"일 수 있다.

CIFS 파일 서버 프로토콜은 오픈된 파일(113)내에서 데이타에 대한 기입 또는 판독 동작을 시도하기 전에 파일 오픈 동작을 수행하고 파일(113)상의 파일 록킹을 얻는 것을 제공한다. 파일 오픈 시간에, CIFS 클라이언트 장치(130)는 소망하는 액세스 모드(판독전용, 기입전용 또는 판독-기입)를 특정할 수 있고 동일한 파일(113)을 오픈하려고 하는 다른 클라이언트 장치(130)상에 거부 모드(deny-mode)[비거부(deny-none), 판독 거부, 기입 거부, 총 거부(deny-all)]를 특정할 수 있다. 그 후에, CIFS 파일 시스템 동작은 파일 오픈이 얻어진 그 액세스 모드에 대해서만 체크될 필요가 있다. CIFS 클라이언트 장치(130)는 그 장치가 오픈으로 유지하는 파일내의 바이트 범위에 대한 바이트 범위 록킹을 특정할 수 있다. 바이트 범위 록킹은 "기입 록킹"(판독-기입 액세스 모드와 총 거부인 거부 모드를 갖는)이라고 불리는 배타적인 록킹이거나 "판독 록킹"(판독 전용의 액세스 모드와 기입거부인 거부 모드를 갖는)인 비배타 록킹이다.

파일 서버(110)는 액세스 모드와 거부 모드를 결합하는 록킹 모드를 결정한다. 여기에서 사용되는 바와 같이, "록킹 모드"라는 용어는 액세스 모드와 거부 모드를 결합하는 파일 서버(110)에 의해 부여된 단일 록킹 모드(uniform lock mode)를 의미한다.

파일 오픈 시에, CIFS 클라이언트 장치(130)는 다른 클라이언트 장치(130)가 파일을 사용하려고 하지 않은 한, 파일을 오픈하는 CIFS 클라이언트 장치(130)가 그 파일에 대해 배타적인 액세스를 갖게 하는 "옵록"(opportunistic lock)을 또한 얻을 수 있다. 이러한 "옵록"은 다른 클라이언트 장치(130)에 의해 시도된 액세스에 의해 "옵록"의 배타성이 종결될 수 있다는 제한하에서 해당 클라이언트 장치(130)에 반드시 필요한 것보다 그 파일에 대한 더 높은 배타성을 제공한다.

파일 서버(110)는 NFS(보조 프로토콜 NLM이 있거나 또는 없는) 또는 CIFS를 사용하여 클라이언트 장치(130)간에 정확한 상호동작을 제공한다. 정확한 상호동작을 제공하기 위해, 파일 서버(110)는 단일 파일 록킹 의미론을 제공한다. 보다 바람직한 실시예에서, 단일 파일 록킹 의미론은 다음과 같은 효과를 갖는다:

파일 서버(110)는 기입 거부 또는 총 거부와 같은 거부 모드를 갖는 CIFS 클라이언트에 의해 이미 오픈되거나 사용중인 파일(113)에 유닉스 클라이언트 장치(201)가 데이타를 중복기입하는 NFS 기입 동작을 수행하는 것을 방지한다.

파일 서버(110)는 유닉스 클라이언트 장치(201)와 PC NFS 윈도우 클라이언트 장치(202)가 CIFS 클라이언트에 의해 이미 오픈되어 사용중인 파일(113)을 제거하거나 이름을 바꾸는 NFS 파일 시스템 동작을 수행하는 것을 방지한다.

유닉스 클라이언트 장치(201) 또는 PC NFS 윈도우 클라이언트 장치(202)가, CIFS 클라이언트에 의해 "옵록"된 파일(113)에 데이타를 소거, 이름 변경 또는 기입하는 NFS 요구를 할 때, 파일 서버(110)는 파일(113)에 대해 CIFS "옵록" 의미론을 실시할 것이다. 파일 서버(110)는 "옵록" 정지 메시지(140)를 "옵록"을 홀딩하는 클라이언트 장치(130)로 보내고 클라이언트 장치(130)로부터 응답을 받는다. 클라이언트 장치(130)가 파일(113)을 종료하면, NFS 요구는 처리될 수 있고 파일 서버(110)는 상기 요구가 처리되도록 한다.

유닉스 클라이언트 장치(201) 또는 PC NFS 윈도우 클라이언트 장치(202)가 CIFS 클라이언트에 의해 "옵록" 된 파일(113)로부터 데이타를 판독하는 NFS 요구를 할 때, 파일 서버(110)는 CIFS "옵록" 의미론을 파일(113)에 대해 실시할 것이다. 파일 서버(110)는 "옵록" 정지 메시지(140)를 "옵록"을 유지하는 클라이언트 장치(130)로 보내고 그로부터 응답을 받는다. 클라이언트 장치(130)가 파일(113)을 닫거나 파일 서버(110)로 그 기입 캐시(write cache)를 플러시할 때, NFS 요구는 처리되고 파일 서버(110)는 그것을 처리되도록 한다.

파일 서버(110)는 특정 록킹 모드에 대하여 CIFS 윈도우 클라이언트 장치(203)로부터의 파일 오픈 요구, PC NFS 윈도우 클라이언트 장치(202)로부터의 NLM 파일 록킹 요구에 대한 상호 호환성을 테스트한다. NLM "파일 록킹"이라는 용어는 공지된 NLM "공유 록킹"이라는 용어대신에 사용되는 것이며, 더 자세한 사항은 본 발명에 참조로 병합되는 "X/Open CAE Specification:Protocols for X/Open Interworking:XNFS, Issue 4(X/Open Document Number C218)"에 기술되어 있다. 특정 록킹 모드는 요구된 액세스 모드와 거부 모드를 결합하여 파일 서버(110)에 의해 결정된다.

이러한 효과를 제공하기 위해, 파일 서버(110)는 다음과 같은 록킹 관리 동 작을 수행한다.

CIFS 파일 오픈 요구 메시지(140)를 수신하자마자, 파일 서버(110)는 현재의 CIFS 및 NLM 파일 록킹과의 충돌 및 현재의 NLM 바이트 범위 록킹에 대한 충돌에 대해 파일 오픈 요구를 테스트한다. 새롭게 요구된 파일 록킹과의 비교목적으로, 파일 서버(110)는 현재의 NLM 바이트 범위 록킹을 비 거부인 거부 모드를 갖는 것으로 취급하고, 비배타 록킹용 판독전용 액세스 모드 및 배타 록킹용 판독-기입 액세스 모드를 갖는 것으로 취급한다.

CIFS 바이트 범위 록킹 요구 메시지(140)를 수신하자마자, 파일 서버(110)는 현재의 CIFS 및 NLM 바이트 범위 록킹과의 충돌에 대해 바이트 범위 록킹 요구를 테스트한다.

NLM 바이트 범위 록킹 요구 메시지(140)를 수신하자마자, 파일 서버(110)는 현재의 CIFS 및 NLM 바이트 범위 록킹과의 충돌 및 현재의 CIFS 파일 록킹과의 충돌에 대한 바이트 범위 록킹 요구를 테스트한다.

NLM 파일 록킹 요구 메시지(140)[파일 오픈 요구 메시지(140)를 시뮬레이션하기 위해 사용됨]를 PC NFS 클라이언트 장치(130)로부터 수신하자마자, 파일 서버(110)는 NLM 파일 록킹 요구를 현재의 CIFS 및 NLM 파일 록킹과의 충돌 및 현재의 NLM 바이트 범위 록킹과의 충돌에 대해 테스트한다. 새롭게 요구된 NLM 파일 록킹과의 비교 목적으로, 파일 서버(110)는 현재의 NLM 바이트 범위 록킹을 비거부인 거부 모드와 비배타 록킹용 판독전용 액세스모드와 배타 록킹용 판독-기입 액세스 모드를 갖는 것으로 취급한다.

동작 방법(다중 프로토콜 파일 서버)

도 3은 다중 프로토콜 파일 서버를 동작하는 방법을 나타내는 처리 플로우도이다.

다중 프로토콜 파일 서버를 동작하는 방법(300)은 적어도 하나의 클라이언트 장치(130)와의 상호동작으로 파일 서버(110)에 의해 수행되는 한 세트의 처리단계와 플로우 지점을 포함한다.

플로우지점(310)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)를 수신할 준비를 한다.

단계(311)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)를 수신하고 파싱한다. 파일 서버(110)는, 파일 서버 요구 메시지(140)가 NFS 파일 서버 프로토콜, NLM 파일 록킹 프로토콜, 또는 CIFS 파일 서버 프로토콜을 사용하는지를 결정한다. 파일 서버 요구 메시지(140)가 NFS 파일 서버 프로토콜 또는 NLM 파일 록킹 프로토콜을 사용하면, 방법(300)은 단계(312)에서 계속된다. 파일 서버 요구 메시지(140)가 CIFS 파일 서버 프로토콜을 사용하면, 방법(300)은 단계(313)에서 계속된다.

단계(312)에서, 파일 서버(110)는 요구 메시지(140)가 파일 시스템 동작(예를 들면, 데이타를 판독 또는 기입하거나 디렉토리를 변경하는 것)을 수행하는 NFS 파일 서버 요구를 포함하는 것인지를 결정한다. 또한, 파일 서버(110)는 요구 메시지(140)가 NLM 바이트 범위 록킹을 얻기 위한 NLM 파일 록킹 요구를 포함하는지 여부도 결정한다. 어느 경우든, 방법(300)은 플로우지점(320)에서 계속된다.

단계(313)에서, 파일 서버(110)는 CIFS 바이트 범위 록킹을 얻기 위해 혹은 CIFS 파일 오픈 동작을 수행하기 위해 파일 서버 요구 메시지(140)가 CIFS 판독 또는 기입 동작을 수행하는 것인지 여부를 결정한다. 파일 서버 요구 메시지(140)가 CIFS 바이트 범위 록킹을 얻거나 CIFS 파일 오픈 동작을 수행하면, 방법(300)은 플로우 지점(320)에서 계속된다. 파일 서버 요구 메시지(140)가 CIFS 판독 또는 기입 동작을 수행하면, 방법은 플로우 지점(330)에서 계속된다. 파일 서버 요구 메시지(140)가 CIFS "변경 통지" 요구이면, 방법은 플로우 지점(350)에서 계속된다(변경 통지 요구는 도 6을 참조하여 더 설명된다).

플로우 지점(320)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)에 의해 요구된 동작과 파일(113)의 파일 록킹 상태를 비교할 준비를 한다. 파일(113)의 파일 록킹 상태는 파일(113)에 대한 현재의 파일 록킹 및 바이트 범위 록킹을 포함한다.

단계(321)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)의 대상인 파일(113)을 결정하고, 파일(113)이 "옵록"인지 여부를 결정한다. 파일(113)이 "옵록"이면, 방법(300)은 단계(322)에서 계속된다. 파일(113)이 "옵록"으로 되지 않으면, 방법(300)은 단계(323)로 계속된다.

단계(322)에서, 파일 서버(110)는 설명된 바와 같이 "옵록"을 정지한다. 단계(322)의 수행은 도 5를 참조하여 더 설명된다. "옵록"을 정지하는 것은 파일(113)의 파일 록킹 상태가 변화되도록 할 수 있다.

단계(323)에서, 파일 서버(110)는 단일 파일 록킹 의미론을 사용하여, 요구된 동작과 파일(113)의 파일 록킹 상태를 비교한다. 이러한 단계에서, 요구된 동작은 NFS 판독 혹은 기입 동작, NFS 또는 CIFS 디렉토리 변경 동작, NLM 파일 록킹 또는 바이트 범위 록킹을 얻는 시도 또는 CIFS 파일 오픈 동작일 수 있다. 단계(323)과 단일 파일 록킹 의미론의 수행은 도 4를 참조하여 더 설명된다. 이러한 비교가 요구 동작이 허용가능하다는 것을 나타내면, 방법(300)은 단계(324)에서 계속된다. 요구 동작이 허용가능하지 않으면, 방법(300)은 단계(325)에서 계속된다.

단계(324)에서, 파일 서버(110)는 요구 동작을 수행한다. 방법(300)은 플로우 지점(340)에서 계속된다.

단계(325)에서, 파일 서버(110)는 요구 동작을 수행하는 것을 거절하고, 에러 메시지로 클라이언트 장치(130)에 응답한다. 방법(300)은 플로우 지점(340)에서 계속된다.

플로우 지점(330)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)에 의해 요구된 동작과 파일(113)의 파일 록킹 상태를 비교할 것을 준비한다.

플로우 지점(350)에서, 파일 서버(110)는 변경 통지 동작을 수행할 것을 준비한다.

단계(351)에서, 제1 CIFS 클라이언트 장치(130)는 디렉토리에 대한 파일 록킹(파일 시스템 요구 메시지(140)를 사용하여 디렉토리를 열도록)을 요구하고 디렉토리에 대한 파일 록킹을 디렉토리에 관한 변경 모니터링 록킹으로 변환한다. 이러한 단계(351)의 수행은 도 6을 참조하여 더 설명될 것이다.

플로우 지점(340)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)에 대 해 응답하고, 방법(300)은 파일 서버 요구 메시지(140)에 관해 종료된다.

동작 방법(교차 프로토콜 록킹 관리자)

도 4는 다중 프로토콜 파일 서버에서 교차 프로토콜 록킹관리자를 동작시키는 방법의 처리 플로우도를 도시한다.

다중 프로토콜 파일 서버에서 교차 프로토콜 록킹 관리자를 동작시키는 방법(400)은 적어도 한 클라이언트 장치(130)과 상호 동작하여 파일 서버(110)에 의해 수행되는 처리 단계 세트와 플로우 지점을 포함한다.

플로우 지점(410)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)에서의 요구 동작과 파일(113)의 파일 록킹 상태를 비교할 준비를 한다.

파일 서버(110)는 단일 파일 록킹 의미론을 사용하여, 요구된 동작의 파일 록킹 특성을 동일한 방식으로 파일 서버 프로토콜로부터 모델링한다. 단일 파일 록킹 의미론은 파일 록킹의 단일 세트를 인식하고, 각각이 클라이언트 장치(130)를 요구하기 위한 액세스 모드와 다른 모든 클라이언트 장치(130)에 대한 거부 모드를 포함한다.

보다 바람직한 실시예에서, 액세스 모드는 3가지 중 하나인데, 즉, 판독 전용, 기입 전용 또는 판독-기입이다. 유사하게, 보다 바람직한 실시예에서, 거부 모드는 비거부, 판독 거부, 기입 거부 또는 총 거부, 4개 중 하나일 수 있다.

제1 클라이언트 장치(130)가 파일(113)에 대해 파일 록킹을 얻은 후에, 제2 클라이언트 장치(130)에 의해 요청을 받은 파일 서버(110)에 의해 결정된 록킹 모드가 파일(113)의 파일 록킹 상태와 호환가능하다면 제2 클라이언트 장치(130)는 그 파일(113)로만 액세스할 수 있다. 예를 들면, 제1 클라이언트 장치(130)는 파일(113)에 대한 파일 록킹을 기입 거부인 거부 모드로서 얻을 수 있다. 제2 NFS 클라이언트 장치(130)가 파일(113)로 기입하도록 시도하거나, 제2 CIFS 클라이언트 장치(130)가 기입 액세스를 포함하는 액세스 모드로 파일(113)을 오픈하도록 시도할 수 있다. 어떠한 경우든(파일(113)의 파일 록킹이 기회적 록킹이 아니면), 파일 서버(110)는 제2 클라이언트 장치(130)에 의한 요구를 거부할 것이다.

설명된 바와 같이, 파일 서버(110)는 제2 클라이언트 장치(130)에 의해 사용된 파일 서버 프로토콜에 응하여, 제2 클라이언트 장치(130)에 의해 서로 다른 시간에 요구된 액세스를 비교한다.

제2 클라이언트 장치(130)가 파일(113)을 오픈하기 위해 CIFS 파일 서버 프로토콜을 사용하면, 파일 서버(110)는 파일 오픈시에 파일(113)의 파일 록킹 상태를 체크한다.

제2 클라이언트 장치(130)가 파일(113)을 판독하거나 기입하기 위해 NFS 파일 서버 프로토콜을 사용하면, 파일 서버(110)는 파일(113)의 파일 록킹 상태를 실제 파일 시스템 동작시에 체크한다. 또한, 이는 파일(113)을 이동하고, 제거하고 이름을 바꾸는 동작과 같이 제1 클라이언트 장치(130)로부터 파일을 제거하는 효과를 갖는 파일 시스템 동작에 적용된다.

제2 클라이언트 장치(130)가 바이트 범위 록킹을 요구하기 위해 CIFS 파일 서버 프로토콜을 사용하면, 바이트 범위 록킹이 요구되는 때에 파일 서버(110)는 현재의 CIFS 또는 NLM 바이트 범위 록킹과의 충돌에 대해 파일(113)의 파일 록킹 상태를 체크한다. 파일 서버(110)는 바이트 범위 록킹이 요구되는 때에 CIFS 파일 록킹과의 충돌에 대해 체크하지 않는데, 이는 파일 오픈시에 체크되기 때문이다.

제2 클라이언트 장치(130)가 바이트 범위 록킹을 요구하기 위해 NLM 프로토콜을 사용하면, 파일 서버(110)는 현재의 CIFS 또는 NLM 바이트 범위 록킹 및 CIFS 파일 록킹과의 충돌에 대해 파일(113)의 파일 록킹 상태를 체크한다.

단계(421)에서, 파일 서버(110)는 파일(113)과 관련된 하나 이상의 파일 록킹이 이미 있는 지 여부를 결정한다. 그렇다면, 방법(400)은 단계(422)로 계속되며, 그렇지 않으면, 방법은 단계(411)로 계속된다.

단계(422)에서, 파일 서버(110)는 파일(113)과 이미 관련된 파일 록킹을 파일(113)과 관련된 하나의 동등한 파일 록킹으로 결합한다. 이러한 단계(422)를 수행하기 위해, 파일 서버(110)는 표 1에서 모든 기존 파일 록킹이 함께 축적될 때까지 축적 파일 록킹(cumulative file lock)과 각 기존 파일 록킹(pre-exisitng file lock)을 교차인덱스시킨다.

표 1은 단일 파일 록킹 의미론을 갖는 다중 프로토콜 파일 서버내의 록킹 변환 테이블을 도시한 것이다.

[표 1] 록킹 변환표

현재의 파일 록킹 모드

새 로 운 록 킹 모 드

NULL

A:R D:DN

A:W D:DN

A:RW D:DN

A:R D:DR

A:W D:DR

A:RW D:DW

A:R D:DW

A:W D:DW

A:RW D:DW

A:Any D:DA

NULL

A:R D:DN

A:W D:DN

A:RW D:DN

A:R D:DR

A:W D:DR

A:RW D:DR

A:R D:DW

A:W D:DW

A:RW D:DW

A:Any D:DA

A:R D:DN

A:RW D:DN

A:R D:DR

A:RW D:DR

A:R D:DW

A:RW D:DW

A:Any D:DA

A:W D:DN

A:RW D:DN

A:W D:DN

A:RW D:DN

A:RW D:DR

A:W D:DR

A:RW D:DR

A:RW D:DW

A:W D:DW

A:RW D:DW

A:Any D:DA

A:RW D:DN

A:RW D:DR

A:RW D:DW

A:Any D:DA

A:R D:DR

A:RW D:DR

A:R D:DR

A:RW D:DR

A:Any D:DA

A:W D:DR

A:RW D:DR

A:W D:DR

A:RW D:DR

A:W D:DR

A:RW D:DR

A:Any D:DA

A:RW D:DR

A:Any D:DA

A:R D:DW

A:RW D:DW

A:Any D:DA

A:R D:DW

A:RW D:DW

A:Any D:DA

A:W D:DW

A:RW D:DW

A:W D:DW

A:RW D:DW

A:Any D:DA

A:RW D:DW

A:W D:DW

A:RW D:DW

A:Any D:DA

A:RW D:DW

A:Any D:DA

A:RW D:DW

A:Any D:DA

A: 액세스 모드(R = 판독, W = 기입 RW= 판독-기입 Any= 판독, 기입 또는

판독-기입 중 어느 하나)

D: 거부 모드(DN = 비거부, DR = 판독 거부, DW = 기입 거부, DA = 총 거부)

단계(411)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)에서 요구 동작의 속성을 결정한다. 요구 동작이 CIFS 파일 오픈 동작이면, 방법(400)은 단계(423)로 계속된다. 요구 동작이 NFS 파일 서버 동작이면, 방법(400)은 단계(431)로 계속된다. 요구 동작이 바이트 범위 록킹에 대한 CIFS 요구 혹은 NLM 요구이면, 파일 시스템(110)은 단계(441)에서 계속된다.

단계(423)에서, 파일 서버(110)는 파일(113)과 이미 관련된 파일 록킹과 제2 클라이언트 장치(130)에 의해 요구된 파일 오픈을 비교한다. 이러한 단계(423)를 수행하기 위해, 파일 서버(110)는 표 2에서 기존의 파일 록킹과 요구된 새로운 액세스 모드 및 거부 모드를 교차 인덱스시키고, 요구된 새로운 액세스 모드와 거부 모드를 관련 표 엔트리에 따라 허용하거나 거부한다.

파일 서버(110)가 요구된 새로운 액세스 모드와 거부 모드를 허용하면, 방법(400)은 단계(424)를 수행한다. 파일 서버(110)가 요구된 새로운 액세스 모드와 거부 모드를 거부하면, 방법(400)은 단계(424)를 수행하지 않는다.

표 2는 단일 파일 록킹 의미론을 갖는 다중 프로토콜 파일 서버 내에서 시도된 파일 록킹의 교차 인덱스를 나타낸다.

[표 2] 다중 프로토콜 록킹 호환 매트릭스

기존의 파일 록킹

요구된 새모드

NULL

A:R D:DN

A:R D:DR

A:R D:DW

A:W D:DN

A:W D:DR

A:W D:DW

A:RW D:DN

A:RW D:DR

A:RW D:DW

A:Any D:DA

NULL

V

A:R D:DN

V

X

V

X

V

X

V

X

A:R D:DR

V

X

V

X

V

X

V

X

A:R D:DW

V

X

V

X

A:W D:DN

V

X

V

X

V

X

A:W D:DR

V

X

V

X

A:W D:DW

V

X

A:RW D:DN

V

X

V

X

V

X

A:RW D:DR

V

X

V

X

A:RW D:DW

V

X

A:Any D:DA

V

X

A: 액세스 모드, D: 거부 모드

V: 새 요구가 허용됨, X: 새 요구가 거부됨

표 2에 나타나 바와 같이, 기존의 파일 록킹과 요구된 새로운 액세스 모드와 거부 모드의 각 쌍은 새로운 액세스 모드 및 거부 모드를 허용하거나 거부하는 관 련 결정을 갖는다.

파일 서버(110)가 현재의 CIFS 파일 록킹과 파일 오픈 동작을 수행하는 새로운 요구간의 충돌을 체크한다면, 현재의 CIFS 파일 록킹은 새로운 파일 오픈 요구에서 요구된 액세스 모드와 거부 모드에 대해 교차 인덱스된다.

파일 서버(110)가 현재의 파일 록킹과 파일 판독 또는 기입 동작을 수행하는 새로운 NFS 요구간의 충돌을 체크하면, 집합 록킹 모드(aggregate lock mode:기존 파일 록킹의 조합)는 새로운 요구를 수행하는데 필요한 액세스 모드에 대해 교차 인덱스된다.

파일 서버(110)가 현재의 파일 록킹 또는 바이트 범위 록킹과 NLM 바이트 범위 록킹에 대한 새로운 요구간의 충돌을 체크하면, 기존 파일 록킹과 바이트 범위 록킹은 새로운 NLM 바이트 범위 록킹과 동등한 록킹 모드에 대해 교차 인덱스된다. 현재의 파일 록킹과 비교하기 위해, 파일 서버(100)는 새로이 요구된 NLM 바이트 범위 록킹을 비거부인 거부 모드를 갖고, 비배타 록킹에 대해 판독 전용 액세스 모드("판독 록킹")와 배타 록킹에 대해 판독-기입 액세스 모드("기입 록킹")를 갖는 것으로 취급한다. 현재의 바이트 범위 록킹을 비교하기 위해, 파일 서버(110)는 새롭게 요구된 NLM 바이트 범위 록킹을, 판독 전용 액세스 모드와 판독 록킹에 대한 기입 거부인 거부 모드를 갖고, 판독-기입 액세스 모드와 기입 록킹에 대한 총거부인 거부 모드를 갖는 것으로 취급한다.

방법(400)은 플로우 지점(450)에서 계속된다.

단계(431)에서, 파일 서버(100)는 파일(113)의 파일 록킹 상태와 제2 클라이 언트 장치(130)에 의해 요구된 동작을 비교한다. 이러한 단계(431)를 수행하기 위해, 파일 서버(100)는 파일 록킹에 대한 거부 모드를 요구된 동작과 비교하고, 그에 응하여 요구된 동작을 허용하거나 거부한다.

방법(400)은 플로우 지점(450)에서 계속된다.

단계(441)에서, 파일 서버(110)는 파일(113)의 파일 록킹 상태와 제2 클라이언트 장치(130)에 의해 요구된 NLM 바이트 범위 록킹을 비교한다. 보다 바람직한 실시예에서, CIFS 바이트 범위 록킹 요구는 이전의 CIFS 파일 오픈 동작(이 동작에서 현재의 파일 록킹이 이미 체크됨)을 요구하기 때문에 바이트 범위 록킹에 대해서만 체크된다. 이러한 단계(441)를 수행하기 위해, 파일 서버(110)는 현재의 파일 록킹 상태와 요구된 바이트 범위 록킹을 표 3에서 교차 인덱스시키고, 관련 표 엔트리에 응하여 요구된 바이트 범위 록킹을 허용하거나 거부한다.

파일 서버(110)가 요구된 새로운 NLM 바이트 범위 록킹을 허용하면, 방법(400)은 단계(442)를 수행한다. 파일 서버(110)가 요구된 새로운 바이트 범위 록킹을 거부하면, 방법(400)은 단계(442)를 수행하지 않는다.

표 3은 단일화 파일 록킹 의미론을 갖는 다중 프로토콜 파일 서버에서 현재의 파일 록킹과 새롭게 요구된 NLM 바이트 범위 록킹의 교차 인덱스를 나타낸다.

[표 3] 새로운 NLM 바이트 범위 록킹과 현재의 파일 록킹과의 호환성

존재하는 파일 록킹 모드
	None	A:R D:DN	A:R D:DR	A:R D:DW	A:W D:DN	A:W D:DR	A:W D:DW	A:RW D:DN	A:RW D:DR	A:RW D:DW	A:Any D:DA
기입록킹	V	V	V	X	V	V	X	V	V	X	X
판독 록킹	V	V	X	V	V	X	V	V	X	V	X

A: 액세스 모드, D: 거부 모드

V: 새 NLM 바이트 범위 록킹 요구가 허용됨,

X: 새 NLM 바이트 범위 록킹 요구가 거부됨

표 3에 나타난 바와같이, 현재의 파일 록킹과 새롭게 요구된 NLM 바이트 범위 록킹의 각 쌍은 요구된 새로운 바이트 범위 록킹을 허용하거나 거부하는 관련 결정을 갖는다.

단계(442)에서, 파일 서버(110)는 요구된 새로운 바이트 범위 록킹을 새로운 부가 바이트 범위 록킹으로서 파일(113)과 연관시킨다.

방법(400)은 플로우 지점(450)에서 계속된다.

플로우 지점(450)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)내의 요구 동작과 파일(113)의 파일 록킹 상태를 비교하고, 요구된 동작을 허용하거나 거부한다.

동작 방법("옵록" 관리자)

도 5는 다중 프로토콜 파일 서버에서 "옵록" 관리자를 동작시키는 방법의 처리 플로우도를 나타낸다.

다중 프로토콜 파일 서버에서 "옵록" 관리자를 동작하는 방법(500)은 처리 단계 세트와 플로우 지점을 포함하며, 적어도 하나의 클라이언트 장치(130)와 상호 동작하는 파일 서버(110)에 의해 수행된다.

윈도우 오퍼레이팅 시스템 환경에서의 파일 록킹 분야에서 "옵록"은 공지되어 있으며, 워싱톤주 레이몬드에 위치한 마이크로소프트사로부터 입수가능한 "윈도우 NT 4.0" 오퍼레이팅 시스템에 대해 이용가능한 서면-예를 들면, 호스트 ftp.microsoft.com, directory/developr/drg/CIFS, 파일 cifs6.doc 또는 cifs6.txt에서의 FTP 프로토콜을 통하여 입수가능한, CIFS IETF 사양을 포함하는-으로, 본 발명에 참조로 병합되는 서면에 더욱 상세하게 기재되어 있다.

플로우 지점(510)에서, 파일 서버(110)는 파일(113)을 오픈하기 위해 CIFS 제1 클라이언트 장치(130)로부터의 요구를 받을 수 있다.

단계(511)에서, 파일 서버(110)는 파일(113)에 대한 파일 오픈 요구를 CIFS 제1 클라이언트 장치(130)로부터 수신한다. 이러한 파일 오픈 요구는 액세스 모드와 거부 모드를 지정한다.

단계(512)에서, 파일 서버(110)는 요구를 허용해야 할 지를 결정하고, 제1 클라이언트 장치(130)에 대해 지정된 액세스 모드와 거부 모드를 갖는 파일 록킹을 허용한다.

단계(513)에서, 클라이언트 장치(130)가 파일 오픈 요구에 대한 "옵록"을 요구하면, 파일 서버(110)는 제1 클라이언트 장치(130)가 실제로 요구하는 것 보다 가능한 더 큰 배타적 레벨을 갖는 "옵록"을 제1 클라이언트 장치(130)에 허용한다.

예를 들면, CIFS 제1 클라이언트 장치(130)가 파일(113)을 판독 전용 액세스 모드와 기입 거부인 거부 모드로 오픈할 때, 파일 서버(110)는 그 타입의 파일 록킹과 파일(113)을 연관시킨다. 추가로, 파일 서버(110)는 판독-기입 액세스 모드와 총 거부인 거부 모드로 파일(113)과 "옵록"을 연관시킨다.

플로우 지점(520)에서, 파일 서버(110)는 파일(113)에 대한 파일 록킹에 대해 CIFS 제1 클라이언트 장치(130)으로부터의 요구에 응답한다.

플로우 지점(530)에서, 제2 클라이언트 장치(130)는 파일(113)을 오픈할 것을 시도한다.

단계(531)에서, 파일 서버(110)는 제2 CIFS 클라이언트 장치(130)로부터의 파일 오픈 요구나 PC NFS 클라이언트 장치(130)로부터 NLM 파일 록킹 요구를 수신한다.

이러한 단계(531)를 수행한 일부로서, 파일 서버(110)는 제2 클라이언트 장치(130)에 의한 요구의 실행을 중지하는 반면, "옵록"을 정지하고 "옵록"의 소지자, 즉, 제1 클라이언트 장치(130)로부터의 응답을 얻는다.

단계(532)에서, 파일 서버(110)는 "옵록" 정지 메시지(140)를 CIFS 제1 클라이언트 장치(130)로 보냄으로써, "옵록"을 정지한다.

제2 클라이언트 장치(130)가 CIFS 클라이언트 장치(130)이면, 예상된 바와 같다. 제2 클라이언트 장치(130)가 NFS 클라이언트 장치(130)이면, 파일 서버(110)는 NFS(혹은 NLM) 프로토콜 요구 메시지(140)에 대한 응답을 CIFS 제1 클라이언트 장치(130)가 "옵록 정지" 메시지(140)에 응답할 때까지 지연시킨다.

단계(533)에서, CIFS 제1 클라이언트 장치(130)는 "옵록 정지" 메시지(140)를 수신하고 다음 두 방법중 하나로 메시지(140)에 응답할 수 있다.

- CIFS 제1 클라이언트 장치(130)는 파일(113)을 종료할 수 있다(따라서, 파일 오픈과 연관된 파일 록킹을 제거한다); 또는

- CIFS 제1 클라이언트 장치(130)는 클라이언트 장치(130)에서 지역적으로 캐시로 있는 파일(113)에 대한 모든 현재의 CIFS 기입 및 바이트 범위 록킹 요구를 플러시하고(즉, 파일 시스템 동작의 결과를 파일 서버(110)로 보낼 수 있다), 파일(113)에 대해 얻어진 이미 판독된 데이타는 버릴 수 있다. 미리 판독된 데이타는 제2 클라이언트 장치(130)가 파일로 새로운 데이타를 연속하여 기입하여, 이미 판독된 데이타를 무효화시키므로, 버려질 수 있다.

단계(534)에서, 파일 서버(110)는 CIFS 제1 클라이언트 장치(130)으로부터의 응답을 받는다.

단계(535)에서, 파일 서버(110)는 CIFS 제1 클라이언트 장치(130)가 파일(113)을 오픈상태로 유지할 지를 결정하고, 오픈상태이면 제2 클라이언트 장치(130)로부터의 요구에 의해 함축된 록킹 모드를 파일(113)의 새로운 파일 록킹 상태에 대해 비교한다. 파일 서버(110)가 제2 클라이언트 장치(130)에 의한 요구가 진행될 것을 결정하면, 플로우 지점(540)으로 계속된다. 파일 서버(110)가 제2 클라이언트 장치(130)에 의한 요구가 진행되지 않을 것을 결정하면, 요구는 거부된다.

플로우 지점(540)에서, 파일 서버(110)는 단계(531)에서의 제2 클라이언트 장치(130)로부터의 요구를 허용하도록 처리할 준비가 되어 있다.

동작 방법(변경 통지 관리자)

도 6은 다중 프로토콜 파일 서버에서 변경 통지 관리자를 동작하는 방법의 처리 플로우도이다.

다중 프로토콜 파일 서버에서의 변경 통지 관리자를 동작하는 방법(600)은 처리단계세트와 플로우 지점을 포함하고, 적어도 하나의 클라이언트 장치(130)와 상호동작하는 파일 서버(110)에 의해 수행된다.

플로우 지점(610)에서, 파일 서버(110)는 파일 서버 요구 메시지(140)를 수신할 준비가 되어 있다.

단계(611)에서, 파일 서버(110)는 제1 CIFS 클라이언트 장치(130)로부터 파일 오픈 요구 메시지(140)를 수신하고, 디렉토리를 파일 서버(110)에 지정한다. 파일 서버(110)는 파일 오픈 요구를 허용할 지와 디렉토리상의 CIFS 파일 록킹을 제1 CIFS 클라이언트 장치(130)에 대해 허용할 지를 결정한다.

단계(612)에서, 파일 서버(110)는 오픈 디렉토리를 참조하여 제1 CIFS 클라이언트 장치(130)로부터 변경 통지 요구 메시지를 수신하여 오픈 디렉토리상의 파일 록킹을 변경 모니터 록킹으로 변경한다.

단계(613)에서, 파일 서버(110)는 오픈 디렉토리상의 파일 록킹을 지정 디렉토리상의 변경 모니터 록킹으로 변경한다.

플로우 지점(620)에서, "변경 모니터" 록킹은 지정 디렉토리와 연관되며, 제1 CIFS 클라이언트 장치(130)는 그 디렉토리에 대한 변경이 통지될 준비가 되어 있다.

단계(621)에서, 파일 서버(110)는 제2 클라이언트 장치(130)로부터 파일 서버 요구 메시지(140)를 수신하여, 지정된 디렉토리에 대한 변화를 요구하고, 제1 클라이언트 장치(130)에 대한 변경 통지를 개시한다(변경의 형태는 파일 생성, 삭제, 파일이름변경, 디렉토리간의 파일 이동, 파일 속성 변경, 파일 변경시간 변경). 제2 클라이언트 장치(130)로부터의 파일 서버 요구 메시지는 CIFS 또는 NFS일 수 있다. 제2 클라이언트 장치(130)는 유닉스 NFS 클라이언트 장치(201), PC NFS 클라이언트 장치(202), CIFS 윈도우 클라이언트 장치(203) 중 어느 하나일 수 있다.

단계(622)에서, 파일 서버(110)는 "변경 모니터" 록킹을 소지하고 있는 제1 클라이언트 장치(130)에 단계(621)에서의 변경을 통지하는데, 이들 변경은 다수의 엔트리(이들 엔트리 각각은 변경된 파일(113) 이름 또는 모니터링되는 디렉토리 내의 변경된 서브 디렉토리의 이름과, 변경의 타입을 특정함)를 포함할 수 있다. 그러한 제1 클라이언트 장치(130)가 한 개 이상이면, 파일 서버(110)는 모두에게 변경을 통지한다.

변경 통지는 윈도우 NT 오퍼레이팅 시스템 환경하의 파일 록킹 분야에서 공지되어 있다. 워싱톤주 레이몬드에 위치한 마이크로소프트사로부터 입수가능한 "윈도우 NT 4.0" 오퍼레이팅 시스템에 대해 이용가능한 서면-예를 들면, 호스트 ftp.microsoft.com, directory/developr/drg/CIFS, 파일 cifs6.doc 또는 cifs6.txt에서의 FTP 프로토콜을 통하여 입수가능한, CIFS IETF 사양을 포함하는-으로, 본 발명에 참조로 병합되는 서면에 더욱 상세하게 기재되어 있다.

플로우 지점(630)에서, 파일 서버(110)는 제1 CIFS 클라이언트 장치(130)에 지정 디렉토리에 대한 변경을 통지하고 다음 메시지(140)를 준비한다.

다른 실시예

보다 바람직한 실시예가 여기에 설명되었지만, 다양한 변경이 본 발명의 개념, 범위 및 정신내에서 가능하며, 이러한 변경은 본 발명이 속한 분야의 당업자에게 자명하다.

Claims

삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
삭제
복수의 다양한 파일 록킹(file-locking) 프로토콜을 사용하는 클라이언트 장치 세트 사이에서 단일 파일 록킹 의미론(uniform file-locking semantics)을 실시하는 단계를 포함하는 파일 서버 동작 방법으로서,

상기 파일 서버는 상기 복수의 다양한 파일 록킹 프로토콜을 구현하고, 상기 복수의 다양한 파일 록킹 프로토콜에 대한 단일 파일 록킹 의미론을 실시하며,

상기 단일 파일 록킹 의미론은,

제1 프로토콜을 사용하는 제1 메시지에 응하여, 선택된 파일에 관한 기회적(opportunistic) 록킹을 제1 클라이언트 장치에 허여하는 단계와,

제2 프로토콜을 사용하는 제2 메시지에 응하여 상기 기회적 록킹을 정지하는 단계를 포함하고,

상기 제1 프로토콜 및 상기 제2 프로토콜은 상기 복수의 다양한 파일 록킹 프로토콜 중 하나인 파일 서버 동작 방법.
삭제
제39항에 있어서, 상기 제1 프로토콜은 CIFS를 포함하는 파일 서버 동작 방법.
제39항에 있어서, 상기 제2 프로토콜은 NFS 또는 NLM을 포함하는 파일 서버 동작 방법.
제39항에 있어서, 상기 정지 단계는,

상기 제2 메시지에 응하여 상기 제1 클라이언트 장치에 옵록(oplock) 정지 메시지를 전송하는 단계;

상기 제2 메시지에 의해 지시된 파일 시스템 요구의 실행을 지연시키는 단계;

상기 제1 클라이언트 장치로부터 상기 옵록 정지 메시지에 대한 응답을 수신하는 단계; 및

상기 수신단계후에 상기 제2 메시지를 처리하고 상기 제2 메시지에 응답하는 단계를 더 포함하는 파일 서버 동작 방법.
제39항에 있어서, 상기 단일 파일 록킹 의미론은,

상기 제1 프로토콜을 사용하는 상기 제1 클라이언트 장치에 의해 요구될 수 있는 변경 모니터 록킹 타입; 및

상기 제1 프로토콜과는 다른 상기 제2 프로토콜을 사용하는 제2 클라이언트 장치에 의해 트리거(trigger)되는 변경 통지를 포함하는 파일 서버 동작 방법.
제39항에 있어서, 상기 단일 파일 록킹 의미론은,

상기 제1 프로토콜을 사용하는 상기 제1 클라이언트 장치에 의해 요구된 액세스 모드와 거부 모드에 응하여 결정된 제1 록킹 모드; 및

상기 제1 프로토콜과 다른 상기 제2 프로토콜을 사용하는 제2 클라이언트 장치로부터의 메시지에 응하여 결정된 제2 록킹 모드를 포함하며,

상기 파일 서버는 상기 제1 록킹 모드와 상기 제2 록킹 모드의 비교에 응답하는 파일 서버 동작 방법.
제45항에 있어서, 상기 비교는 록킹 호환성 매트릭스를 포함하는 파일 서버 동작 방법.
제45항에 있어서, 상기 비교는 록킹 변환 매트릭스를 포함하는 파일 서버 동작 방법.
제45항에 있어서, 상기 제2 록킹 모드는 바이트 범위 록킹에 대한 요구에 응답하는 파일 서버 동작 방법.
제39항에 있어서, 상기 복수의 다양한 파일 록킹 프로토콜을 사용하는 클라이언트 장치 세트 사이에서 단일 파일 록킹 의미론을 실시하는 단계는,

상기 복수의 다양한 파일 록킹 프로토콜을 인식하는 단계;

상기 다양한 파일 록킹 프로토콜 중 적어도 하나를 사용하는 메시지에 응하여 상기 단일 파일 록킹 의미론을 제공하는 단계; 및

모든 상기 클라이언트 장치에 대해 상기 단일 파일 록킹 의미론을 실시하는 단계를 포함하는 파일 서버 동작 방법.
제39항에 있어서, 상기 복수의 다양한 파일 록킹 프로토콜을 사용하는 클라이언트 장치 세트 사이에서 단일 파일 록킹 의미론을 실시하는 단계는,

상기 다양한 파일 록킹 프로토콜 중 선택된 하나의 프로토콜에서 파일에 액세스하기 위한 메시지로서, 요구 모드를 포함하는 메시지를 인식하는 단계와,

상기 요구 모드를 사용하는 상기 파일로의 액세스가, 동일한 또는 다른 다양한 파일 록킹 프로토콜을 사용하는 메시지에 의해 형성된 현재의 록킹과 충돌하는지 여부를 테스트하는 단계를 포함하는 파일 서버 동작 방법.
제39항에 있어서, 상기 복수의 다양한 파일 록킹 프로토콜을 사용하는 클라이언트 장치 세트 사이에서 단일 파일 록킹 의미론을 실시하는 단계는,

제1 프로토콜을 사용하며 선택된 파일의 적어도 일부를 록킹하도록 동작하는 제1 메시지를 수신하는 단계;

제2 프로토콜을 사용하며 상기 일부로의 액세스를 요구하도록 동작하는 제2 메시지를 수신하는 단계; 및

상기 제2 메시지에 의해 요구된 상기 액세스를 상기 록킹과 비교하고, 상기 록킹에 의해 금지되는 경우 상기 액세스를 거부하는 단계를 포함하는 파일 서버 동작 방법.
프로세서와, 대용량 기억장치와, 네트워크로의 인터페이스를 포함하고,

복수의 다양한 파일 록킹 프로토콜을 사용하는 클라이언트 장치 세트 사이에서 단일 파일 록킹 의미론을 실시하는 단계를 수행하기 위해, 상기 프로세서의 제어하에 동작하며,

상기 복수의 다양한 파일 록킹 프로토콜을 구현하고, 상기 복수의 다양한 파일 록킹 프로토콜에 대한 단일 파일 록킹 의미론을 실시하는 파일 서버로서,

상기 단일 파일 록킹 의미론은,

제1 프로토콜을 사용하는 제1 메시지에 응하여, 선택된 파일에 관한 기회적 록킹을 제1 클라이언트 장치에 허여하는 단계와,

제2 프로토콜을 사용하는 제2 메시지에 응하여 상기 기회적 록킹을 정지하는 단계를 포함하고,

상기 제1 프로토콜 및 상기 제2 프로토콜은 상기 복수의 다양한 파일 록킹 프로토콜 중 하나인 파일 서버.
삭제
제52항에 있어서, 상기 제1 프로토콜은 CIFS를 포함하는 파일 서버.
제52항에 있어서, 상기 제2 프로토콜은 NFS 또는 NLM을 포함하는 파일 서버.
제52항에 있어서, 상기 정지 단계는,

상기 제2 메시지에 응하여 상기 제1 클라이언트 장치에 옵록(oplock) 정지 메시지를 전송하는 단계;

상기 제2 메시지에 의해 지시된 파일 시스템 요구의 실행을 지연시키는 단계;

상기 제1 클라이언트 장치로부터 상기 옵록 정지 메시지에 대한 응답을 수신하는 단계; 및

상기 수신단계후에 상기 제2 메시지를 처리하고 상기 제2 메시지에 응답하는 단계를 더 포함하는 파일 서버.
제52항에 있어서, 상기 단일 파일 록킹 의미론은,

상기 제1 프로토콜을 사용하는 상기 제1 클라이언트 장치에 의해 요구될 수 있는 변경 모니터링 록킹 타입; 및

상기 제1 프로토콜과는 다른 상기 제2 프로토콜을 사용하는 제2 클라이언트 장치에 의해 트리거(trigger)되는 변경 통지를 포함하는 파일 서버.
제52항에 있어서, 상기 단일 파일 록킹 의미론은,

상기 제1 프로토콜을 사용하는 상기 제1 클라이언트 장치에 의해 요구된 액세스 모드와 거부 모드에 응하여 결정된 제1 록킹 모드; 및

상기 제1 프로토콜과 다른 상기 제2 프로토콜을 사용하는 제2 클라이언트 장치로부터의 메시지에 응하여 결정된 제2 록킹 모드를 포함하며,

상기 제1 록킹 모드와 상기 제2 록킹 모드의 비교에 응답하는 파일 서버.
제58항에 있어서, 상기 비교는 록킹 호환성 매트릭스를 포함하는 파일 서버.
제58항에 있어서, 상기 비교는 록킹 변환 매트릭스를 포함하는 파일 서버.
제58항에 있어서, 상기 제2 록킹 모드는 바이트 범위 록킹에 대한 요구에 응답하는 파일 서버.
제52항에 있어서, 상기 복수의 다양한 파일 록킹 프로토콜을 사용하는 클라이언트 장치 세트 사이에서 단일 파일 록킹 의미론을 실시하는 단계는,

상기 복수의 파일 록킹 프로토콜을 인식하는 단계;

상기 다양한 파일 록킹 프로토콜 중 적어도 하나를 사용하는 메시지에 응하여 상기 단일 파일 록킹 의미론을 제공하는 단계; 및

모든 상기 클라이언트 장치에 대해 상기 단일 파일 록킹 의미론을 실시하는 단계를 포함하는 파일 서버.
제52항에 있어서, 상기 복수의 다양한 파일 록킹 프로토콜을 사용하는 클라이언트 장치 세트 사이에서 단일 파일 록킹 의미론을 실시하는 단계는,

상기 다양한 파일 록킹 프로토콜 중 선택된 하나의 프로토콜에서 파일에 액세스하기 위한 메시지로서, 요구 모드를 포함하는 메시지를 인식하는 단계와,

상기 요구 모드를 사용하는 상기 파일로의 액세스가, 동일한 또는 다른 다양한 파일 록킹 프로토콜을 사용하는 메시지에 의해 형성된 현재의 록킹과 충돌하는지 여부를 테스트하는 단계를 포함하는 파일 서버.
제52항에 있어서, 상기 복수의 다양한 파일 록킹 프로토콜을 사용하는 클라이언트 장치 세트 사이에서 단일 파일 록킹 의미론을 실시하는 단계는,

제1 프로토콜을 사용하고, 선택된 파일의 적어도 일부를 록킹하도록 동작하는 제1 메시지를 수신하는 단계;

제2 프로토콜을 사용하고, 상기 일부로의 액세스를 요구하도록 동작하는 제2 메시지를 수신하는 단계; 및

상기 제2 메시지에 의해 요구된 상기 액세스를 상기 록킹과 비교하고, 상기 록킹에 의해 금지되는 경우 상기 액세스를 거부하는 단계를 포함하는 파일 서버.