KR101841311B1

KR101841311B1 - 디렉토리 리싱

Info

Publication number: KR101841311B1
Application number: KR1020137006736A
Authority: KR
Inventors: 데이비드 매튜 크루즈; 매튜 죠지; 사로쉬 사이러스 헤이브왈라; 크리스티안 그레고리 올레드; 닐 로버트 크리스티안센
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2010-09-17
Filing date: 2011-09-06
Publication date: 2018-03-22
Also published as: MX2013002933A; EP2616950A2; CN104268242A; EP3637275B1; EP3637275A1; RU2013111824A; KR20130107280A; WO2012036938A2; AU2011302396B2; EP2616950B1; US20150149505A1; AU2011302396A1; HK1206119A1; US9092450B2; JP5809275B2; CA2809133A1; WO2012036938A3; CN102521224B; RU2596986C2; BR112013006347A2

Abstract

분산형 파일 시스템을 액세스하는 클라이언트가 디렉토리 메타데이터를 로컬 캐싱할 수 있도록 하는 실시예가 설명된다. 클라이언트는 클라이언트가 디렉토리 데이터를 로컬 캐싱하고 디렉토리 데이터를 최초로 요청한 동일한 애플리케이션으로부터의 요청을 캐시를 사용하여 서비싱(servicing)할 수 있도록 허용하는 판독 리스(read lease)를 요청할 수 있다. 또한, 클라이언트는 클라이언트가 디렉토리 핸들의 클로징(closing of directory handle)을 지연시킬 수 있고 그 디렉토리 핸들이 동일한 또는 상이한 애플리케이션으로부터의 후속 디렉토리 메타데이터 요청을 서비싱하는데 재사용될 수 있도록 허용하는 핸들 리스(handle lease)도 요청할 수 있다. 클라이언트는 클라이언트 상의 애플리케이션이 예를 들어 디렉토리 내에 새로운 파일을 생성 또는 삭제하거나 또는 그들의 속성을 변경함으로써 디렉토리 메타데이터를 수정하고 이들 변경들을 캐싱할 수 있도록 허용하는 기록 리스를 요청할 수 있다.

Description

디렉토리 리싱{DIRECTORY LEASING}

클라이언트 상의 애플리케이션이 분산형 파일 시스템에 저장된 파일을 액세스하는 것은 흔한 일이다. 분산형 파일 시스템은 원격으로 저장된 파일에의 액세스를, 클라이언트 상에서 국부적으로 실행되는 애플리케이션에 투명하게 제공한다. 분산형 파일 시스템은 정보를 원격으로 가져오는 것보다 효율적이도록 클라이언트가 일부 정보를 로컬 캐싱하여 몇몇 요청에 대해 로컬 정보가 제공될 수 있도록 해주는 몇몇 기능들을 포함할 수 있다. 그러나, 현재의 분산형 파일 시스템은 분산형 파일 시스템을 액세스하는 클라이언트들 사이에서 일치성 및 일관성(consistency and coherency)을 제공하는 메타데이터(예를 들어, 디렉토리 메타데이터)와 같은 정보를 캐싱하는 메카니즘을 가지고 있지 않다.

이들 및 그 밖의 다른 것을 고려하여, 본 발명의 실시예가 이루어졌다. 또한, 비교적 특정 문제를 다루고 있지만, 본 발명의 실시예는 배경기술에서 언급한 특정 문제를 해결하는 것에 국한되지 말아야 함을 이해해야 할 것이다.

이 요약은 이하의 상세한 설명에서 추가적으로 설명되는 선택된 개념들을 단순화된 형태로 도입하도록 제공되었다. 이 요약은 청구 대상의 주요 특징 또는 기본 특징을 식별하도록 의도된 것이 아니고, 청구 대상의 범주를 제한하는 데 사용되도록 의도된 것도 아니다.

분산형 파일 시스템을 액세스하는 클라이언트가 디렉토리 메타데이터를 로컬 캐싱할 수 있도록 허용하는 실시예가 설명된다. 일 실시예에서, 클라이언트는 디렉토리 데이터를 캐싱하기 위해 파일 서버로부터 리스(lease)를 요청한다. 클라이언트는 클라이언트가 디렉토리 데이터를 로컬 캐싱하고 디렉토리 데이터를 최초로 요청한 동일한 애플리케이션으로부터의 요청을 서비싱(servicing)할 수 있도록 허용하는 판독 리스(read lease)를 요청할 수 있다. 또한, 클라이언트는 클라이언트가 디렉토리 핸들의 클로징(closing of a directory handle)을 지연시킬 수 있고 그 디렉토리 핸들이 클라이언트 상의 동일한 또는 상이한 애플리케이션으로부터의 후속 디렉토리 메타데이터 요청을 서비싱하는데 재사용될 수 있도록 허용하는 핸들 리스(handle lease)도 요청할 수 있다. 몇몇 실시예에서, 서버는 클라이언트 리스를 추적하고, 디렉토리 메타데이터에 대한 판독 리스를 소유한 클라이언트에 의해 행해진 디렉토리 메타데이터에 대한 변경에 의해 판독 리스가 철회되는 일이 없도록 보장하기 위해 두 개의 리스 키에 의존한다. 다른 실시예에서, 클라이언트는 클라이언트 상의 애플리케이션이 예를 들어 디렉토리 내의 파일을 생성 또는 삭제하거나 또는 그들의 속성을 변경함으로써 디렉토리 메타데이터를 수정하고 이들 변경들을 캐싱할 수 있도록 허용하는 기록 리스를 요청할 수 있다. 다른 클라이언트가 디렉토리 메타데이터를 요청하는 경우, 기록 리스는 파기되고 변경들은 서버로 플러시(flush)된다.

실시예들은 컴퓨터 프로세스, 컴퓨팅 시스템, 또는 컴퓨터 프로그램 제품 또는 컴퓨터 판독가능 매체와 같은 제조 물품으로 구현될 수 있다. 컴퓨터 프로그램 제품은 컴퓨터 시스템에 의해 판독가능하고 또한 컴퓨터 프로세스를 실행하는 명령어들의 컴퓨터 프로그램을 인코딩하는 컴퓨터 저장 매체일 수 있다. 컴퓨터 프로그램 제품은 컴퓨터 시스템에 의해 판독가능하고 또한 컴퓨터 프로세스를 실행하는 명령어들의 컴퓨터 프로그램을 인코딩하는 반송파 상의 전파 신호일 수 있다.

아래의 도면을 참조하여 비제한적 및 비전면적인 실시예가 설명된다.
도 1은 몇몇 실시예를 구현하는데 사용될 수 있는 시스템의 실시예를 나타내는 도면,
도 2는 몇몇 실시예에서 사용될 수 있는 클라이언트 및 서버의 블록도를 나타내는 도면,
도 3은 디렉토리 메타데이터를 로컬 캐싱하는 몇몇 실시예에 따른 동작 흐름도를 나타내는 도면,
도 4는 디렉토리 데이터에 대한 리스를 유지하는 클라이언트에 의해 디렉토리 메타데이터를 수정하는 요청을 서비싱하기 위한 몇몇 실시예에 따른 동작 흐름도를 나타내는 도면,
도 5는 몇몇 실시예에 따라 디렉토리 데이터에 대한 판독 리스의 철회가 수신될 때 수행되는 동작 흐름도를 나타내는 도면,
도 6은 디렉토리 메타데이터가 로컬 캐싱될 수 있도록 허용하는 몇몇 실시예에 따른 동작 흐름도를 나타내는 도면,
도 7은 실시예를 구현하는데 적합한 컴퓨팅 환경에 대한 블록도를 나타내는 도면.

실시예의 일부분을 형성하고 본 발명을 실시하는 특정 예시적인 실시예를 보여주는 첨부 도면을 참조하여 다양한 실시예가 보다 구체적으로 설명된다. 그러나, 실시예들은 다수의 상이한 형태로 구현될 수 있고 본 명세서에 기술된 실시예에 국한되는 것으로 해석되어서는 안되며, 그 보다 이들 실시예는 본 개시물이 철저하고 완전한 이해를 돕도록 제공된 것이며, 본 발명의 범주를 당업자에게 완전히 전달할 것이다. 실시예들은 방법, 시스템 또는 장치로 실시될 수 있다. 따라서, 실시예들은 하드웨어 구현, 완전한 소프트웨어 구현 또는 소프트웨어 및 하드웨어 측면을 결합한 구현의 형태를 취할 수 있다. 따라서, 후속하는 상세한 설명은 제한적 의미로서 취급되어서는 안된다.

도 1은 실시예들이 구현되는 분산형 파일 시스템(100)에 대한 실시예를 나타낸다. 시스템(100)은 파일 및 파일 정보에 대한 액세스를 요구하는 다양한 애플리케이션을 구동하는 클라이언트(102,104)를 포함한다. 파일 서버(106)는 파일 및 파일 정보를 예를 들어 데이터 저장소(108)에 저장한다. 클라이언트(102,104)는 네트워크(110)와 같은 네트워크를 통해 파일 서버(106)에 액세스할 수 있다. 당업자라면 알 수 있는 바와 같이, 네트워크(110)는 클라이언트(102,104)가 파일 서버(106)와 통신할 수 있도록 해주는 LAN, WAN(예를 들어, 이더넷), SAN(storage area network), 또는 다른 네트워크일 수 있다.

분산형 파일 시스템(100)은 클라이언트(102,104)가 파일 서버(106)에 액세스할 수 있도록 해주는 프로토콜을 구현할 수 있다. 프로토콜에 대한 몇몇 비제한적 예는 SMB(Server Message Block), SMB2 및 NFS를 포함한다. 당업자라면 알 수 있는 바와 같이, 파일 액세스 프로토콜은 클랑언트가 파일 서버로부터 파일을 요청하기 위한 다양한 포맷을 제공한다. 실시예들은 임의의 특정 파일 액세스 프로토콜에 국한되지 않는다. 그 보다, 기술된 실시예들의 특징들은 전술한 파일 액세스 프로토콜을 포함하여 임의의 파일 액세스 프로토콜을 사용하여 구현될 수 있다.

일 실시예에서, 클라이언트(102,104)는 클라이언트가 디렉토리 메타데이터를 로컬 캐싱할 수 있도록 허용하는 리스를 파일 서버(106)로부터 요청할 수 있다. 당업자라면 알 수 있는 바와 같이, 파일 서버(106)는 실제 파일 데이터를 저장하는 것 외에, 디렉토리 내의 파일의 특성을 기술하는 디렉토리 메타데이터도 저장할 수 있다. 예를 들어, 디렉토리 메타데이터는 마지막으로 수정한 날짜, 생성 날짜, 파일 크기, 파일 유형, 및 디렉토리 내의 각 파일에 대한 저자 이름을 포함할 수 있으나 이에 국한되지는 않는다. 이 실시예는 리싱 메카니즘(leasing mechanism)을 제공함으로써 구현될 수 있다.

도 1에 예시되어 있는 바와 같이, 몇몇 실시예는 클라이언트(102)와 같은 클라이언트가 메타데이터 리스 요청을 포함하는 패킷(112)을 파일 서버(106)에 전송하는 것을 제공한다. 실시예에 있어서, 패킷(112)은 리스 요청 이외에 메타데이터에 대한 요청을 포함할 수 있다. 예를 들어, 브라우저 애플리케이션과 같은 애플리케이션이 특정 디렉토리에 대한 디렉토리 메타데이터를 요청할 수 있다. 이 요청에 응답하여, 클라이언트(102)는 메타데이터 리스 요청뿐만 아니라 특정 디렉토리의 메타데이터에 대한 요청을 포함하는 패킷(112)을 전송할 수 있다.

도 1에 도시되어 있는 바와 같이, 패킷(112)은 판독 리스, 기록 리스, 및/또는 핸들 리스를 지정할 수 있다. 판독 리스는 클라이언트(102)가 디렉토리의 메타데이터를 로컬 캐시에 저장하고 브라우저 애플리케이션이 디렉토리 메타데이터를 요청할 때마다 클라이언트가 로컬 캐시로부터 요청을 서비싱하는 것을 허용할 것이다. 핸들 리스는 클라이언트(102)가 디렉토리 핸들의 클로징을 지연시켜, 클라이언트(102)가 디렉토리 핸들을 사용하여 디렉토리에 대해 디렉토리 메타데이터를 요청할 수 있는 브라우저 애플리케이션 및 다른 애플리케이션으로부터의 후속 요청을 서비싱하는 것을 허용한다. 기록 리스는 클라이언트가 애플리케이션이 디렉토리 메타데이터에 행하는 변경들을 캐싱하는 것을 허용한다.

도 1에 도시되어 있는 실시예에서, 파일 서버(106)는 요청된 디렉토리 메타데이터, 및 요청된 리스가 승인되었는지 여부에 대한 표시를 포함하는 응답 패킷(114)을 전송한다. 응답 패킷에 기초하여, 클라이언트(102)는 리스 요청이 승인된 경우 디렉토리 메타데이터를 캐싱하고 디렉토리 메타데이터를 브라우저 애플리케이션에 제공한다. 요청된 리스가 승인되지 않았음을 응답 패킷이 나타내는 경우, 클라이언트(102)는 디렉토리 메타데이터를 캐싱하지 않고, 디렉토리 메타데이터를 브라우저 애플리케이션에 제공할 것이다. 클라이언트(102)가 리스를 승인받지 못한 경우, 디렉토리 메타데이터에 대한 브라우저 애플리케이션으로부터의 임의의 후속 요청은 클라이언트가 파일 서버(106)로부터 디렉토리 메타데이터를 요청하게 할 것이다.

이하에서 자세히 설명되는 바와 같이, 리스를 클라이언트에 승인하게 되면 애플리케이션으로부터의 요청을 효율적으로 서비싱할 수 있고 클라이언트가 다수의 요청을 파일 서버(106)에 전송할 필요성이 줄어든다. 따라서, 몇몇 실시예에서, 파일 서버(106)는 일반적으로 다른 클라이언트가 충돌하는 리스를 현재 보유하고 있지 않다면 리스를 클라이언트에게 승인할 것이다. 디렉토리 메타데이터의 일관성을 보장하기 위해, 파일 서버(106)는 특정 디렉토리 메타데이터에 대해 충돌하는 리스가 다른 클라이언트에게 승인되지 않도록 보장한다.

도 1의 설명은 몇몇 실시예의 일부 특징만을 나타낸다. 이하에서 보다 자세히 설명되는 바와 같이, 다른 실시예들이 추가적인 특징을 제공할 수 있다. 도 1의 설명은 임의의 다른 실시예의 범주를 제한하는데 사용되어서는 안된다.

도 2는 몇몇 실시예에서 사용될 수 있는 클라이언트와 서버의 블록도를 나타낸다. 위에서 설명한 바와 같이, 상이한 파일 액세스 프로토콜이 사용되어 설명된 실시예들의 특징을 구현할 수 있다. 이하에서 설명되는 도 2의 설명 중 일부는 SMB2의 특징에 대한 설명을 포함한다. 그러나, 이것은 다른 실시예를 제한하는데 사용되어서는 아니되는데, 그 이유는 설명한 특징을 구현하는데 임의의 파일 액세스 프로토콜이 사용될 수 있기 때문이다. SMB2의 사용은 단지 하나의 예일뿐이며 단지 설명을 위한 것이다.

도 2는 분산형 파일 시스템(200)의 일부인 클라이언트(202) 및 서버(204)의 블록도를 나타낸다. 몇몇 실시예에서, 클라이언트(202)는 시스템(100)(도 1)에서 클라이언트(102,104)로서 구현될 수 있고, 파일 서버(204)는 시스템(100)(도 1)에서 파일 서버(106)로서 구현될 수 있다.

도 2에 도시되어 있는 바와 같이, 클라이언트(202)는 서버(204)의 파일 시스템(208)에 저장되어 있는 파일 데이터 및 메타데이터에 대한 액세스를 요청하는 다수의 애플리케이션(206A-C)을 포함한다. 클라이언트(202)는 또한 리디렉터(redirector)(210)를 포함한다. 일 실시예에서, 리디렉터(210)는 SMB2로서 구성될 수 있고, 클라이언트(202) 및 서버(204)는 SMB2 프로토콜에 따라 포맷된 패킷을 사용하여 통신한다. 애플리케이션(206A-C) 중 하나가 서버(204) 상에 위치한 파일을 요청하는 경우, 리디렉터(210)가 이 요청을 처리할 것이다. 리디렉터(210)는 파일 데이터 및 메타데이터에 대한 요청을 이용하여 SMB2 프로토콜에 따라 포맷된 패킷을 생성할 것이다. 이하에서 보다 자세히 설명되는 바와 같이, 실시예에서, SMB2 프로토콜은 클라이언트(202)가 클라이언트(202) 상의 로컬 캐시(212)에 디렉토리 메타데이터를 저장할 수 있도록 해주는 리싱 메카니즘(leasing mechanism)을 제공하도록 확장된다. 이 리싱 메카니즘은 서버(204)에 의해 승인된 리스와 연관된 리스 키(디렉토리 키/파일 키)를 저장하는 클라이언트(202) 상의 룩업 테이블(214)을 이용한다. 서버(204)는 리스를 요청하고 승인받은 클라이언트에 대한 리스 키를 저장한다. 서버(204)는 리스 테이블(216)을 이용하여 리스 키를 저장한다.

시스템(200)의 동작에 대한 일 예로서, 애플리케이션(206A)은 파일 시스템(208)의 디렉토리(예를 들어, Dir. 1)에 저장된 파일에 대한 메타데이터를 요청할 수 있다. 그 결과, 애플리케이션(206A)은 리디렉터(210)에 의해 수신되는 요청을 발행한다. 이 요청의 수신에 응답하여, 리디렉터(210)는 협상 요청 패킷(218)을 전송함으로서 서버(204)와의 세션을 개시할 것이다. 당업자라면 알 수 있는 바와 같이, 협상 요청 패킷(218)은 클라이언트와 서버 간의 세션에 대한 협상을 제공하는 SMB2 프로토콜에 따라 포맷될 것이다. 협상 요청 패킷(218)은 클라이언트가 디렉토리 메타데이터 리싱을 처리할 수 있는지 여부를 나타내는 정보를 포함할 것이다. 일 실시예에서, 디렉토리 메타데이터 리싱은 SMB2 프로토콜의 몇몇 버전에 의해서만 지원될 수 있고, 협상 요청 패킷(218)은 클라이언트가 메타데이터 리싱을 지원하는 SMB2 프로토콜의 버전을 지원하고 이 SMB2 프로토콜의 버전을 이용하여 서버와 통신하려 한다는 표시를 제공할 수 있다.

협상 요청 패킷(218)에 응답하여, 서버(204)는 서버가 SMB2 프로토콜의 버전을 지원하는지 여부에 대한 표시를 포함할 수 있는 협상 응답 패킷(220)을 전송할 것이다. 이 예에서, 협상 응답 패킷(220)은 서버가 디렉토리 메타데이터 리싱을 지원하는 SMB2 프로토콜의 버전을 이용하여 통신하는 것에 동의한다는 것을 나타낸다.

클라이언트(202)와 서버(204) 간의 협상이 완료된 후, 리디렉터(210)는 애플리케이션(206A)에 의해 요청되는 디렉토리 메타데이터를 요청할 수 있다. 일 실시예에서, 리디렉터(210)는 먼저 요청되는 디렉토리 메타데이터와 연관된 디렉토리 키(예를 들어, Dir. 2 키)를 생성할 것이다. 또한, 리디렉터(210)는 요청되는 디렉토리 메타데이터를 포함하는 부모 디렉토리(이 경우, Dir. 1)에 대한 키를 생성한다. 이들 키는 룩업 테이블(214)에 저장된다. 도 2의 실시예에 도시되어 있는 바와 같이, 룩업 테이블(214)은 디렉토리 키를, 디렉토리 내에 저장된 파일에 대한 다양한 파일 키 및 디렉토리 내의 서브디렉토리에 대한 디렉토리 키와 연관시킨다. 몇몇 실시예에서, 리스 키는 GUID(globally unique identifiers)이다. 그러나, 리스 키는 GUID에 국한되지 않는다.

리디렉터(210)는 Dir. 2의 디렉토리 메타데이터에 대한 요청을 포함하고 및 Dir. 2의 디렉토리 메타데이터에 대한 리스를 요청하는 패킷(222)을 전송한다. 리스 요청의 일부분으로서, 리디렉터(210)는 생성된 리스 키(즉, Dir. 1에 대한 디렉토리 키 및 Dir. 2에 대한 디렉토리 키)를 포함한다. 다른 실시예에서, 리디렉터(210)는 어떤 디렉토리 키도 생성하지 않는다. 대신, 패킷(222)은 서버가 리스 키를 생성해야 함을 리디렉터(210)에 나타낸다.

서버(204)가 디렉토리 리스 요청 패킷(222)을 수신하는 경우, 서버(204)는 Dir. 2로부터 디렉토리 메타데이터를 검색할 것이다. 서버(204)는 또한 요청된 리스를 클라이언트(202)에 승인할 수 있는지 여부를 결정한다. 구체적으로, 서버는 서버가 승인한 다른 리스에 대한 리스 키(디렉토리 키 및 파일 키)를 저장하는 리스 테이블(216)을 참조할 수 있다. 이 예에서, 어떤 이전 클라이언트도 Dir. 2에 대한 리스를 요청하지 않았으며, 따라서, 서버(204)는 디렉토리 리스 요청 패킷(222)으로부터의 Dir. 1에 대한 디렉토리 키 및 Dir. 2에 대한 디렉토리 키를 리스 테이블(216)에 저장한다.

서버는 요청된 리스가 승인되었다는 표시 및 디렉토리 메타데이터를 포함하는 디렉토리 리스 응답 패킷(224)을 전송한다. 이 경우, 요청된 리스는 판독 리스, 기록 리스 및/또는 핸들 리스를 포함할 수 있다. 리스가 판독 리스인 경우, 클라이언트(202)는 애플리케이션(206A)으로부터의 Dir. 2의 디렉토리 메타데이터에 대한 요청을 캐시(212)로부터 서비싱할 수 있다. 리스가 기록 리스인 경우, Dir. 2에 대한 디렉토리 메타데이터에 대한 임의의 변경은 캐시(212)에 저장될 수 있다. 리스가 핸들 리스를 포함하는 경우, 클라이언트(202)는 애플리케이션(206A)이 핸들을 클로우징할 때 Dir. 2에 대한 핸들의 클로징을 연기할 수 있다. 핸들은 애플리케이션(206A) 및 그 밖의 다른 애플리케이션(206B, 206C)로부터의 후속 요청을 서비싱하는데 재사용될 수 있다. 리디렉터(210)는 디렉토리 메타데이터를 애플리케이션(206A)에 제공하고 또한 디렉토리 메타데이터를 캐시(212)에도 저장할 것이다.

이후에, 제2 클라이언트가 Dir. 2에 저장된 동일한 디렉토리 메타데이터에 대한 액세스를 요청하는 경우, 서버(204)는 제2 클라이언트가 클라이언트(202)에 주어진 핸들 리스와 양립할 수 없는 액세스를 요청한다면 클라이언트(202)로부터의 핸들 리스를 철회할 수 있다. 서버(204)는 핸들 리스가 철회됨을 나타내는 철회 통지(226)를 클라이언트(202)에 전송할 것이다. 철회 이후, 애플리케이션(206A,206B, 206C)으로부터의 디렉토리 메타데이터에 대한 임의의 요청은 클라이언트(202)가 새로운 디렉토리 핸들을 서버(204)로부터 직접 요청할 것을 요구할 수 있다. 몇몇 실시예에서, 리스의 철회는 동시에 이루어지고 클라이언트(202)는 철회 통지를 받았다는 확인(228)을 전송해야 한다. 이후, 제2 클라이언트가 Dir. 2에 저장된 디렉토리 메타데이터에 대해 수정을 하는 경우, 서버(204)는 클라이언트(202)로부터의 판독 리스를 철회하여 캐시(212)에 저장된 데이터를 무효화할 수 있다. 철회 이후, 애플리케이션(206A,206B, 206C)으로부터의 디렉토리 메타데이터에 대한 임의의 요청은 서버(204)로부터 정보를 직접 요청함으로써 서비싱될 수 있다.

당업자라면 알 수 있는 바와 같이, 캐시(212) 내의 정보는 디렉토리 메타데이터를 애플리케이션(206A,206B,206C)에 제공하는 것 이외의 목적으로 클라이언트(202)에 의해 사용될 수 있다. 일 예로서, 파일이 디렉토리 내에 존재하지 않는 경우, 누락 파일에 대한 애플리케이션(206A,206B,206C)으로부터의 요청은 그 요청을 서버(204)로 리다이렉팅할 것도 없이 실패할 수 있다. 이것은 존재하지 않는 파일을 목표로 하는 개방 요청에 대한 네트워크 트래픽을 줄이는데 도움이 된다.

일 실시예에서, 전술한 리싱 특징들은 이행적(transitive)이다. 즉, 리디렉터(210)는 리스의 습득 및 철회를 로컬 애플리케이션에 넘길 수 있다. 그러면, 로컬 애플리케이션은 다른 원격 클라이언트를 서빙하는데 사용될 수 있다. 이러한 식으로, 리스 승인 및 철회는 본질적으로 최종 동동(final peer)에 이행적이다.

도 3 내지 도 6은 실시예에 따른 동작 흐름도(300,400,500,600)를 나타낸다. 동작 흐름도(300,400,500,600)는 임의의 적절한 컴퓨팅 환경에서 수행될 수 있다. 예를 들어, 동작 흐름도는 도 1 및 도 2에 도시되어 있는 것과 같은 시스템에 의해수행될 수 있다. 따라서, 동작 흐름도(300,400,500,600)에 대한 설명은 도 1 및 도 2의 구성요소들 중 적어도 하나를 참조할 수 있다. 그러나, 도 1 및 도 2의 구성요소들에 대한 임의의 참조는 단지 설명을 위한 것이며, 도 1 및 도 2의 실시예는 동작 흐름도(300,400,500,600)에 대한 비제한적 환경임을 이해해야 한다.

또한, 동작 흐름도(300,400,500,600)가 비록 특정 순서로 설명 및 예시되어 있지만, 다른 실시예서, 동작들은 다른 순서로, 여러번, 및/또는 동시에 수행될 수 있다. 또한, 몇몇 실시예에서 하나 이상의 동작은 생략 또는 결합될 수 있다.

도 3은 디렉토리 메타데이터를 로컬 캐싱하기 위한 몇몇 실시예에 따른 동작 흐름도(300)를 나타낸다. 흐름도(300)는 (디렉토리 메타데이터의 일부를 포함하는) 디렉토리 메타데이터에 대한 요청이 애플리케이션으로부터 수신되는 동작(302)에서 시작한다. 몇몇 실시예에서, 동작(302)은 클라이언트 상에서 리디렉터에 의해 수신되는데, 이 리디렉터는 시스템(100)(도 1) 또는 시스템(200(도 2)과 같은 분산형 파일 시스템의 일부이다. 흐름도(300)는 임의의 특정 파일 액세스 프로토콜을 사용하여 구현되는 것에 국한되지 않는다. 임의의 적절한 파일 액세스 프로토콜이 사용되어 흐름(300)의 실시예를 구현할 수 있다.

흐름도는 동작(302)으로부터 판정동작(304)으로 넘어가는데, 이 판정동작에서, 요청된 메타데이터가 로컬 캐시내에 저장되어 있는지 여부가 판정된다. 판정동작(304)에서, 요청된 메타데이터가 로컬 캐시내에 저장되어 있는 것으로 판정되면, 흐름도는 메타데이터가 로컬 캐시로부터 검색되는 동작(306)으로 넘어간다. 동작(308)에서, 로컬 캐시로부터 검색된 메타데이터는 애플리케이션으로 제공된다. 흐름도(300)는 동작(310)에서 종료된다.

그러나, 판정동작(304)에서, 디렉토리 메타데이터가 로컬 캐시 내에 저장되어 있지 않은 것으로 판정되면, 제어는 판정동작(304)에서 동작(312)으로 넘어가는데, 이 동작(312)에서, 디렉토리 메타데이터에 의해 식별된 파일에 대한 디렉토리 키가 생성된다. 몇몇 실시예에서, 디렉토리 키는 흐름도(300)를 실행하는 리디렉터에 의해 생성되는 GUID이다. 동작(312) 이후, 디렉토리 메타데이터에 의해 식별된 디렉토리의 부모 디렉토리에 대한 디렉토리 키가 동작(314)에서 생성된다. 몇몇 실시예에서, 동작(314)은 디렉토리의 모든 선조(ancestors)에 대한 키를 생성하는 것을 포함할 수 있다. 이후, 키는 로컬 캐싱될 수 있다.

동작(316)에서, 요청이 파일 서버로 전송된다. 이 요청은 메타데이터 및 메타데이터의 로컬 캐싱을 허용하는 리스에 대한 것이다. 동작(318)에서, 파일 서버로부터 응답이 수신된다. 실시예에서, 이 응답은 요청된 리스가 파일 서버에 의해승인되었는지 여부에 대한 표시를 포함할 것이다. 흐름도는 동작(318)으로부터, 응답으로부터의 메타데이터가 애플리케이션에 제공되는 동작(320)으로 넘어간다. 동작(320)에 이어, 판정동작(322)에서 서버가 디렉토리 메타데이터에 대한 요청된 리스를 승인했는지 여부에 대한 판정이 이루어진다. 판정동작(322)에서, 리스가 승인되지 않은 것으로 판정되면, 메타데이터는 로컬 캐싱될 수 없고 흐름도는 동작(310)에서 종료된다. 판정동작(322)에서, 파일 서버에 의해 리스가 승인된 것으로 판정되면, 동작(324)에서 메타데이터는 로컬 캐시에 저장된다. 동작(324)이후, 흐름도는 동작(310)에서 종료된다.

이제 도 4를 참조하면, 디렉토리 메타데이터에 대한 핸들 리스를 보유하는 (분산형 파일 시스템을 액세스하는) 클라이언트에 의해 디렉토리 메타데이터를 수정하는 요청을 서비싱하는 몇몇 실시예에 따른 흐름도(400)가 도시되어 있다. 실시예에서, 흐름도(400)는 흐름도(300)가 실행된 이후 실행될 수 있다. 따라서, 흐름도(400)는 디렉토리 메타데이터를 캐싱하는 핸들 리스가 승인된 실시예에서 수행된다.

흐름도(400)는 디렉토리 메타데이터를 수정하는 요청이 수신되는 동작(402)에서 시작한다. 이 요청은 예를 들어 파일에 정보를 기록하는 기록 요청일 수 있고, 이 기록 요청은 메타데이터를 변경할 수 있으며, 비제한적 예는 수정 날짜 및 파일 크기를 포함한다. 디렉토리 메타데이터를 캐싱하는 핸들 리스는 파일 서버에 의해 흐름도(400)를 실행하는 클라이언트에 대해 이전에 승인되었다.

동작(404)에서, 요청으로부터의 정보, 즉 디렉토리 메타데이터를 수정하는 정보를 갖는 패킷, 예를 들어 파일에 기록되는 데이터가 생성된다. 리스가 미리 승인되었기 때문에, 리스와 연관된 제1 디렉토리 키 및 부모의 디렉토리 키가 존재한다. 따라서, 제1 디렉토리 키가 동작(406)에서 패킷에 포함되고 부모의 디렉토리 키가 동작(408)에서 패킷에 포함된다. 패킷은 동작(410)에서 서버에 전송된다. 몇몇 실시예에서, 클라이언트는 개방 요청시 제1 디렉토리 키 및 부모의 디렉토리 키를 초기에 전송한다. 서버는 개방시 모든 후속 동작에 대해 이들 키를 사용할 것이다. 그러나, 다른 실시예에서, 클라이언트는 각 동작에 대해 제1 디렉토리 키 및 부모 디렉토리 키를 제공할 수 있다.

동작(410) 이후, 흐름도는 변경된 메타데이터를 반영하도록 로컬 캐시가 업데이트되는 동작(412)으로 넘어간다. 다시 말해, 로컬 캐시는 가장 최근의 수정 날짜, 파일 크기 등의 변동을 반영하도록 업데이트된다. 흐름도(400)는 동작(414)에서 종료된다.

도 5는 디렉토리 메타데이터에 대한 판독 리스를 철회하는 통지를 처리하는 흐름도(500)를 나타낸다. 흐름도(500)는 클라이언트가 서버(204)(도 2)와 같은 서버로부터 판독 리스를 승인받은 후에 실행될 수 있다. 흐름도(500)는 디렉토리 메타데이터에 대해 이전에 승인된 판독 리스가 철회됨을 나타내는 철회 통지가 서버로부터 수신되는 동작(502)으로 시작한다. 몇몇 실시예에서, 철회 통지는 캐싱된 디렉토리 메타데이터의 일관성에 영향을 미치는 다른 클라이언트에 의해 수행된 행위, 예를 들어 디렉토리 내의 파일에 대한 수정 때문에 서버에 의해 전송된다. 철회 통지의 수신에 응답하여, 흐름도(500)는 임의의 캐싱된 디렉토리 메타데이터가 무효화되는 동작(504)으로 넘어간다. 몇몇 실시예에서, 동작(504)은 디렉토리 메타데이터를 요청하는 애플리케이션에 디렉토리 메타데이터를 제공하는데 더 이상 캐시가 사용될 수 없음을 나타내기 위해 클라이언트에 의해 수행되는 다수의 단계를 포함한다.

동작(504) 이후, 흐름도는 철회 통지가 성공적으로 수신되었음을 나타내는 확인이 서버로 전송되는 동작(506)으로 넘어간다. 몇몇 실시예에서, 흐름도(500)는 동작(506)을 포함하지 않을 수 있다. 이들 실시예에서, 클라이언트는 철회 통지를 수신하나 확인을 서버에 전송하지 않는다. 흐름도는 디렉토리 메타데이터를 서버로부터 요청함으로써 디렉토리 메타데이터에 대한 임의의 요청이 서비싱되는 동작(508)으로 넘어간다. 흐름도(500)는 동작(510)에서 종료된다.

도 6은 디렉토리 메타데이터르 로컬 캐싱할 수 있는 몇몇 실시예에 따른 동작 흐름도(600)를 나타낸다. 몇몇 실시예에서, 흐름도(600)는 분산형 파일 시스템의 일부인 파일 서버에 의해 실행될 수 있다.

흐름도(600)는 디렉토리 메타데이터에 대한 요청 및 리스가 수신되는 동작(602)으로 시작한다. 몇몇 실시예에서, 요청은 클라이언트, 또는 분산형 파일 시스템의 일부인 클라이언트 상의 리디렉터에 의해 전송된다. 동작(602) 이후, 흐름도(600)는 동작(602)에서 수신된 요청에서 요청된 리스를 승인할 지 여부를 판정하는 판정동작(604)으로 넘어간다. 판정동작(604)은 예를 들어 디렉토리 메타데이터에 대한 리스가 이미 승인되었는지 여부를 포함하여 여러 요소에 기초할 수 있다. 판정동작(604)에서, 리스를 승인하지 않기로 판정되면, 흐름도는 디렉토리 메타데이터를 갖는 패킷이 전송되는 동작(606)으로 넘어간다. 패킷은 요청된 리스가 승인되지 않았다는 표시를 포함할 것이다. 흐름도는 동작(608)에서 종료된다.

판정동작(604)에서, 리스가 승인될 수 있다고 판정되면, 흐름도(600)는 디렉토리 키 및 부모 디렉토리 키가 저장되는 동작(610)으로 넘어간다. 몇몇 실시예에서, 디렉토리 키 및 부모 디렉토리 키는 클라이언트에 승인된 리스를 추적하는 리스 키로서 사용되는 GUID이다. 몇몇 실시예에서, 동작(602)에서 디렉토리 키 및 부모 디렉토리 키가 디렉토리 메타데이터에 대한 요청 및 리스 요청과 함께 수신된다. 이 실시예에서, 디렉토리 키 및 부모 디렉토리 키는 동작(602)에서 요청을 전송하는 클라이언트에 의해 생성되었다. 다른 실시예에서, 디렉토리 키 및 부모 디렉토리 키는 서버에 의해 생성될 수 있고 동작(610)에서 리스 테이블에 저장된다.

몇몇 실시예에서, 디렉토리 및 부모 디렉토리 키는 2 이상의 개방 핸들 간의 컨테이너-자식 관계(container-child relationship)를 표현한다. 이는 파일 키 및 디렉토리 키에도 적용되며, 파일 키는 디렉토리 내의 파일과 연관된다. 예를 들어, 개방된 2개의 핸들(H1,H2)이 존재하는 것으로 가정한다. H1은 파일 키=K1 및 디렉토리 키=D와 연관될 수 있다. H2는 파일 키=K2 및 디렉토리 키=D와 연관될 수 있다. 키는 이들 핸들에 의해 참조되는 파일이 동일한 디렉토리 내에 상주함을 나타낸다.

다시 도 6을 참조하면, 동작(612)에서, 요청된 디렉토리 메타데이터 및 리스의 승인에 대한 표시를 갖는 응답 패킷이 클라이언트에 전송된다. 클라이언트는 승인된 리스에 따라 디렉토리 메타데이터를 로컬 캐싱할 수 있다.

동작(614)에서, 디렉토리 메타데이터를 수정하는 요청이 수신된다. 이 요청은 예를 들어 추가의 정보를 파일에 기록하는 것일 수 있다. 이것은 예를 들어, 마지막 수정 시간, 또는 파일 크기를 변경함으로써 디렉토리 메타데이터를 수정할 것이다. 흐름도는 동작(614)에서 디렉토리 메타데이터를 수정하는 요청이 리스 보유자로부터 온 것인지에 대한 판정이 이루어지는 판정동작(616)으로 넘어간다.

일 실시예에서, 판정동작(616)에서 이루어진 판정은 디렉토리 메타데이터를 수정하는 동작이 수행되는 핸들과 연관된 리스 키를 이전에 클라이언트에 제공된 핸들과 연관된 리스 키와 비교함으로써 이루어진다. 전술한 바와 같이, 몇몇 실시예에서, 클라이언트는 파일 핸들(또는 디렉토리 핸들)과 연관된 리스 키를 생성하고, 따라서 각 키는 특정 클라이언트에 고유할 것이다. 일 실시예에서, 클라이언트에 제공된 핸들(H1)은 파일 키=K1 및 디렉토리 키=D와 연관된다. 이후 서버가 핸들(H2)과 연관된 메타데이터를 수정하는 동작을 수신하는 경우, 서버는 핸들(H2)과 연관된 리스 키를 핸들(H1)과 연관된 리스 키와 비교한다. 예를 들어, H2가 파일 키=K2 및 디렉토리 키=D와 연관된 경우, 서버는, H1 및 H2에 대한 디렉토리 키들이 동일하기 때문에 디렉토리(D)에 대한 리스를 갖는 동일한 클라이언트가 수정을 행하였고 따라서 리스는 철회될 필요가 없다고 판정한다. 그러나, H2가 파일 키=K2 및 디렉토리 키=D1와 연관된 경우, 서버는, 핸들(H1 및 H2)과 연관된 디렉토리 키들이 다르기 때문에 리스가 철회되어야 한다고 판정한다.

리스 보유자가 디렉토리 메타데이터에 대한 수정을 행하는 것으로 판정되면, 흐름도는 수정된 디렉토리 메타데이터를 반영하도록 파일 시스템이 업데이트되는 동작(618)으로 넘어간다. 흐름도(600)는 동작(608)에서 종료된다.

판정동작(616)에서 요청이 리스 보유자로부터 온 것이 아니라고 판정되면, 흐름도는 요청된 수정이 다른 클라이언트에 주어진 리스와 불일치하는지 여부에 대한 판정이 이루어지는 판정동작(620)으로 넘어간다. 요청이 불일치하는 경우, 흐름도는 동작(618)으로 넘어가고 동작(608)에서 종료된다.

판정동작(620)에서, 요청이 리스와 불일치하는 것으로 판정되면, 흐름도는 동작(622)으로 넘어가고, 이 동작(622)에서, 디렉토리 메타데이터에 대한 리스를 현재 보유하고 있는 클라이언트로 철회 통지가 전송된다. 이 철회는 디렉토리 메타데이터에를 액세스하는 모든 클라이언트 사이에서 디렉토리 메타데이터의 일관성을 유지하기 위해 전송된다. 동작(624)에서 철회 통지의 확인이 수신되고, 그 후 흐름도는 동작(618)으로 넘어가고 동작(608)에서 종료된다.

도 7은 본 명세서에서 기술된 실시예를 구현하는데 사용될 수 있는 일반적인 컴퓨터 시스템(700)을 나타낸다. 컴퓨터 시스템(700)은 컴퓨팅 환경의 일 예일뿐이고 컴퓨터 및 네트워크 아키텍처의 사용 또는 기능의 범주에 대한 어떠한 제한도 두지 않는다. 컴퓨터 시스템(700)은, 예시적인 컴퓨터 시스템(700)에 도시되어 있는 구성요소들의 임의의 하나 이상의 조합에 대한 어떠한 종속성 또는 요구사항을 가지지 않는 것으로 이해되어야 한다. 몇몇 실시예에서, 시스템(700)은 도 1 및 도 2에 대해 전술한 클라이언트 및/또는 서버로서 사용될 수 있다.

가장 기본적인 구성에서, 시스템(700)은 전형적으로 적어도 하나의 처리 장치(702) 및 메모리(704)를 포함한다. 컴퓨팅 장치의 정확한 구성 및 유형에 따라, 메모리(704)는 휘발성(예를 들어, RAM), 비휘발성(예를 들어, ROM, 플래시 메모리 등) 또는 이들 둘의 조합일 수 있다. 이러한 가장 기본적인 구성은 도 7에서 점선으로 도시되어 있다. 시스템 메모리(704)는 시스템(700)에서 실행되는 애플리케이션을 저장한다. 예를 들어, 메모리(704)는 도 2와 관련하여 설명한 리포트 룩업 테이블(214)을 저장할 수 있다.

본 명세서에서 사용되는 컴퓨터 판독가능 매체라는 용어는 컴퓨터 저장 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 그 밖의 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술에서 구현되는 휘발성 및 비휘발성, 착탈가능 및 비착탈가능 매체를 포함할 수 있다. 시스템 메모리(704), 착탈가능 저장소 및 비착탈가능 저장소(708)는 모두 컴퓨터 저장 매체 예(즉, 메모리 저장소)이다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 다른 메모리 기술, CD-ROM, DVD 또는 다른 광학 저장 장치, 또는 정보를 저장하는데 사용될 수 있고 컴퓨팅 장치(700)에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있으나, 이에 국한되지는 않는다. 이러한 임의의 컴퓨터 저장 매체는 장치(700)의 일부일 수 있다. 컴퓨팅 장치(700)는 또한 키보드, 마우스, 펜, 소리 입력 장치, 터치 입력 장치 등과 같은 입력 장치(들)(714)를 구비할 수 있다. 디스플레이, 스피커, 프린터 등과 같은 출력 장치(들)(616)도 포함될 수 있다. 전술한 장치들은 예시이며 다른 장치들이 사용될 수 있다.

본 명세서에서 사용되는 컴퓨터 판독가능 매체라는 용어는 또한 통신 매체를 포함할 수 있다. 통신 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 또는 반송파 또는 다른 운송 메카니즘과 같은 변조 데이터 신호 내의 다른 데이터에 의해 구현될 수 있고 임의의 정보 전달 매체를 포함한다. "변조 데이터 신호"라는 용어는 신호 내에 정보를 인코딩하도록 설정 또는 변경된 하나 이상의 특성을 갖는 신호를 나타낼 수 있다. 예를 들어, 통신 매체는 유선 네트워크 또는 직도선(direct-wired) 접속과 같은 유선 매체, 및 음향, 무선 주파수(RF), 적외선, 및 다른 무선 매체와 같은 무선 매체를 포함할 수 있다.

본 명세서에서 "일 실시예"는 설명된 특정 특징, 구조 또는 특성이 적어도 하나의 실시예에 포함됨을 의미한다. 따라서, 이러한 어구는 하나 이상의 실시예를 지칭할 수 있다. 또한, 설명된 특징, 구조 또는 특성은 하나 이상의 실시예에서 임의의 적절한 방식으로 결합될 수 있다.

그러나, 당업자라면 알 수 있는 바와 같이, 본 발명은 하나 이상의 구체적인 설명없이도 구현될 수 있거나, 다른 방법, 리소스, 방식 등으로 구현될 수 있다. 다른 예로서, 본 발명의 측면들을 불명료하게 하는 것을 단지 피하기 위해 잘 알려져 있는 구조, 리소스 또는 동작들은 도시 또는 설명되지 않았다.

예시적인 실시예 및 애플리케이션들이 도시 및 설명되었지만, 본 발명은 전술한 그대로의 구성 및 리소스에 국한되지 않는다. 본 발명의 범주를 벗어나지 않는 한 본 명세서에서 설명한 방법 및 시스템의 구성, 동작 및 세부사항에 대한 다양한 수정, 변경 및 변형들이 당업자에 의해 구현될 수 있다.

Claims

디렉토리 메타데이터를 로컬 캐싱하기 위한 컴퓨터 구현 방법으로서,
디렉토리 메타데이터에 대한 제1 요청을 애플리케이션으로부터 수신하는 단계;
상기 제1 요청의 수신에 응답하여, 상기 디렉토리 메타데이터에 대한 제2 요청을 서버로 전송하는 단계- 상기 제2 요청은, 상기 디렉토리 메타데이터를 포함하는 디렉토리에 대한 핸들의 요청, 상기 디렉토리 메타데이터를 로컬 캐싱하기 위한 리스의 요청, 상기 요청된 디렉토리 메타데이터를 포함하는 제 1 디렉토리와 연관되는 생성된 키, 및 제 2 디렉토리와 연관되는 생성된 디렉토리 키를 포함하며, 상기 리스는 상기 서버가 상기 리스를 철회할 때까지 상기 디렉토리 메타데이터의 로컬 캐싱을 허용하고, 상기 제 1 디렉토리는 상기 제 2 디렉토리에 포함됨 -;
상기 서버로부터 제1 응답을 수신하는 단계- 상기 제1 응답은 상기 디렉토리 메타데이터, 및 상기 리스의 요청의 승인에 대한 표시를 포함함 -;
상기 디렉토리 메타데이터를 로컬 캐시에 저장하는 단계; 및
상기 디렉토리 메타데이터를 상기 애플리케이션에 제공하는 단계를 포함하는
방법.
제1항에 있어서,
상기 리스의 요청은 판독 캐싱, 기록 캐싱, 및 핸들 캐싱 중 하나 이상을 위한 요청을 표시하는 플래그를 포함하는
방법.
제1항에 있어서,
상기 디렉토리 메타데이터에 대한 제3 요청을 제2 애플리케이션으로부터 수신하는 단계; 및
상기 제3 요청의 수신에 응답하여, 상기 디렉토리 메타데이터를 상기 로컬 캐시로부터 제공하는 단계를 더 포함하는
방법.
제1항에 있어서,
상기 제2 디렉토리 내에 저장된 파일을 수정하기 위한 제3 요청을 제2 애플리케이션으로부터 수신하는 단계;
상기 제3 요청의 수신에 응답하여,
상기 파일과 연관된 파일 키를 생성하는 단계; 및
상기 제3 요청으로부터의 데이터, 상기 파일과 연관된 파일 키 및 제2 디렉토리와 연관되는 생성된 디렉토리 키를 포함하는 제4 요청을 상기 서버에 전송하는 단계를 더 포함하는
방법.
제1항에 있어서,
상기 제2 디렉토리와 연관되는 생성된 디렉토리 키 및 상기 제1 디렉토리와 연관되는 생성된 키를 룩업 테이블 내에 저장하는 단계를 더 포함하되,
상기 룩업 테이블은 상기 제1 디렉토리와 연관되는 생성된 키와 상기 제2 디렉토리와 연관되는 생성된 디렉토리 키의 연관성을 저장하는
방법.
제1항에 있어서,
상기 리스의 요청은 상기 서버가 리스 키를 생성하는 요청을 포함하는
방법.
제1항에 있어서,
상기 서버로부터, 상기 리스의 철회 통지를 수신하는 단계;
상기 철회 통지의 수신에 응답하여,
상기 철회 통지의 수신에 대한 확인을 전송하는 단계; 및
상기 디렉토리 메타데이터를 상기 로컬 캐시로부터 제거하는 단계를 더 포함하는
방법.
제1항에 있어서,
상기 디렉토리 메타데이터가 변경되었다는 통지를 서버로부터 수신하는 단계; 및
상기 통지의 수신에 대한 확인을 전송하는 단계를 더 포함하는
방법.
제1항에 있어서,
상기 제1 디렉토리와 연관되는 생성된 키는 디렉토리 키 또는 파일 키 중 하나인
방법.
제7항에 있어서,
상기 철회 통지의 수신 이후에:
상기 디렉토리 메타데이터에 대한 제 3 요청을 제 2 애플리케이션으로부터 수신하는 단계; 및
상기 제 3 요청의 수신에 응답하여, 상기 디렉토리 메타데이터에 대한 제 4 요청을 상기 서버에 전송하는 단계를 더 포함하는
방법.
디렉토리 메타데이터를 로컬 캐싱하도록 구성된 컴퓨터 시스템으로서,
적어도 하나의 프로세서; 및
상기 적어도 하나의 프로세서에 의해 실행되는 경우 방법을 수행하는 실행가능 명령어를 저장하는 컴퓨터 판독가능 저장 매체를 포함하되,
상기 방법은,
서버에서 디렉토리 메타데이터에 대한 제1 요청을 제1 클라이언트로부터 수신하는 단계- 상기 제1 요청은 상기 디렉토리 메타데이터를 포함하는 디렉토리에 대한 핸들에 대한 요청, 상기 디렉토리 메타데이터를 로컬 캐싱하기 위한 리스에 대한 요청, 상기 요청된 디렉토리 메타데이터를 포함하는 제 1 디렉토리와 연관되는 생성된 키, 및 제 2 디렉토리와 연관되는 생성된 디렉토리 키를 포함하고, 상기 리스는 상기 서버가 상기 리스를 철회할 때까지 상기 디렉토리 메타데이터의 로컬 캐싱을 허용하고, 상기 제 1 디렉토리는 상기 제 2 디렉토리에 포함됨 -; 및
제1 응답을 상기 제 1 클라이언트로 전송하는 단계- 상기 제1 응답은 상기 디렉토리 메타데이터, 및 상기 리스에 대한 요청의 승인에 대한 표시를 포함함-를 포함하는
컴퓨터 시스템.
제11항에 있어서,
상기 리스에 대한 요청은 판독 캐싱, 기록 캐싱, 및 핸들 캐싱 중 하나 이상에 대한 요청을 표시하는 플래그를 포함하는
컴퓨터 시스템.
제11항에 있어서,
상기 방법은,
제2 요청을 수신하는 단계;
상기 제2 요청이 제2 클라이언트로부터 수신된 것인지를 판정하는 단계- 상기 제2 요청은 상기 디렉토리 메타데이터를 수정함 -를 더 포함하는
컴퓨터 시스템.
제11항에 있어서,
상기 방법은,
상기 제 1 요청의 수신에 응답하여 상기 디렉토리에 대한 상기 핸들과 연관된 파일 키를 생성하고 상기 디렉토리의 부모 디렉토리와 연관된 디렉토리 키를 생성하는 단계; 및
상기 서버에 전송된 상기 제 1 응답에 상기 파일 키 및 상기 디렉토리 키를 포함하는 단계를 더 포함하는
컴퓨터 시스템.
제13항에 있어서,
상기 제2 요청이 제2 클라이언트로부터 수신된 것인지를 판정하는 단계는 상기 제 2 요청으로부터의 디렉토리 키를 이전에 저장된 디렉토리 키와 비교하는 단계를 포함하는
컴퓨터 시스템.
제15항에 있어서,
상기 방법은,
상기 제 2 요청으로부터의 상기 디렉토리 키가 이전에 수신된 제 2 디렉토리와 연관되는 생성된 디렉토리 키와 동일하지 않다는 판정에 응답하여 상기 리스를 철회하는 철회 통지를 상기 제 1 클라이언트로 전송하는 단계를 더 포함하는
컴퓨터 시스템.
실행될 때 방법을 수행하는 컴퓨터 실행가능한 명령어를 저장한 컴퓨터 판독가능 저장 디바이스로서,
상기 방법은,
디렉토리 메타데이터에 대한 제 1 요청을 애플리케이션으로부터 클라이언트 리디렉터에서 수신하는 단계;
상기 제 1 요청의 수신에 응답하여 그리고 상기 애플리케이션에 투명하게:
상기 디렉토리 메타데이터를 포함하는 제 1 디렉토리와 연관된 제 1 GUID(globally unique identifier) 및 상기 제 1 디렉토리를 포함하는 제 2 디렉토리와 연관된 제 2 GUID를 생성하는 단계;
파일 액세스 프로토콜에 따라 포맷된 패킷을 상기 디렉토리 메타데이터에 대한 서버로 전송하는 단계 - 상기 패킷은 상기 제 1 디렉토리에 대한 핸들에 대한 요청, 상기 디렉토리 메타데이터를 로컬 캐싱하기 위한 리스에 대한 요청, 및 상기 제 1 GUID 및 상기 제 2 GUID를 포함하고, 상기 리스는 상기 서버가 상기 리스를 철회할 때까지 상기 디렉토리 메타데이터의 로컬 캐싱을 허용함 -;
상기 서버로부터 제 2 패킷을 수신하는 단계 - 상기 제 2 패킷은 상기 디렉토리 메타데이터 및 상기 리스에 대한 요청의 승인에 대한 표시를 포함함 -;
상기 디렉토리 메타데이터를 로컬 캐시에 저장하는 단계; 및
상기 디렉토리 메타데이터를 상기 애플리케이션에 제공하는 단계를 포함하는
컴퓨터 판독가능 저장 디바이스.
제17항에 있어서,
상기 방법은,
상기 디렉토리 메타데이터에 대한 제 2 요청을 제 2 애플리케이션으로부터 수신하는 단계;
상기 제 2 요청의 수신에 응답하여, 상기 로컬 캐시로부터 상기 디렉토리 메타데이터를 제공하는 단계를 더 포함하는
컴퓨터 판독가능 저장 디바이스.
제18항에 있어서,
상기 방법은,
상기 제 1 디렉토리 내에 저장된 파일을 수정하기 위한 제 3 요청을 제 2 애플리케이션으로부터 수신하는 단계;
상기 제 3 요청의 수신에 응답하여:
상기 파일과 연관된 제 3 GUID를 생성하는 단계; 및
상기 제 3 요청으로부터의 데이터, 상기 파일과 연관된 제 3 GUID, 및 상기 제 2 디렉토리와 연관된 상기 제 2 GUID와 함께 제 3 패킷을 상기 서버에 전송하는 단계를 더 포함하는
컴퓨터 판독가능 저장 디바이스.
제19항에 있어서,
상기 방법은 상기 제 1 GUID 및 상기 제 2 GUID와 관련하여 룩업 테이블에 상기 제 3 GUID를 저장하는 단계를 더 포함하는
컴퓨터 판독가능 저장 디바이스.