KR102438595B1

KR102438595B1 - Sfa-rest 인터페이스를 이용하는 파일 서비스 기법

Info

Publication number: KR102438595B1
Application number: KR1020167031467A
Authority: KR
Inventors: 브래들리 진 캘더; 앤드류 제임스 에드워즈; 이샤이 벤 아로야; 데이비드 앨런 고에벨; 지에쉥 우; 자이덴 하리다스; 슈바브라타 갱굴리; 매튜 더글라스 헨델; 오잔 데미르; 진 가넴
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2014-05-11
Filing date: 2015-05-11
Publication date: 2022-08-31
Also published as: JP6626459B2; US20150324386A1; CN106415538A; RU2016144155A3; US11641397B2; CN106415538B; RU2016144155A; BR112016025156B1; MX371406B; US10536523B2; JP2017516231A; EP3143520B1; CA2946674A1; WO2015175413A1; BR112016025156A8; AU2015259419A1; RU2686594C2; AU2015259419B2; US20200351346A1; MX2016014641A

Abstract

다양한 실시예에서 파일 시스템으로의 액세스를 제공하기 위한 방법 및 시스템이 제공된다. 파일 시스템 내 파일에 대한 동작 수정자를 갖는 SFA 기반 동작이 수신된다. SFA 기반 동작이 REST(representational state transfer, 파일-표현 상태 전달) 인터페이스에 기초해서 정의된다. SFA-REST 인터페이스가 SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함한다. SFA 기반 동작이 동작 수정자를 이용해 실행된다. 분산된 파일 저장소 내 파일에 대한 REST 기반 동작이 수신된다. 상기 REST 기반 동작이 SFA-REST 인터페이스에 기초해서 정의된다. 상기 동작 수정자는 REST 기반 동작을 실행하도록 참조된다. REST 기반 동작이 SFA-REST 인터페이스에 기초해서 한다. 스키마가 파일 시스템을 액세스하기 위해 구현될 수 있다. 상기 스키마는 파일을 저장하도록 테이블을 포함하며, 상기 테이블은 SFA-REST 인터페이스의 요소에 대응하는 필드를 포함한다.

Description

SFA-REST 인터페이스를 이용하는 파일 서비스 기법{FILE SERVICE USING A SHARED FILE ACCESS-REST INTERFACE}

복수의 다양한 유형의 데이터 액세스 프로토콜에 의해 데이터 액세스가 촉진된다. 데이터 액세스 프로토콜은 컴퓨터 내부의 데이터 통신 또는 컴퓨터 사이의 데이터 통신을 위한 규칙을 제공한다. 다양한 유형의 데이터 액세스 프로토콜은 데이터를 액세스하는 데 일정한 이점을 제공한다. 특히, 공유 파일 액세스("SFA")(shared file access) 프로토콜, 예컨대, 서버 메시지 블록("SMB")(Server Message Block)이 사용되어 파일 시스템 자원을 액세스하고, 지정된 아키텍처 제약에 의해 한정되는 클라이언트 서버 인터렉션을 위해 표현 상태 전송("REST")(Representation State Transfer) 프로토콜이 또한 사용될 수 있다. 각각의 프로토콜은, 데이터를 액세스하는 메시지를 통신하기에 잘 규정된 형식을 갖고 있다. 따라서, 프로토콜이 데이터 액세스 서비스로 링크되도록 애플리케이션 프로그래밍 인터페이스(API)로 구현될 때, 하나의 프로토콜의 API 라이브러리는 불가피하게 다른 프로토콜 API를 배제한 상태에서 기능한다. 이와 관련하여, 종래의 데이터 액세스 프로토콜 및 API는 통합 SMB 및 REST 기능을 포괄적으로 지원할 수 없기 때문에, 통합 파일 공유 및 제약-기반 클라이언트 서버 인터렉션을 촉진하는 데 효과적이지 않다. 배경이 되는 기술의 예로는 미국등록특허 제6385701호가 있다.

본 개요는 이하의 상세한 설명에서 더 기재될 개념 중 일부를 선택해서 개략적으로 소개하기 위해 제공된다. 이 개요는 본 발명의 핵심 특징 또는 필수 특징을 나타내는 것이 아니며, 청구 대상의 범주를 결정하는 것을 별도로 돕는데 사용되는 것도 아니다.

다양한 실시예에서, 파일 시스템으로의 액세스를 제공하기 위한 방법 및 시스템이 제공된다. 파일 시스템 내 파일에 대한 동작 수정자를 갖는 SFA 기반 동작이 수신된다. SFA 기반 동작이 파일-REST(representational state transfer) 인터페이스에 기초해서 정의된다. SFA-REST 인터페이스는 SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함한다. 분산된 파일 저장소 내 파일에 대한 REST 기반 동작이 수신된다. REST 기반 동작이 SFA-REST 인터페이스에 기초해서 정의된다. SFA 기반 동작은 동작 수정자를 이용해 실행된다. 동작 수정자는 REST 기반 동작을 실행하는데 참조된다. REST 기반 동작은 SFA-REST 인터페이스에 기초해서 실행된다. 파일 시스템을 액세스하도록 파일 스키마(schema)가 구현될 수 있다. 스키마는 파일을 저장하기 위한 테이블을 포함하며, 테이블은 SFA-REST 인터페이스의 요소에 대응하는 필드를 포함한다. 파일 시스템에 파일 공유를 백업하기 위해 스냅샷 구성요소가 구현될 수 있음이 더 고려된다.

본 발명은 첨부된 도면을 참조하여 이하에서 더 상세히 기재된다.
도 1은 본 발명의 실시예를 구현하는 데 사용되기에 적합한 예시적 컴퓨팅 환경의 블록도이다.
도 2a 내지 도 2d는 본 발명의 실시예가 사용될 수 있는 예시적 클라우드 컴퓨팅 인프라구조 및 플랫폼의 블록도이다.
도 3은 본 발명의 실시예에 따른, 분산된 파일 시스템 내의 파일에 액세스하기 위한 방법을 나타내는 흐름도이다.
도 4는 본 발명의 실시예에 따른, 파일 공유를 스냅샷하기 위한 방법을 나타내는 흐름도이다.
도 5는 본 발명의 실시예에 따른, 분산된 파일 시스템 내의 파일에 액세스하기 위한 방법을 나타내는 흐름도이다.
도 6은 본 발명의 실시예에 따른, 분산된 파일 시스템 내의 파일에 액세스하기 위한 방법을 나타내는 흐름도이다.

본 명세서에서 법정 요건을 충족하기 위해서, 본 발명의 실시예의 청구 대상을 상세하게 설명한다. 그러나 기재 자체는 본 특허의 범위를 한정하려는 것이 아니다. 오히려, 본 발명의 발명자는 청구되는 대상이 그 밖의 다른 현재 또는 미래의 기술에 맞춰서, 본 명세서에 기재된 것과 상이한 단계를 포함하거나 유사한 단계들의 조합을 포함하도록 그 밖의 다른 방식으로 구현될 수 있음을 알 것이다. 덧붙여, 본 명세서에서 용어 "단계" 및/또는 "블록"이 사용되는 방법의 다양한 요소를 가리키는데 사용될 수 있지만, 개개의 단계의 순서가 명시적으로 기재되어 있지 않는 한, 이들 용어는 본 명세서에 개시된 다양한 단계들 간의 임의의 특정 순서를 나타내는 것으로 해석되어서는 안 된다.

본 개시의 목적으로, 용어 "구비한다"는 용어 "포함한다"와 같은 넓은 의미를 갖는다. 나아가, 단어 "하나의" 및 "한"은 별도로 언급되지 않는 한, 복수 형태는 물론 단수 형태까지 포함한다. 따라서, 예를 들어, "특징부"의 요건은 하나 이상의 특징부가 존재할 때 만족된다. 또한 용어 "또는"은 연접 형태, 이접 형태, 및 둘 모두를 포함한다(따라서 a 또는 b는 a 또는 b뿐 아니라 a 및 b도 포함한다).

이하에서의 상세 개시의 목적으로, 본 발명의 실시예가 HTTP를 통한 SFA 및 REST 기반 동작을 이용하고, 클라우드 컴퓨팅 플랫폼에서 파일 서비스를 지원하도록 인터렉션하는 SFA 기반 동작을 참조하여 기재되나, 클라우드 컴퓨팅 플랫폼 상의 파일 서비스에 대한 SFA-REST 인터페이스를 통한 콘텐츠 공유는 예시에 불과하며, 기재된 기법이 SFA 기반 동작과 REST 기반 동작이 인터렉션하는 그 밖의 다른 구현 맥락까지 확장될 수 있다.

파일, 프린터, 직렬 포트 및 네트워크 상 노드 간 통신에 공유 액세스를 제공하기 위해서 공유 파일 액세스 프로토콜이 사용된다. 구체적으로, 공유 파일 액세스 프로토콜은 클라이언트가 파일이 로컬 컴퓨터 상에 있는 것처럼 파일을 조작하는 것을 가능하게 한다. 동작, 가령, 읽기, 쓰기, 생성하기, 삭제하기가 모두 지원되며, 유일한 차이점은 파일이 컴퓨팅 장치에 로컬하지 않고 실제로는 원격 서버 상에 있다는 것이다.

공유 파일 액세스 프로토콜 구현예는 클라이언트가 특정 요청을 하고 서버가 이에 따라 응답하는 클라이언트-서버 방식을 통해 동작한다. 특히, SMB 프로토콜이 클라이언트가 파일 서버에 요청을 할 수 있도록 하는 파일 시스템 액세스를 제공한다. 배경기술로서, 파일 시스템은 파일 시스템 저장소 내 정보가 서로 구별될 수 있도록 데이터가 저장 및 취득 방식을 제어하는 데 사용된다. 데이터 및 이들의 명칭을 관리하기 위해 사용되는 구조 및 로직 규칙이 파일 시스템이라고 지칭된다. SMB 서버를 통해서, 이들 파일 시스템 및 그 밖의 다른 자원을 네트워크 상의 클라이언트가 이용 가능할 수 있게 된다. 따라서 SMB 프로토콜은 바람직한 파일 공유 프로토콜이다.

표현 상태 전송("REST")은 분산된 하이퍼미디어 시스템에 의해 구성요소, 커넥터 및 데이터 요소에 적용되는 아키텍처 제약의 조화된(coordinated) 세트로 구성된 소프트웨어 아키텍처 스타일을 지칭한다. 이와 관련하여, REST 프로토콜은 아키텍처 제약 프로토콜로서 기술될 수 있다. 형식적인 REST 아키텍처 제약은 클라이언트-서버, 무상태(stateless), 캐싱 가능(cacheable), 자기-설명적 메시지(self-descriptive message), 및 표현을 통한 자원의 조작 등을 포함한다. 특히, 무상태는 요청들 사이에 서버 상에 어떠한 클라이언트 상황정보(context)도 저장되지 않음으로써 클라이언트-서버 통신이 제약되거나, 요청들 사이에 클라이언트에서 어떠한 상태도 전혀 유지되지 않을 수 있는 표기를 지칭할 수 있다. 임의의 클라이언트 제약으로부터의 각각의 요청이 요청을 서비스하는 데 필요한 모든 정보를 포함하고, 세션 상태가 클라이언트 내에 보유된다. REST는 또한 하이퍼텍스트 전송 프로토콜("HTTP")(Hypertext Transfer Protocol)을 통해 실행되도록 구성될 수 있다. 예를 들어, 확장 마크업 언어("XML")(Extensible Markup Language) 파일을 포함하는 지정된 웹 페이지가 판독될 수 있고, 이때, XML은 원하는 콘텐츠를 기술하고 가진다. API로서 구현되는 REST 프로토콜은 모바일 애플리케이션, 소셜 네트워킹 웹 사이트, 및 자동화된 비즈니스 프로세스에서 사용될 수 있다. REST 스타일이 클라이언트와 서비스 간 인터렉션이 제한된 수의 동작을 가짐으로써 향상됨을 강조한다. 자원에 이들 고유의 전역 자원 식별자("URI")(universal resource identifier)가 할당될 수 있다.

일반적으로 컴퓨팅 플랫폼이 플랫폼 내에서 실행되고, 제약을 따르며, 플랫폼 기능을 이용하도록 설계된 소프트웨어를 갖는 기존 환경을 지칭할 수 있다. 상기 플랫폼은 하드웨어 아키텍처 및 소프트웨어 프레임워크를 포함하고, 여기서 조합에 의해 클라이언트와 서버가 데이터 액세스 프로토콜을 이용해 통신할 수 있다. 일반적인 플랫폼은 하드웨어 아키텍처, 운영 체제, 및 런타임 라이브러리를 포함한다. 하드웨어 아키텍처는 물리적 구성요소 및 상호관계의 식별을 지칭하고, 소프트웨어 프레임워크는 소프트웨어가 일반적인 기능을 제공하는 추상 개념을 지칭한다. 특히, 소프트웨어 프레임워크(가령, REST API)는 블롭 저장소(blob storage)에서 블롭으로의 액세스를 가능하게 할 수 있다. 이와 관련하여, 예를 들어, 소비자는 전용 플랫폼 인프라구조 상에 적용되도록 블록 저장소의 데이터(가령, 블롭 데이터)를 액세스할 수 있다. 플랫폼은 분산된 클라우드 컴퓨팅 인프라구조에서 컴퓨팅 플랫폼으로서 구현될 수 있다.

일반적으로, 클라우드 컴퓨팅 플랫폼은 분산 방식으로 데이터를 저장하거나 서비스 애플리케이션을 실행하도록 동작한다. 컴퓨팅 플랫폼은 넓은 지리적 위치,가령, 국가와 대륙에 걸쳐 있을 수 있다. 클라우드 컴퓨팅 플랫폼은 서로 다른 유형의 서비스, 가령, 컴퓨팅 서비스(가령, 가상 머신, 웹 사이트, 클라우드 서비스, 및 모바일 서비스), 데이터 서비스(가령, 저장소, SQL 데이터베이스, SQL 리포팅, 테이블, 백업 및 복원), 네트워킹 서비스(가령, 가상 네트워크, 트래픽 관리자, 데이터 전송), 및 애플리케이션 서비스(가령, 미디어 서비스, 서비스 버스, 통지 허브, 및 다요소 인증)를 제공하는 공개 클라우드(public cloud)일 수 있다. 예를 들어, 클라우드 컴퓨팅 플랫폼은 서비스 애플리케이션을 실행시키고 인터넷-액세스 가능한 데이터센터 내 머신 상에 데이터를 저장하기 위해 제공된다.

클라우드 컴퓨팅 플랫폼 구성요소(가령, 패브릭 제어기(fabric controller))는 컴퓨터 자원, 네트워크 기어(network gear), 직렬 장치 및 패브릭의 기저 기능을 지원하는 전력 유닛의 건강 상태의 모니터링, 유지보수, 및 관리 전반을 더 담당한다. 본 발명의 실시예에 따라 다양한 유형의 클라우드 구성이 구현될 수 있고, 따라서 해당 분야의 통상의 기술자라면 클라우드 컴퓨팅 플랫폼의 적합한 구조가 사용될 수 있고 본 발명의 실시예가 본 명세서에 기재된 것에 한정되지 않음을 알 것이다.

플랫폼은 데이터의 액세스를 지원하는 서비스를 지원할 수 있다. 데이터 액세스는 서로 다른 유형의 데이터 액세스 프로토콜에 의해 촉진된다. 데이터 액세스 프로토콜은 컴퓨터 내부의 또는 컴퓨터들 간의 데이터 통신을 위한 규칙을 제공한다. 서로 다른 유형의 데이터 액세스 프로토콜은 데이터를 액세스하는 데 특정 이점을 제공한다. 특히, SMB 프로토콜은 선호되는 파일 공유 프로토콜이며 REST 프로토콜은 제약-기반 클라이언트 서버 인터렉션을 위해 자주 사용된다. 각각의 프로토콜은 데이터를 액세스하기 위해 메시지를 통신하기 위한 잘 정의된 형태이다. 프로토콜이 데이터 액세스 서비스로 링크하기 위한 애플리케이션 프로그래밍 인터페이스(API)로 구현될 때, 불가피하게 하나의 프로토콜의 API 라이브러리는 타 프로토콜 API를 배제하고 작동한다. 이와 관련하여, 종래의 데이터 액세스 프로토콜 및 API는 통합 SMB 및 REST 기능을 위한 포괄적인 지지를 제공하지 못하기 때문에 통합 파일 공유 및 제약-기반 클라이언트 서버 인터렉션을 촉진하는 데 효율적이지 않다. 덧붙여, 종래의 파일 시스템 액세스는 종종 설치, 설정 및 동작하기 복잡하고 비용이 비싼 직접 연결 저장소("DAS") 및 저장 영역 네트워크("SAN") 솔루션을 기초로 한다. 오늘날, 기본 레벨에서, 어떠한 클라우드-기반 플랫폼도 파일 시스템을 액세스하기 위해 공유 파일 액세스 프로토콜 및 REST 프로토콜을 기초로 하는 SFA-REST API("SFA-REST 인터페이스")를 제공하는 파일 서비스를 지원할 수 없다. 클라우드 컴퓨팅 플랫폼 상의 파일 서비스가 플랫폼을 지원하는 클라우드 컴퓨팅 인프라구조의 가용성 및 확장성을 활용하면서, 클라이언트로부터 파일 시스템으로의 병렬 액세스에 대한 포괄적인 지원을 제공할 수 있다.

따라서 본 발명의 실시예가 단순하고 효율적인 클라우드 컴퓨팅 플랫폼 파일 서비스 및 파일 서비스에 기초해서 파일에 액세스하기 위한 방법을 제공하며, 이때 파일 서비스는 SFA-REST 인터페이스를 포함한다. 특히, 본 명세서에서 정의되는 SFA-REST 인터페이스 구성요소는 넓은 의미로 SFA 프로토콜 및 REST 프로토콜의 기능의 통합 구현을 지칭한다. 이와 관련하여, SFA-REST 인터페이스가 SFA 기반 동작을 지원하여 파일 공유를 액세스할 수 있고, SFA-REST 인터페이스는 SFA 프로토콜의 구현 요소를 적어도 부분적으로 기초로 한다. 상기 SFA-REST 인터페이스는 REST 기반 동작을 더 지원하여 파일 공유를 액세스할 수 있고, SFA-REST 인터페이스는 REST 프로토콜의 구현 요소를 적어도 부분적으로 기초로 한다. SFA-REST 인터페이스는 가상 머신, 저장소, 로드 밸런싱(load balancing) 및 공유된 파일로의 액세스를 제공하는 파일 서비스를 위한 네트워킹을 제공하는 클라우드 컴퓨팅 인프라구조 내 플랫폼 상에서 더 구현될 수 있다. 상기 클라우드 컴퓨팅 인프라구조는 파일 서비스를 독립적으로 지원할 수 있지만, 실시예에서, 블롭 서비스는 파일 서비스와 병렬로 실행될 수 있다. 파일 서비스 및 블롭 서비스 모두가 클라우드 컴퓨팅 인프라구조에서 이용 가능한 특징부를 활용할 수 있다.

통합 기능을 지원하는 SFA-REST 인터페이스의 예시적 구현이 SFA-REST 인터페이스의 캐시 구성요소로 설명될 수 있다. 캐시 구성요소는 이하에서 더 상세히 설명될 것이다. 캐시 구성요소는 파일 서비스 자원(가령, 파일 또는 디렉토리)의 얼마나 많은 콘텐츠가 클라이언트 상에 캐싱될 수 있는지를 결정하는 것을 촉진시킬 수 있다. 파일의 SFA 기반 캐싱이 REST 임대(lease)와 상이한 SMB 임대라고 지칭될 수 있다. REST 임대의 특징이 또한 이하에서 더 상세히 언급된다. 예를 들어, SMB 임대를 계속 참조하면, SFA 클라이언트가 파일을 열 때, SFA 클라이언트는 캐싱(가령, 읽기, 쓰기, 핸들링)의 최대 크기를 요청할 수 있다. 상기 SFA 클라이언트는 캐싱을 요청하는 동작 수정자(operation modifier)를 갖는 SFA 기반 동작을 통신할 수 있다. 해당 파일에 열린 그 밖의 다른 핸들의 유형 및 수에 기초해서, 파일 서비스는 핸들을 닫거나 더 많은 핸들을 열기 위한 읽기, 쓰기, 또는 심지어 호출이 특정된 파일에 대해 수행될 수 있는지 여부에 대한 결정으로 클라이언트에게 응답할 수 있다. 파일이 제1 클라이언트에 의해 배타적으로 액세스될 때, 시스템은 완전 캐싱(읽기, 쓰기 및 핸들링)을 허가할 수 있다. 제2 클라이언트가 해당 파일로의 핸들을 열려 시도하는 경우, 시스템은 SMB-임대를 파기하여, 제1 클라이언트에 의해 이뤄진 변경이 제2 클라이언트에게 보일 수 있음을 보장할 수 있다. SMB 임대의 파기는 SMB 임대를 갖는 제1 클라이언트와의 통신을 포함하여, SMB 임대가 파기되기 전에 서버 변경을 플러싱(flush)할 수 있다. 또한 캐시 구성요소가, SMB-대여 대상 파일에 대해 REST 기반 동작(가령, 읽기 또는 쓰기)이 요청될 때 SMB-임대를 파기하는 것을 지원할 수 있다.

SFA-REST 인터페이스의 캐시 구성요소가 SFA 클라이언트 및 REST 클라이언트를 통한 파일 시스템으로의 병렬 액세스 때문에 이제는 가능해진 에러 경로를 지원하도록 구성될 수 있다. 예를 들어, SMB 임대가 파기될 필요가 있을 때 임대를 소유하는 클라이언트가 응답하지 않을 수 있다. SFA-REST 인터페이스는 파일에 대한 SMB 임대를 참조하여 SFA 기반 동작 및 REST 기반 동작의 통합 기능을 관리하는 것을 지원할 수 있다. 예를 들어, 파일이 열리고 기존 SMB 임대 하에서 캐싱되는 동안 읽기 또는 쓰기를 위한 REST 기반 동작이 파일에 대한 액세스를 요청할 수 있다. 파일은 캐싱을 요청하는 동작 수정자를 갖는 SFA 기반 동작을 기초로 열릴 수 있다. 이 경우, SMB 임대가 파기되는 동안 REST 기반 동작 읽기 또는 쓰기가 차단될 수 있다. SMB 임대를 파기할 때 약간의 시간이 걸릴 수 있다. 따라서, SFA-REST 인터페이스가 SMB 임대를 파기하는 것이 너무 오래 걸리는 환경에서 타임아웃 에러를 제공할 수 있다. 특정 에러 코드가 정의되고 클라이언트로 반환되어, 클라이언트가 REST 기반 동작(가령, 읽기 또는 쓰기)를 차후에 시도할 수 있다. 본 발명에서, SFA-REST 인터페이스 구성요소를 통해 지원되는 SFA 기반 동작과 REST 기반 동작의 그 밖의 다른 임의의 변형 및 조합이 고려된다.

본 발명의 실시예는 SFA-REST 인터페이스 구성요소에 기초해서 개발된 스키마를 더 포함한다. 상기 스키마는 파일 공유에의 평행 SFA 기반 및 REST 기반 액세스를 제공하는 파일 서비스를 지원한다. 예를 들어, SFA 클라이언트 및 REST 클라이언트가 모두 동시에 파일 공유를 액세스할 수 있다. 스키마는 복수의 테이블을 포함하며, 이때 테이블은 SFA 프로토콜 및 REST 프로토콜의 요소를 갖는 SFA-REST 인터페이스에 기초해서 하는 필드를 포함한다. 상기 스키마는 파일 시스템의 스냅샷(snapshotting)을 더 가능하게 한다. 스냅샷은 파일 시스템을 백업한다. 스냅샷은 각각의 스냅샷에서의 구 버전이 차후에 액세스될 수 있도록 하는 쓰기 시 복사(copy-on-write) 유형 패턴을 기초로 할 수 있다.

따라서 본 발명의 제1 측면에서, 분산된 파일 시스템에서 파일에 액세스하기 위한 방법이 제공된다. 방법은 분산된 파일 시스템에서 파일에 대한 동작 수정자를 갖는 SFA 기반 동작을 수신하는 단계를 포함한다. SFA 기반 동작이 파일-표현 상태 전송(REST) 인터페이스에 기초해서 정의된다. SFA-REST 인터페이스는 SFA 프로토콜과 REST 프로토콜의 통합 기능을 포함한다. 방법은 분산된 파일 시스템에서 파일에 대한 REST 기반 동작을 수신하는 단계를 더 포함하고, 상기 REST 기반 동작은 SFA-REST 인터페이스에 기초해서 정의된다. 방법은 또한 동작 수정자를 이용해 SFA 기반 동작을 실행하는 단계를 더 포함한다. 방법은 동작 수정자를 참조하여 REST 기반 동작을 실행하는 단계를 포함한다. 방법은 SFA-REST 인터페이스에 기초해서 REST 기반 동작을 실행하는 단계를 더 포함한다.

본 발명의 제2 측면에서, 데이터 파일 시스템을 액세스하기 위한 파일 서비스 스키마를 갖는 시스템이 제공된다. 파일 서비스 스키마는 복수의 테이블을 포함한다. 복수의 테이블은 파일 시스템 내 파일의 상태를 저장한다. 복수의 테이블은 SFA-REST 인터페이스의 요소에 대응하는 필드를 포함한다. 상기 SFA-REST 인터페이스는 파일 시스템 내 파일에 액세스하기 위한 SFA 프로토콜 및 REST 프로토콜의 통합 기능을 포함한다.

본 발명의 제3 측면에서, 파일 공유를 스냅샷하기 위한 컴퓨터 구현식 방법이 제공된다. 방법은 파일 공유(file share)를 포함하는 공유 테이블을 업데이트하는 단계를 포함한다. 공유 테이블을 업데이트하는 단계는 공유 테이블에 하나의 행(row)을 추가하는 단계를 포함하며, 상기 행은 파일 공유의 새 버전과 연관된다. 이 방법은, 파일 공유와 연관된 노드로, 상기 노드에게 새 버전의 파일 공유로 쓰기를 시작할 것을 지시하는 통지를 통신하는 단계를 더 포함한다. 방법은 노드가 새 버전의 파일 공유에 쓰는 중임을 결정하는 단계를 더 포함한다. 방법은 공유 테이블을 업데이트하여 스냅샷이 성공적으로 완료됐음을 가리킬 수 있다.

본 발명의 실시예의 개요를 간단히 기재했고, 이하에서, 본 발명의 다양한 측면에 대한 일반적인 맥락을 제공하기 위해 본 발명의 실시예가 구현될 수 있는 예시적 동작 환경이 기재된다. 우선 도 1을 구체적으로 참조하면, 본 발명의 실시예를 구현하기 위한 예시적 동작 환경이 도시되며, 전체적으로 컴퓨팅 장치(100)로 표시되어 있다. 그러나 컴퓨팅 장치(100)는 적합한 컴퓨팅 환경의 하나의 예시이며 본 발명의 사용 또는 기능의 범위에 어떠한 제한도 암시하지 않는다. 또한 컴퓨팅 장치(100)는 도시된 구성요소들 중 임의의 하나 또는 조합과 관련된 어떠한 종속성 또는 요건도 갖지 않는 것으로 해석되어야 한다.

본 발명은 컴퓨터 또는 그 밖의 다른 기계, 예컨대, PDA(personal data assistant) 또는 그 밖의 다른 헨드-헬드 장치에 의해 실행되는, 컴퓨터 코드 또는 기계-이용 명령, 가령, 프로그램 모듈 같은 컴퓨터-실행 명령의 일반적인 맥락에서 기재될 수 있다. 일반적으로, 프로그램 모듈, 가령, 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등이 특정 작업을 수행하거나 특정 추상 데이터 유형을 구현하는 코드를 지칭한다. 본 발명은 다양한 시스템 구성, 가령, 핸드-헬드 장치, 소비자 전자장치, 범용 컴퓨터, 더 특수한 컴퓨팅 장치 등에서 실시될 수 있다. 본 발명은 또한 분산 컴퓨팅 환경에서 실시될 수 있으며, 여기서 작업이 통신 네트워크를 통해 링크되는 원격-처리 장치에 의해 수행된다.

도 1을 참조하면, 컴퓨팅 장치(100)는 다음의 장치를 직접 또는 간접적으로 연결하는 버스(110)를 포함한다: 메모리(112), 하나 이상의 프로세서(114), 하나 이상의 표시 구성요소(116), 입/출력 포트(118), 입/출력 구성요소(120) 및 예시적 전력 공급기(122). 버스(110)는 하나 이상의 버스일 수 있는 것(가령, 주소 버스, 데이터 버스, 또는 이들의 조합)을 대표한다. 도 1의 다양한 블록이 간결성을 목적으로 선으로 도시되더라도, 실제로는, 다양한 구성요소의 구별이 그렇게 명확하지 않고, 은유적으로 선은 회색이고 흐릿하다고 보는 것이 더 정확할 것이다. 예를 들어, I/O 구성요소일 수 있는 표시 구성요소, 가령, 디스플레이 장치를 고려할 수 있다. 또한 프로세서는 메모리를 가진다. 이는 해당 기술 분야의 속성이며, 도 1의 도면은 본 발명의 하나 이상의 실시예와 관련하여 사용될 수 있는 예시적 컴퓨팅 장치의 예시에 불과함이 반복 강조된다. 모두 도 1의 범위 내에서 고려되고 "컴퓨팅 장치"를 지칭할 때 "워크스테이션", "서버", "랩톱", "핸드-헬드 장치" 등의 카테고리들 간 구별이 이뤄지지 않는다.

일반적으로 컴퓨팅 장치(100)는 다양한 컴퓨터-판독 매체를 포함한다. 컴퓨터-판독형 매체는 컴퓨팅 장치(100)에 의해 액세스될 수 있고 휘발성 및 비휘발성 매체, 이동식 및 비이동식 매체를 포함하는 임의의 이용 가능한 매체일 수 있다. 비제한적 예를 들면, 컴퓨터 판독형 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다.

컴퓨터 저장 매체는 정보, 가령, 컴퓨터 판독형 명령, 데이터 구조, 프로그램 모듈 또는 그 밖의 다른 데이터를 저장하기 위한 임의의 방법 또는 기법으로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함한다. 컴퓨터 저장 매체의 비제한적 예를 들면, RAM, ROM, EEPROM, 플래시 메모리 또는 그 밖의 다른 메모리 기법, CD-ROM, 디지털 다목적 디스크(DVD) 또는 그 밖의 다른 광학 디스크 저장장치, 또는 희망 정보를 저장하는 데 사용될 수 있고 컴퓨팅 장치(100)에 의해 액세스될 수 있는 그 밖의 다른 임의의 매체가 있을 수 있다. 컴퓨터 저장 매체는 신호 자체를 배제한다.

일반적으로 통신 매체는 컴퓨터 판독형 명령, 데이터 구조, 프로그램 모듈 또는 그 밖의 다른 데이터를 변조된 데이터 신호, 가령, 반송파 또는 그 밖의 다른 전송 매체로 구현하며 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 하나 이상의 특성이 신호 내 정보를 인코딩하기 위해 설정 또는 변경되는 신호를 의미한다. 통신 매체의 비제한적 예로는 유선 매체, 가령, 유선 네트워크 또는 직접 배선 연결, 무선 매체, 가령, 음향, RF, 적외선 및 그 밖의 다른 무선 매체가 있다. 상기 언급된 것들 중 임의의 것의 조합이 컴퓨터 판독형 매체의 범위 내에 포함되어야 한다.

메모리(112)는 휘발성 및/또는 비휘발성 메모리의 형태로 된 컴퓨터 저장 매체를 포함한다. 메모리는 이동식, 비이동식, 또는 이들의 조합일 수 있다. 예시적 하드웨어 장치는 솔리드-스테이트 메모리, 하드 드라이브, 광학-디스크 드라이브 등을 포함한다. 컴퓨팅 장치(100)는 다양한 개체, 가령, 메모리(112) 또는 I/O 구성요소(120)로부터 데이터를 읽는 하나 이상의 프로세서를 포함한다. 표시 구성요소(116)는 데이터 표시를 사용자 또는 그 밖의 다른 장치에게 제시한다. 예시적 표시 구성요소는 디스플레이 장치, 스피커, 인쇄 구성요소, 진동 구성요소 등을 포함한다.

I/O 포트(118)는 컴퓨팅 장치(100)가 이들의 일부가 구축될 수 있는 그 밖의 다른 장치, 가령, I/O 구성요소(120)로 논리적으로 연결될 수 있다. 예시적 구성요소는 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 스캐너, 프린터, 무선 장치 등을 포함한다.

도 2a를 참조하며, 본 발명의 실시예에서 사용되기 적합한 예시적 클라우드 컴퓨팅 분산 인프라구조(200)를 도시하는 블록도가 기재된다. 일반적으로, 클라우드 컴퓨팅 분산 인프라구조(200)는 클라우드 컴퓨팅 플랫폼을 통해 서비스를 제공하기 위한 환경을 도시한다. 클라우드 컴퓨팅 인프라구조(200)는 확장 가능한, 고도로 이용 가능한, 그리고 내구성이 있는 서비스를 제공한다. 예를 들어, 저장 서비스는 서로 다른 유형의 저장 유형으로 데이터를 저장할 수 있는 능력을 제공한다. 각각의 저장 유형이 이점을 가지며 복수의 저장 유형이 동일한 애플리케이션 내에서 사용될 수 있다. 클라우드 컴퓨팅 인프라구조가 서비스 API를 제공하여 블롭(blob), 큐(queue), 테이블 및 파일 시스템 저장 유형을 지원할 수 있다. 특히, 본 발명의 실시예는 플랫폼 상의 파일 시스템으로의 병렬 액세스를 위한 SFA 기반 동작 및 REST 기반 동작을 지원하는 파일 서비스를 제공한다. 파일 서비스는 SFA 프로토콜 및 REST 프로토콜의 통합 기능을 포함하는 SFA-REST 인터페이스를 이용한다. SFA-REST 인터페이스는 SFA 프로토콜을 기초로 하는 파일 시스템을 노출하여, SFA-REST 인터페이스에 의해 파일 시스템 내 파일로 핸들(handle)을 반환하는 파일 열기 또는 생성이 가능해진다. 핸들이 반환될 때 클라이언트는 상기 핸들을 이용해 파일을 읽고 쓸 수 있다. SFA-REST 인터페이스는 파일에 대한 PUT 및 GET 액션을 포함하는 직접 REST 기반 동작을 가능하게 하는 REST 프로토콜의 요소를 더 포함한다. 프로토콜 구성요소가 통합되어 파일 시스템에 병렬로 액세스를 집합적으로 제공할 수 있다. 특히, SFA-REST 인터페이스는 SFA 프로토콜의 SFA 기반 동작과 REST 프로토콜의 REST 기반 동작 간 인터렉션을 위한 규칙을 정의한다. SFA-REST 인터페이스는 각각의 개별 동작과 대응하는 파라미터 및 반환된 값을 기초로 서로 다른 동작을 수행하는 것을 촉진시키는 SFA 기반 API 및 REST 기반 API를 포함한다. SFA 기반 API를 예시로서 참조할 때, 생성 API는 파라미터 및 상태로서 파일명을, 그리고 반환된 값으로서 파일 핸들, 파일 시간 스탬프, 파일 크기를 포함한다. 생성 API에 의해 클라이언트는 파일명을 갖는 파일을 열거나 생성할 수 있다. 추가 파라미터가 파일의 서로 다른 측면을 제어하고 반환된 값을 핸들링할 수 있다. SFA 기반 API는 서비스로부터 클라이언트로 설정될 수 있는 oplock 명령어를 더 지원한다. 파일이 열리거나 생성될 때 oplock은 생성 SFA 기반 동작에 의해 생성될 수 있다. 이하에서, oplock, SMB 임대, 및 REST 기반 API와의 인터렉션을 지원하는 SFA 기반 API에 대한 추가 세부사항이 더 상세히 기재된다.

여기서 SMB 임대 및 oplock이 상호 교환 가능하게 사용될 수 있지만, 이들의 구현이 상이하다는 점이 중요하다. 특히, 클라이언트-서버 인터렉션 동안 SMB 임대 및 oplock이 서로 다르게 관리된다. oplock은 oplock을 파기할 수 있는 동일한 클라이언트 상에서 2개의 프로세스를 운영하는 단일 클라이언트에 의해 우연히 파기될 수 있지만, SMB 임대는 이러한 우발적 SMB 임대 파기로부터 보호된다. 본 발명의 실시예를 참조할 때 구별이 필요할 수 있다.

REST 기반 API를 참조할 때, REST 기반 API는 무상태 동작을 지원한다. 배경기술로서, 무상태는 요청들 사이에 서버 상에 어떠한 클라이언트 상황정보(context)도 저장되지 않음으로써 클라이언트-서버 통신이 제약된다는 표기를 지칭할 수 있다. 임의의 클라이언트 제약으로부터의 각각의 요청이 요청을 서비스하는 데 필요한 모든 정보를 포함하고, 세션 상태가 클라이언트 내에 보유되거나 요청들 사이에 클라이언트에 상태가 전혀 유지되지 않을 수 있다. 이와 관련하여, 요청들 간에 어떠한 종속관계도 존재하지 않는다. 또한, REST 기반 동작에 대한 인증이 요청의 정규화된 버전을 서명하여 소비자의 저장소 계정 키(key)로 REST 기반 동작을 인증하고 최종 서명을 요청과 함께 전달하는 것에 기초해서 각각의 요청에 대해 동일한 방식으로 핸들링될 수 있다. 예시적 REST 기반 API는 클라이언트가 파일을 생성할 수 있게 하는 파일 생성 API일 수 있다. 상기 파일 생성 API는 명칭 파라미터 및 상태 반환 값을 가질 수 있다. 추가 예시적 API가 본 명세서에서 별지로서 포함된다.

도 2a를 계속 참조하면, 일반적으로 클라우드 컴퓨팅 분산 인프라구조(200)가 SFA 클라이언트(202), REST 클라이언트(204), 클라우드 컴퓨팅 플랫폼(206), 서비스 API(208), 블롭(212), 큐(214), 테이블(216) 및 파일 시스템(218)을 갖는 저장장치(210), 및 네트워크(220) 및 도시되지 않은 그 밖의 다른 구성요소를 포함한다. 네트워크(220)의 비제한적 예를 들면, 하나 이상의 로컬 영역 네트워크(LAN) 및/또는 광역 네트워크(WAN)가 있을 수 있다. 이러한 네트워킹 환경은 사무실, 기업별 컴퓨터 네트워크, 인트라넷 및 인터넷에서 일반적이다. 따라서 네트워크(226)는 본 명세서에서 더 기재되지 않는다.

SFA 클라이언트(202) 및 REST 클라이언트(204)는 클라우드 컴퓨팅 플랫폼(206)에 의해 제공되는 서비스를 액세스하는 소프트웨어 또는 하드웨어를 갖는 컴퓨팅 장치이다. 클라이언트는 임의의 유형의 컴퓨팅 장치, 가령, 도 1을 참조하여 기재되는 컴퓨팅 장치(100)를 포함할 수 있다. 클라이언트는 네트워크(220)를 통해 클라우드 컴퓨팅 플랫폼(206)을 액세스할 수 있다. SFA 클라이언트(202) 및 REST 클라이언트(204)는 구체적으로 각각 SFA 프로토콜 및 REST 프로토콜을 이용해, 클라우드 컴퓨팅 플랫폼(206) 상의 서비스를 액세스할 수 있는 컴퓨터 프로그램을 지칭할 수 있다. 상기 클라이언트는 서비스 API(208)를 이용해 서로 다른 저장 유형을 액세스할 수 있다. 저장 유형은 큰 이진 객체(binary object)를 연관된 메타데이터, 예컨대, 문서, 사진, 비디오 및 음악 파일과 함께 저장하도록 설계된 블롭(212)을 포함한다. 큐(214)는 신뢰할만한 비동기식 메시지 전달 저장 유형이다. 테이블(216) 저장 유형은 테라바이트의 데이터를 차지하는 가벼운 데이터 객체를 저장할 수 있는 구조화된 저장 능력을 제공한다. 파일 공유(218)는 SFA 클라이언트(202) 및 REST 클라이언트(204)로부터 병렬로 공유 및 액세스될 수 있는 파일을 저장할 수 있는 능력을 제공한다.

도 2b를 다시 참조하면, SFA 클라이언트(204) 및 REST 클라이언트(204)가 특히 파일 서비스를 액세스할 수 있다. SFA-REST 인터페이스(230)는 파일 서비스 자원(240)을 지원하기 위한 SFA 프로토콜과 REST 프로토콜의 통합 기능을 포함한다. 파일 서비스 자원(240)은 저장소 계정(storage account)(242), 공유(244), 디렉토리(246), 및 파일(248)을 포함한다. 특히, 공유(244)는 파일의 세트를 조직하는 방식을 제공하고 또한 클라우드 컴퓨팅 플랫폼에 호스팅되는 SMB 파일 공유로서 장착될 수 있다. 파일 서비스는 SFA 클라이언트(202) 및 REST 클라이언트(204)가 동시에 파일 서비스 자원(240)을 액세스할 수 있는 파일 서비스 API("SFA-REST 인터페이스")(230)에 기초해서 파일 서비스 자원(240)에 대한 액세스를 제공할 수 있다. SFA-REST 인터페이스는 HTTP 동작을 통해 액세스 파일 자원을 지원하는 API를 포함할 수 있다. 동작이 자원 유형 및 REST 버브(verb)와 연관될 수 있다. 예를 들어, 공유 생성 동작이 공유의 자원 유형과, 동작 실행 시 저장소 계정에 새로운 공유를 생성하는 REST 버브 PUT을 가질 수 있다. 본 발명의 실시예에 따라 추가 동작이 고려된다.

실시예에서, 동작은 사용될 SFA-REST API의 버전을 특정할 수 있다. 예를 들어, x-ms-version이 동작의 버전을 특정하는 데 사용되는 HTTP 헤더일 수 있다. 따라서 사용자는 x-ms-version 요청 헤더를 설정함으로써 자신이 사용하기 원하는 동작의 버전을 특정할 수 있다. HTTP 헤더에서 버전이 식별되고, API의 새로운 버전이 이용 가능한 경우, 사용자의 기존 코드의 기능을 파기하지 않을 것이다. 사용자는 x-ms-version HTTP 헤더를 특정함으로써, API의 더 새로운 버전을 호출하도록 코드를 수정할 수 있다.

도 2c를 참조하면, SFA-REST 인터페이스(230)가 SFA 프로토콜과 REST 프로토콜의 서로 다른 통합 기능을 지원하는 복수의 서로 다른 인터페이스 구성요소(가령, API)를 포함할 수 있다. SFA-REST 인터페이스는, 데이터 액세스 구성요소(250), 임대 구성요소(252), 캐시 구성요소(254), 타임스탬프 구성요소(256), 메타데이터 구성요소(258), 속성 구성요소(260), 바이트 범위 잠금(byte range lock) 구성요소(262), 명칭부여 및 참조(naming and referencing) 구성요소(264) 및 잠금(locking) 구성요소(266) 등을 포함한다.

도 2d를 참조하면, 본 발명의 실시예는 파일 서비스 스키마 자원(270)을 더 포함한다. 파일 서비스 스키마 자원(270)은 파일 시스템으로의 액세스를 촉진시킨다. 파일 서비스 스키마 자원(270)은 액세스 테이블(272), 공유 테이블(274) 및 스냅샷 구성요소(276)를 갖는 스키마를 포함한다. 액세스 테이블(272) 및 공유 테이블(274)을 갖는 스키마는 파일 공유, 디렉토리 및 파일을 갖는 파일 시스템으로의 액세스를 제공한다.

본 명세서에 기재된 이러한 배열 및 그 밖의 다른 배열이 단지 예시로서 제공됨이 이해되어야 한다. 그 박의 다른 배열 및 기능(가령, 머신, 인터페이스, 기능, 기능의 순서 및 그룹)이 이들 나타난 것에 추가로 또는 이를 대신하여 사용될 수 있고, 일부 기능은 다 함께 생략될 수 있다. 또한 본 명세서에 기재된 기능들 중 다수가 이산 또는 분산 구성요소로서 또는 그 박의 다른 구성요소와 함께, 임의의 적합한 조합 및 위치로 구현될 수 있는 기능적 개체이다. 본 명세서에 하나 이상의 개체에 의해 수행되는 것으로 기재된 다양한 기능이 하드웨어, 펌웨어, 및/또는 소프트웨어에 의해 수행될 수 있다. 예를 들어, 다양한 기능이 메모리에 저장된 명령을 실행하는 프로세서에 의해 수행될 수 있다.

데이터 액세스 구성요소가 파일 시스템으로의 액세스를 촉진시킬 수 있다. 상기 데이터 액세스 구성요소는 파일 시스템으로의 액세스를 지원하는 SFA 기반 API 및 REST 기반 API를 포함한다. 특히, SFA 기반 API는 핸들을 구현하며, 여기서 데이터 액세스(가령, 파일 열기 또는 생성하기)가 파일로의 핸들을 반환하고 상기 핸들을 이용한 파일 읽기 및 쓰기를 가능하게 한다. REST 기반 API는 SFA 프로토콜에서 발견되는 동등한 핸들 기능을 지원하지 않는다. REST 기반 API는 핸들 기능 없이 파일 읽기 및 쓰기를 지원하지만 SFA 프로토콜을 기초로 하는 대응하는 요소를 포함한다.

임대 구성요소가 공유 액세스를 위한 파일 임대 실행을 촉진시킬 수 있다. SFA-REST 인터페이스는 REST 임대를 촉진하는 REST 기반 API를 포함한다. REST 임대에 의해 일정 지속시간 동안 파일로의 배타적 쓰기 공유된 읽기 액세스가 가능해진다. 지속시간은 지정된 시간 주기일 수 있으며, 예컨대, 1분, 또는 무한 시간일 수 있다. 또한 SFA-REST 인터페이스는 파일 핸들을 기초로 공유된 액세스를 지원하는 SFA 기반 API를 포함한다. 예를 들어, 사용자가 SFA 기반 동작에 의해 파일을 생성하거나 열 때, SFA 기반 동작은 동작 수정자를 포함할 수 있다. 동작 수정자는 SFA 기반 동작을 수정하는 제약(constraint)(가령, 액세스, 공유)을 정의한다. 제약은 액세스 제약, 가령, 읽기, 쓰기, 및 삭제일 수 있으며, 제약은 공유 제약, 가령, 읽기 공유, 쓰기 공유, 및 삭제 공유일 수 있다. 파일 서비스는 파일로의 액세스를 제공하기 위해 SFA 기반 동작이 수행되어야 하는지 여부를, 상기 파일에 대해 현재 열려 있는 나머지 모든 핸들로부터의 동작 수정자가 SFA 기반 동작 상의 현재 동작 수정자와 호환되는지 여부에 기초해서, 결정할 수 있다.

임대 구성요소는 파일에 대한 파일 핸들을 열어서 파일을 읽기, 쓰기 및 삭제되도록 액세스하고 타 핸들로부터의 공유된 읽기를 허용하는 것과 유사하게 기능하도록 REST 임대에 대해 REST 기반 API를 구현한다. 임대 구성요소는 검증을 수행하여 REST 기반 동작이 REST 임대를 획득 또는 갱신할 때 어떠한 기존 임대도 없음을 확인할 수 있고, REST 기반 동작과 호환되지 않는 열린 파일의 그 밖의 다른 핸들 또는 임대가 존재하기 때문에 임대가 허용되지 않음을 가리키는 에러를 반환할 수 있다. 따라서 파일을 열기 위한 REST 기반 동작 또는 SFA 기반 동작이, 이전 REST 기반 동작과 연관된 임대 또는 이전 SFA 기반 동작과 연관된 동작 수정자의 참조에 기초해서, 실패할 수 있다.

캐시 구성요소는 기회적 잠금(opportunistic lock)에 의해 REST 기반 동작 및 SFA 기반 동작이 인터렉션하는 방식을 관리한다. SMB Oplock(기회적 잠금)이 SFA 클라이언트가 성능을 개선하고 네트워크 전송량을 감소하기 위해 요청하는 캐싱 메커니즘이다. 이는 특정 파일 또는 디렉토리의 최신 상태가 SFA 클라이언트 상에 캐싱될 수 있음을 의미한다. SMB 임대 유형이라고 일컬어지는 복수의 Oplock 유형이 존재한다: 읽기(R): 획득될 때, 클라이언트는 로컬 캐시로부터 읽을 수 있다. 쓰기(W): 획득될 때, 클라이언트는 데이터를 SMB 서비스로 다시 플러싱(flush)할 필요 없이 로컬하게 쓸 수 있다. 핸들(H): 획득될 때, 클라이언트는 SMB 서비스에게 핸들 닫힘이 발생하는 때를 통지할 필요가 없다. oplock는 애플리케이션이 동일한 액세스 및 공유 모드에 의해 파일 열기 및 닫기를 유지하는 경우 유용하다. SFA 클라이언트는 SMB 서비스에게 매 닫기에 대해 즉시 알릴 필요가 없다. 상기의 SMB 임대 유형은 오픈 핸들 동안 특정된 액세스 및 공유 모드에 독립적이다. 일반적으로 SFA 클라이언트는 액세스 및 공유 모드에 무관하게 파일에 대해 새 핸들을 열 때마다 임대 유형을 획득하려 시도한다.

REST 기반 동작에 따라, REST 요청이 기존 SFA 클라이언트 oplock을 파기할 것이 필요할 수 있다. 이는 쓰기 Oplock의 경우 SFA 클라이언트가 파일 서비스로 캐싱된 변경을 플러싱할 것을 요구할 것이다. 각각의 유형의 oplock이 파기될 필요가 있는 이유 중 일부가 아래에서 제공된다: PutRange 같은 쓰기 REST 동작이 발행될 때마다 읽기(R) oplock이 파기될 필요가 있다. GetBlob 같은 읽기 REST 동작이 발행될 때마다 쓰기(W) oplock이 파기될 필요가 있다. 파일 서비스가 삭제 요청이 성공하기 위해 어떠한 열린 핸들도 필요하지 않기 때문에 클라이언트가 삭제 REST 동작을 발행할 때마다 핸들(H) oplock이 파기될 필요가 있다.

oplock을 파기하는 것은 SMB 캐싱된 클라이언트 변경을 아마도 플러싱하는 것을 포함하며, 이로 인해 REST 서비스 동작 응답 시간에 추가 딜레이가 초래되거나 상태 코드 408(Request Timeout(요청 타임아웃)) 및 에러 코드 식별자(가령, ClientCacheFlushDelay)로 REST 동작이 실패할 수 있다. 예시적 시나리오가 oplock 파기 및 플러싱이 요구되고 REST 클라이언트가 딜레이를 경험하는 경우를 포함한다. 이 시나리오에서, SFA 클라이언트가 파일을 열고, RWH oplock을 획득하고 데이터를 로컬하게 쓴다. REST 클라이언트는 GetFile 요청을 전송한다. 파일 서비스는 쓰기(W) oplock을 파기하고 클라이언트에게 RH oplock을 남겨둔다. SFA 클라이언트는 파일 서비스에 대해 자신의 캐싱된 데이터를 플러싱하며 oplock 파기를 긍정응답(ack)한다. 파일 서비스는 GetFile 요청을 처리하고 요청된 데이터로 다시 응답한다. 상기의 예시에서, REST 클라이언트는 oplock 파기 및 SFA 클라이언트가 파일 서비스에 대해 자신의 데이터를 플러싱하는 데 걸리는 시간에 의해 야기되는 딜레이를 경험할 것이다. 쓰기(W) oplock이 이미 파기되었기 때문에 임의의 다음 GetFile 요청이 임의의 추가 딜레이를 경험하지 않을 것이다.

또 다른 예시적 시나리오가 Opblock 파기가 요구되지만 REST 클라이언트가 딜레이를 경험하지 않는 경우를 포함한다. 이 시나리오에서, (앞서 언급된 예시로부터 계속하여) SFA 클라이언트가 이미 RH oplock을 가진다. REST 클라이언트는 PutRange 요청을 발행한다. 파일 서비스는 SFA 클라이언트로 oplock 파기 요청을 전송하지만 응답을 기다리지 않는다. 파일 서비스는 PutRange 요청을 처리한다. 상기의 예시에서, oplock 파기가 요구되더라도, 읽기 oplock을 파기할 때 응답이 요구되지 않기 때문에 REST 동작은 임의의 추가 딜레이를 경험하지 않는다.

파일 서비스는 동일한 파일 상에 열린 핸들을 이미 갖는 SFA 클라이언트의 Oplock 상태에 기초해서 각각의 REST 기반 동작에 대응하는 서로 다른 거동을 가질 수 있다. oplock 파기의 차단(blocking)은 파일 서비스가 파기가 성공적이었다는 긍정응답을 기다릴 필요가 있다는 사실을 지칭하며, 반면에, 비-차단의 경우, 파일 서비스는 그럴 필요가 없음을 의미한다. Oplock 파기 차단이 요구되고, 파기가 특정된 요청 타임아웃 내에 최대 30초 내에 성공하지 않는 경우, REST 동작은 상태 코드 408(Request Timeout(요청 타임아웃)) 및 에러 코드 식별자(가령, ClientCacheFlushDelay)로 실패할 수 있다.

또한, 예를 들면, DeleteFile 요청이 도한 oplock 핸들(H) 임대 파기를 요구할 것이며; 이는 REST 클라이언트로부터 DeleteFile이 발행될 때 SMB 측으로부터 개받되는 어떠한 파일 핸들도 존재하지 않음을 보장하도록 수행된다. 공유 위반(sharing violation)이 존재하는 경우, 요청은 상태 코드 409(Conflict(충돌)) 및 에러 코드 식별자(가령, Sharing Violation(공유 위반))으로 실패할 것이다.

타임스탬프 구성요소가 이벤트가 발생할 때를 식별하도록 기능할 수 있다. 구체적으로, 타임스탬프 구성요소는, SFA 프로토콜과 REST 프로토콜의 통합된 기능이 SFA-REST 인터페이스를 통해 이용 가능할 수 있도록 하는 멀티-타임스탬프 구현일 수 있다. REST 기반 API가 낙관적 동시수행 모델(optimistic concurrency model)에 대한 지원을 제공한다. 낙관적 동시수행 모델은 정확한 타임스탬프에 기초해서 한다. 낙관적 동시수행 모델에서, 파일 서비스가 파일에 액세스하기 위한 REST 기반 동작을 수신할 때, 파일 서비스는 파일로의 매 쓰기마다 증분됨이 보장되는 정밀한 타임스탬프인 개체 태그("ETAG")를 생성하고 반환한다. ETAG는, 호출 사이에 파일이 변경되는 경우 REST 기반 동작이 실패이거나 ETAG가 변경되지 않는 경우 실패일 조건부 헤더로서 다음 REST 기반 동작, 가령, 읽기 또는 쓰기로 다시 전달될 수 있다. SFA 기반 API는 낙관적 동시수행 모델을 구현하지 않는다. 대신 파일 핸들이 닫힐 때 타임스탬프의 업데이트가 수행된다. 덧붙여, 전통적인 파일 시스템에 의해서는 보통, SFA 클라이언트가 파일 상의 타임스탬프를 임의의 시간으로 명시적으로 설정할 수 있다.

타임스탬프 구성요소는 각각의 파일에 대해 5개의 서로 다른 타임스탬프를 지원한다. 이중 4개의 타임스탬프는 SFA 기반 API에 기초해서 할 수 있다. 타임스탬프는 생성 시점, 마지막 수정 시점, 마지막 쓰기 시점, 및 마지막 액세스 시점을 포함한다. 4개의 타임스탬프는 SMB-프로토콜과 동일한 시맨틱을 이용해 구현될 수 있다. 다섯 번째 타임스탬프는 낙관적 동시수행을 위해 사용될 수 있는 ETAG이다. 상기 다섯 번째 타임스탬프는 SFA 기반 API를 통해 노출되지 않는다. 모든 5개의 스탬프가 REST 기반 API를 통해 이용 가능하다. 이와 관련하여, 타임스탬프가 5개의 서로 다른 타임스탬프에 기초해서 SFA 기반 동작과 REST 기반 동작 간 통합 기능을 지원할 수 있다. 특히, REST 기반 동작은 낙관적 동시수행 모델에 따라 달라지기 때문에, SFA 기반 동작이 파일 상에서 실행될 때 ETAG 타임스탬프가 업데이트될 필요가 있다. 따라서 SFA 기반 동작이 실행될 때 SFA-REST 인터페이스가 다른 타임스탬프와 함께 ETAG를 업데이트하는 것을 지원한다. 조건부 REST 기반 동작에 의한 예시적 시나리오에서, SFA 기반 동작을 이용해 파일이 업데이트된 경우, 다음의 조건부 REST 기반 동작이 업데이트된 ETAG가 존재함을 결정하여, 조건부 REST 기반 동작이 수행될 수 있는지 여부를 검증할 필요가 있다.

메타데이터 구성요소가 데이터 콘텐츠에 대한 설명적 정보를 지원하도록 구성될 수 있다. REST 기반 API에 의해 임의의 명칭 및 값 쌍의 작은 세트가 파일과 연관될 수 있다. SFA 기반 API는 파일과 연관될 수 있는 속성을 확장했다. 명칭 제한은, 일반적인 REST 프로토콜보다 더 제한되는 SMB-프로토콜(길이 및 유효 문자)을 기초로 한다. SFA 프로토콜과 REST 프로토콜을 호환 가능하게 만들기 위해, 메타데이터에 의해 이용 가능한 제한된 명칭을 갖도록 REST 기반 API가 구현되었다.

명칭부여 및 참조 구성요소가 파일 서비스 자원을 액세스하는 것을 지원할 수 있다. 파일 서비스 자원은 명칭 또는 참조 구문을 기초로 액세스될 수 있다. 저장소 계정은 공유를 포함하지 않거나 1개 이상 포함할 수 있다. 공유는 속성, 메타데이터를 포함하고 파일 또는 디렉토리를 포함하지 않거나 1개 이상 포함할 수 있다. 디렉토리는 속성을 포함할 수 있고 파일 또는 디렉토리를 포함하지 않거나 1개 이상 포함할 수 있다. 파일은 이진 데이터, 속성 및 메타데이터로 구성된 임의의 단일 개체일 수 있다.

공유 명칭을 참조할 때, 파일 서비스 공유 명칭 규칙은 SFA 프로토콜에서보다 SFA-REST 인터페이스의 API에서 더 제한적으로 구현될 수 있다. 따라서 블롭 서비스에 대한 API와 SFA-REST 인터페이스의 API가 블롭 컨테이너 및 파일 공유에 대해 유사한 명칭부여 규칙을 공유할 수 있다.

디렉토리 명칭 및 파일명을 참조할 때, SFA-REST 인터페이스가 대소문자 비구분 방식(case insensitive) 및 대소문자 보존 방식(case preserving)인 API를 더 지원한다. REST 기반 API 내 각각의 개별 구성요소(사선(slash)들 사이의 부분)에 대해 파일 및 디렉토리 명칭의 허용된 길이가 제한적이고 REST 기반 API에 대한 경로 명칭의 총 길이가 REST 프로토콜에서 표시되는 것보다 더 길고 더 깊은 명칭을 허용한다. 명칭부여 및 참조 구성요소는 REST 프로토콜에서 일반적으로 적법한 문자가 이제는 부적합하기 때문에 더는 지원하지 않는 REST 기반 API를 포함하고, 일반적으로 REST에서는 부적법한 SFA 프로토콜 문자가 이제 REST 기반 API에서는 적법하다. 하나의 실시예에서, REST 프로토콜에서 지원되지 않으나, 명칭부여 및 참조 구성요소의 REST 기반 API에서는 이제 지원되는 문자가 REST 기반 API에서 탈출(escape)될 수 있다. 문자 탈출은 선택된 문자를 HEX 코드로 인코딩하는 것을 포함한다. 부적법한 REST 프로토콜 문자를 인코딩하여, 이들을 REST 기반 API에서 적법하게 만드는 것의 그 밖의 다른 변형 및 조합이 본 발명의 실시예에 따라 고려된다.

경로명(pathname)이 "/" 사선 문자로 분리되는 하나 이상의 경로명 성분(디렉토리 또는 파일명)을 포함한다. 마지막 경로명 성분 외의 모든 경로명 성분이 디렉토리를 나타낼 수 있다. 마지막 경로명 성분은 파일의 디렉토리를 나타낸다. 경로명은 지정 개수의(가령, 1,024개의) 문자 길이만 가질 수 있다. 경로명은 "/" 사선 문자로 분리되는 하나 이상의 경로명 성분으로 구성될 수 있다. 하위 디렉토리 깊이가 지정 깊이(가령, 250)를 초과하지 않도록 구성될 수 있다. 파일은 디렉토리와 동일한 경로를 공유할 수 없고, 그 반대의 경우도 마찬가지인데, 즉, 동일한 명칭이 동일한 부모 디렉토리를 공유하는 파일 또는 디렉토리에 대해 사용될 수 없다. 예를 들면: 명칭 "data"를 갖는 파일 및 디렉토리가 동일한 부모 경로 하에서 존재할 수 없다.

공유 또는 파일 자원에 대한 메타데이터가 자원과 연관되는 명칭-값 쌍(name-value pair)으로 저장될 수 있다. 디렉토리가 메타데이터 없이 구현될 수 있다. 메타데이터 명칭이 C# 식별자에 대한 명칭부여 규칙을 기초로 할 수 있다. 메타데이터 명칭은 생성됐을 때의 대소문자를 보존할 수 있지만, 설정 또는 읽힐 때는 대소문자 구분되지 않는다. 동일한 명칭의 둘 이상의 메타데이터 헤더가 하나의 자원에 대해 제출된 경우, 파일 서비스는 상태 코드 400(Bad Request(잘못된 요청))을 반환한다.

SFA-REST 인터페이스는 공유, 디렉토리, 또는 파일에 대해 균일 자원 식별자("URI")(Uniform Resource Identifier) 참조를 지원할 수 있다. 각각의 파일 서비스 자원은 자원 자체를 참조하는 대응하는 기저 URI를 가질 수 있다. 저장소 계정의 경우, 기저 URI는 계정명만 포함할 수 있다. 공유의 경우, 기저 URI는 계정명 및 공유명을 포함할 수 있다. 디렉토리의 경우, 기저 URI는 계정명, 공유명, 및 디렉토리의 경로를 포함할 수 있다. 파일의 경우, 기저 URI는 계정명, 공유명, 및 파일의 경로를 포함한다. URI는 URI를 고유하게 구현할 수 있다. 모든 계정명이 고유하기 때문에, 2개의 계정이 동일한 명칭과의 공유를 가질 수 있다. 그러나 특정 저장소 계정 내에서, 매 공유가 고유의 명칭으로 구현될 수 있다. 특정 공유 또는 디렉토리 내 파일이 또한 상기 공유 또는 디렉토리 내 고유 명칭을 가질 수 있다. 명칭으로 공유, 디렉토리, 또는 파일을 생성하기 위한 시도가 명칭부여 규칙을 위반하면, 요청은 상태 코드 400(Bad Request(잘못된 요청))로 실패한다.

바이트 범위 잠금(byte range lock) 구성요소가 SFA-REST 인터페이스에 대한 바이트 범위 잠금을 지원할 수 있다. SFA 기반 API에 의해, SFA 클라이언트가 한 파일의 범위로의 배타적 액세스뿐 아니라 파일의 범위로의 읽기 액세스를 요청할 수 있다. 이는, 상기 범위 내에 어떠한 그 밖의 다른 쓰기가 없지만 읽기를 허용함을 보장한다. 바이트 범위 잠금 구성요소는 SFA 바이트 범위 잠금의 로직과 충돌이 존재할 때 REST 기반 API를 통한 읽기 또는 쓰기를 거절하도록 구성될 수 있다. SFA 기반 API에 의해 바이트 범위 잠금이 파일의 영역으로의 읽기 및 쓰기 액세스를 관리할 수 있고, REST 기반 API가 특정 구현에 대한 이 능력을 활용할 수 있다. 따라서 대신, REST 기반 API는 전체 파일로의 쓰기 액세스를 필요로 할 수 있다. 이는 또한 SFA 클라이언트가 파일 내 임의의 범위에 대한 잠금을 가질 경우, REST 기반 동작이 실패할 수 있음을 의미한다. 그럼에도, REST 기반 동작은 바이트 범위 잠금을 지원하는 REST 기반 API에 의해 구현될 수 있다.

액세스 구성요소가 2개의 서로 다른 프로토콜 종단점을 기초로 파일 서비스로의 액세스를 지원한다. 액세스 구성요소는 SFA 프로토콜에 대한 종단점과 REST v프로토콜에 대한 개별 종단점을 제공한다. 이와 관련하여, SFA 클라이언트에 대한 요청 및 응답이 SFA 프로토콜 종단점을 통해 전달되고 REST 클라이언트에 대한 요청 및 응답이 REST 프로토콜 종단점으로부터 통신된다.

잠금 구성요소는 파일 잠금을 관리한다. 잠금 구성요소는 SFA 기반 동작을 처리하고 동작 수정자를 이용해 동작을 수행하며 상기 동작 수정자의 참조에 기초해서 REST 기반 동작을 처리하도록 구성된다. 동작 수정자는 액세스 모드 및 공유 모드를 나타내는 잠금 수정자(locking modifier)일 수 있다. 예를 들어, SFA 클라이언트가 파일 공유로서 공유를 설정할 수 있다. SFA-REST 인터페이스를 이용해, SFA 클라이언트가 공유되는 파일로의 잠금 구성요소 관리 액세스에서 파일 시스템 잠금 메커니즘을 활용할 수 있다. 파일에 액세스하기 위한 SFA 기반 동작은 동작 수정자를 포함할 수 있다. 잠금 구성요소를 통해, 동작 수정자는 읽기, 쓰기, 및 삭제, 또는 바이트 범위 잠금이 단일 파일 내 영역으로의 읽기 및 쓰기 액세스를 관리하기 위한 전체 파일 액세스 공유를 요청하는 잠금 수정자일 수 있다. SFA 클라이언트가 파일을 열 때, 파일을 열기 위한 SFA 기반 동작은 파일 액세스 및 공유 모드를 갖는 잠금 수정자를 포함한다. 일반적으로 다음의 파일 액세스 잠금 수정자가 SFA 클라이언트에 의해 사용된다: 읽기(Read): 읽기 전용으로 파일을 연다. 쓰기(Write): 쓰기 액세스 전용으로 파일을 연다. 읽기/쓰기(Read/Write): 읽기/쓰기 권한을 갖고 파일을 연다. 삭제(Delete): 삭제 액세스 전용으로 파일 연다.

일반적으로 다음의 파일 공유 잠금 수정자가 SFA 클라이언트에 의해 사용된다: 없음(None): 현재 파일의 공유를 거절한다. 파일을 열기 위한 임의의 요청이 파일이 닫힐 때까지 실패할 것이다. 공유 읽기(Shared Read): 읽기 위한 파일의 다음 열기를 허용한다. 이 플래그가 특정되지 않는 경우, 파일을 열기 위한 임의의 요청이 파일이 닫힐 때까지 실패할 것이다. 공유 쓰기(Shared Write): 쓰기 위한 파일의 다음 열기를 허용한다. 이 플래그가 특정되지 않는 경우, 쓰기 위해 파일을 열기 위한 어떠한 요청도, 파일이 닫힐 때까지 실패할 것이다. 공유 읽기/쓰기(Shared Read/Write): 읽기 또는 쓰기 위한 파일의 다음 열기를 허용한다. 이 플래그가 특정되지 않는 경우, 읽기 또는 쓰기 위한 파일을 열기 위한 임의의 요청이 파일이 닫힐 때까지 실패할 것이다. 공유 삭제(Shared Delete): 파일의 다음 삭제를 허용한다. 이 플래그가 특정되지 않는 경우, 파일을 삭제하기 위한 어떠한 요청도 파일이 닫힐 때까지 실패할 것이다.

SFA 클라이언트 공유가 예시를 들어 더 설명될 수 있다. 예를 들어, 공유 위반 없이 파일 열기(File Opens without Sharing Violation): 클라이언트 A가 (열려 있는 동안 다음 읽기/쓰기 거부하는) 파일액세스.읽기(FileAcess.Read) 및 파일공유.쓰기(FileShare.Write)로 파일을 연다. 그 후 클라이언트 B가 (열려 있는 동안 다음 쓰기/삭제를 거부하는) 파일액세스.쓰기(FileAcess.Write) 및 파일공유.읽기(FileShare.Read)로 파일을 연다. 결과(Result): 이는 파일 액세스와 파일 공유 모드 간 어떠한 충돌도 없기 때문에 허용된다.

파일 액세스로 인한 공유 위반: 클라이언트 A가 (열려 있는 동안 다음 쓰기/삭제(Write/Delete)를 거부하는) 파일액세스.쓰기 및 파일공유.읽기로 파일을 연다. 그 후 클라이언트 B가 (열려 있는 동안 다음 읽기/삭제를 거부하는) 파일액세스.쓰기 및 파일공유.쓰기로 파일을 연다. 결과: 클라이언트 B는 클라이언트 A에 의해 이전에 특정된 공유 모드에 의해 거부되는 파일 액세스를 특정했기 때문에 공유 위반에 직면한다.

공유 모드로 인한 공유 위반: 클라이언트 A가 (열려 있는 동안 다음 읽기/삭제를 거부하는) 파일액세스.쓰기 및 파일공유.쓰기로 파일을 연다. 그 후 클라이언트 B가 (열려 있는 동안 다음 쓰기/삭제를 거부하는) 파일액세스.쓰기 및 파일공유.읽기로 파일을 연다. 결과: 클라이언트 B는 쓰기 액세스를 위해 여전히 열려 있는 파일로의 쓰기 액세스를 거부하는 공유 모드를 특정했기 때문에 공유 위반에 직면한다.

REST 기반 동작이 동작 수정에 의해 파일을 열지 않을 수 있다. 그러나 REST 기반 동작은 SFA 클라이언트 상에서 열린 임의의 파일에 대해 특정된 공유 모드를 존중한다. SMB 공유 모드와 인터렉션하는 REST 기반 동작이 예시로서 더 도시될 수 있다. REST 파일 얻기 공유 위반(REST Get File Sharing Violation): SFA 클라이언트가 (열려 있는 동안 다음 읽기/삭제를 거부하는 )파일액세스.읽기 및 파일공유.쓰기로 파일을 연다. 그 후 REST 클라이언트가 파일에 대해 파일 얻기(Get File)(REST API)를 수행한다(이로서, 앞서 테이블에 특정된 바 있는 파일액세스.읽기를 이용함). 결과: SFA 클라이언트가 여전히 읽기/삭제 액세스를 거부하는 동안 파일을 열어 놓았기 때문에 REST 클라이언트의 요청이 상태 코드(409)(Conflict(충돌)) 및 에러 코드 Sharing Violation(공유 위반)에 의해 실패한다.

REST 범위 배치(Put Range) 공유 위반: SFA 클라이언트가 (열려 있는 동안 다음 쓰기/삭제를 거부하는) 파일액세스.쓰기 및 파일공유.읽기로 파일을 연다. 그 후 REST 클라이언트가 파일에 대해 범위 배치(Put Range)(REST API) 동작을 수행한다(이로써, 앞서 테이블에 특정된 바 있는 파일액세스.쓰기를 이용함). 결과: SFA 클라이언트가 쓰기/삭제 액세스를 거부하면서 여전히 파일을 열어 놓기 때문에, REST 클라이언트의 요청은 상태 코드 409(Conflict(충돌)) 및 에러 코드 Sharing Violation(공유 위반)으로 실패한다.

SFA 클라이언트 공유 모드가 REST 기반 동작에 영향을 미칠 수 있다. SFA 클라이언트가 파일을 열었을 때 특정된 공유 모드에 따라, 파일 서비스가 에러 코드 공유 위반에 의해 충돌(가령, 상태 코드 409)을 반환할 수 있다. 파일이 SFA 클라이언트 상에서의 파일 열림으로 인한 공유 위반을 반환한다. 예를 들어, SFA 클라이언트 파일 공유 모드가 쓰기 및 삭제를 거부하는 공유 읽기일 수 있다. 따라서 파일 생성(creat file), 파일 속성 설정(set file properties), 파일 메타데이터 설정(set file metadata), 파일 삭제(delete file), 및 범위 배치(put range) REST 기반 동작이 공유 위반 표시와 함께 실패한다. 파일 서비스는 SFA 클라이언트 상에서의 파일 열림으로 인한 공유 위반을 반환할 수 있다.

삭제 구성요소가 삭제를 관리할 수 있다. 삭제 구성요소는 SFA 기반 삭제 동작을 처리하고 동작 수정자를 이용해 실행하며 동작 수정자를 참조하는 것에 기초해서 REST 기반 삭제 동작을 처리하도록 구성된다. SFA 클라이언트가 삭제를 위해 파일을 열 때, 나머지 모든 SFA 클라이언트 파일에 대한 오픈 핸들이 닫힐 때까지 삭제 계류로 표시한다. 파일이 삭제 계류로 표시되는 동안, 파일에 대한 임의의 REST 기반 동작이 에러 코드 식별자(가령, SMBDeletePending)와 함께 상태 코드를 반환할 것이다. 파일을 닫기 전에 SFA 클라이언트가 삭제 계류 플래그를 삭제하는 것이 가능하기 때문에 상태 코드 404는 반환되지 않는다. 다시 말하면, 파일이 제거된 때 상태 코드 404(not found(발견되지 않음))가 예상된다. 또한, 파일이 SMB 삭제 계류 상태에 있을 때, 파일 나열(List Files) 결과에 포함되지 않을 수 있다. REST 기반 파일 삭제 및 디렉토리 삭제 동작이 원자적으로(atomically) 커밋(commit)되며 삭제 계류 상태를 도출하지 않는 것이 고려된다.

속성(attribute) 구성요소가 REST 기반 동작에 영향을 미치는 파일 속성을 관리하도록 구성된다. SFA 기반 동작을 이용하는 SFA 클라이언트가 파일 속성, 가령, 저장(Archive), 읽기 전용(Read-only), 숨김(Hidden), 및 시스템(System)을 읽고 설정할 수 있다. 파일 또는 디렉토리가 읽기 전용 속성으로 설정된 경우(읽기 공유로 SMB에서 열려 있는 경우라도), 파일에 쓰기를 시도하는 임의의 REST 기반 동작이 상태 코드 412(Precondition Failed(전제조건 실패)) 및 에러 코드 식별자(가령, ReadOnly Attribute)로 실패할 수 있다. 이들 REST 기반 동작은 다음을 포함할 수 있다: 파일 생성(Create File), 파일 속성 설정(Set File Properties), 파일 메타데이터 설정(Set File Metadata), 및 범위 배치(Put Range). 또한, 파일 속성이 REST 클라이언트로부터 설정되거나 읽히지 않을 수 있다. 파일이 읽기 전용으로 만들어지면, REST 클라이언트는 SFA 클라이언트가 읽기 전용 속성을 제거할 때까지 파일에 쓰기를 할 수 없을 것이다.

도 2d를 계속 참조하면, 파일 서비스가 파일 서비스 스키마 자원(270)을 지원한다. 따라서 SFA-REST 인터페이스가 스키마에 기초해서 파일에 액세스하는 것을 촉진시킨다. SFA 클라이언트 또는 REST 클라이언트 각각이 SFA-REST 인터페이스에 기초해서 구현된 스키마를 이용해 파일 시스템 내 파일에 액세스하는 SFA 기반 동작 또는 REST 기반 동작을 생성할 수 있다. 이와 관련하여, 스키마 필드가 파일 시스템으로의 병렬 SFA 기반 및 REST 기반 액세스를 지원하는 SFA-REST 인터페이스의 요소를 포함한다.

스키마는 논리 스키마일 수 있다. 기저 데이터베이스의 늬앙스를 고려하기 위해 스키마의 물리적 표현은 상이할 수 있다. 스키마의 물리적 표현은 또한 역호환( backward compatible)되도록 변경될 수 있다. 스키마는 복수의 테이블을 기초로 할 수 있다. 하나의 구현예에서, 스키마는 8개의 파일 액세스 테이블 및 공유 테이블을 포함한다. 주 테이블은 파일 및 디렉토리가 이들 명칭을 기초로 저장되는 명칭공간 테이블일 수 있다. 명칭공간 테이블은 공유명을 포함할 수 있다. 명칭공간 테이블은 파일 및 디렉토리가 이들 부모 디렉토리의 자식으로서 저장되는 계층구조적일 수 있다. 파일 또는 디렉토리의 전체 경로가 명칭공간 테이블 내 복수의 조사(lookup)에 기초해서 결정된다. 파일은 또 다른 액세스 테이블 내 파일에 대한 정보를 조사하는 데 사용되는 테이블 내 ID를 포함할 수 있다.

스키마는 또한 정보 테이블을 포함할 수 있다. 정보 테이블은 파일의 내용에 대한 정보를 저장하는 데 사용될 수 있다. 정보 테이블은 파일 내용 자체는 저장하지 않는다. 이 테이블로의 키(key)는 파일 ID이다.

또한 스키마가 페이지 범위(page range) 테이블을 지원할 수 있다. 페이지 범위 테이블은 저장된 파일에 대한 실제 데이터를 저장하는 데 사용될 수 있다. 페이지 범위 테이블로의 키는 파일 ID와 저장된 페이지 범위의 크기로서의 오프셋 모두를 포함한다.

스키마는 핸들 테이블을 더 지원할 수 있다. 핸들 테이블은 파일 상에서 개방된 핸들을 나타내도록 사용될 수 있다. 핸들 테이블은 파일 시스템 내 파일로 핸들을 반환하는 파일 열기 또는 생성을 지원한다. 핸들이 반환될 때 클라이언트는 핸들을 이용해 파일을 읽고 파일에 쓰기를 할 수 있다.

스키마는 또한 임대 테이블을 지원한다. 임대 테이블은 동작 수정자에 기초해서 파일 캐싱을 위해 제공되는 SMB 임대를 지원하는 데 사용될 수 있다. 구체적으로, 임대 테이블은 대응하는 파일과 연관된 SFA 기반 동작의 동작 수정자에 기초해서 하는 임대 상태를 저장하는 데 사용될 수 있다.

2개의 추가 액세스 테이블이 디렉토리에 대한 변경 통지 설정 및 이벤트를 저장하기 위해 스키마 내에 구성될 수 있다. 2개의 테이블은 변경 통지 테이블 및 변경 통지 이벤트 테이블일 수 있다. 구체적으로, 변경 통지 테이블은 동작이 디렉토리 내 변경을 검출하는 것을 등록할 때 업데이트될 수 있다. 파일에 대해 쓰기 동작이 수행될 때마다, 대응하는 동작이 실행되어 변경 통지 테이블을 체크하여 데이터가 이벤트 테이블에 입력될 필요가 있는지 여부를 결정할 수 있다.

바이트 잠금 테이블이 파일에 대한 바이트 범위 잠금을 저장하는 데 사용될 수 있다. 바이트 범위 잠금은 파일 서비스를 통해 획득될 수 있다. 바이트 범위 잠금은 SFA 클라이언트가 파일의 한 범위로의 배타적 액세스를 요청할 뿐 아니라 파일의 한 범위로의 읽기 액세스를 요청하는 시나리오를 지칭한다. 이는 상기 범위 내에서 해당 범위 내에 그 밖의 다른 어떠한 쓰기도 없지만, 읽기가 허용됨을 보장한다.

도 2d를 계속 참조하면, 복수의 로드 밸런서(도시되지 않음)가 클라우드 컴퓨팅 인프라구조에 걸친 파티션을 위해 구현될 수 있다. 원자적으로 실행되는 트랜잭션이 단일 파티션 내에서 실행된다. 예를 들어, 원자적 트랜잭션은 모두 발생하거나 아무 것도 발생하지 않는 일련의 데이터베이스 동작을 지칭한다. 원자성의 보장이 전체 시리즈를 전면적으로 거절하는 것보다 더 큰 문제를 야기할 수 있는 데이터베이스로의 업데이트가 부분적으로만 발생하는 것을 막는다. 원자성은 불가분성 및 비축소가능성을 지칭한다. 하나의 실시예에서, 스키마가 공유 레벨로 파티셔닝된다. 이와 관련하여, 공유 상의 트랜잭션이 단일 파티션 내에서 구현될 수 있다. 공유가 복수의 파티션에 저장될 수 있도록 스키마가 파티션 키의 일부인 숫자 키의 증가를 더 허용할 수 있다. 이로 인해, 단일 공유가 복수의 백엔드 노드에 의해 서비스될 수 있고, 이는 더 우수한 성능을 도출한다.

파일 서비스가 파일 저장소를 빠르고 쉽게 백업하기 위한 스냅샷을 구현하는 스냅샷 구성요소를 지원한다. 스키마는 스냅샷을 용이케 한다. 스키마 내 공유 테이블이 스냅샷 동작을 지원한다. 특히, 새로운 변경이 쓰기 시 복사(copy-on-write) 유형의 패턴으로 써질 수 있어서, 각각의 스냅샷에서의 오래된 버전이 차후에 액세스될 수 있도록 한다. 정상 상태에서 스냅샷이 찍히기 전에, 공유 테이블은 모든 공유에 대한 항목(entry)을 가질 수 있다. 공유 테이블 스키마는 공유에 대한 액세스 권한, 한 행이 유효한지 여부에 대한 표시, 마지막 수정 시점 및 만료 시점, 및 스냅샷 동작을 수행하는 것을 촉진하는 스냅샷 버전을 포함한다.

공유 스냅샷은 3개의 동작을 기초로 할 수 있다. 업데이트 동작은 공유 테이블을 업데이트하여 스냅샷이 생성될 것을 표시할 수 있다. 업데이트 생성 동작은 스냅샷 버전 식별자를 갖는 새 행을 추가하는 것 및 스냅샷의 타임스탬프를 포함하도록 스냅샷 버전 식별자로 상기 행을 업데이트하는 것을 포함한다. 이때, 공유에 쓰기를 하고 있는 임의의 클라이언트가 존재하는 경우, 쓰기는 스냅샷 버전 0으로 계속된다. 스냅샷이 실패하면, 하루 후에 만료될 때 동작은 스냅샷 버전 0을 폐기(clean up)한다. 쓰기 통지 동작이 공유에 대한 새 스냅샷 버전으로 쓰기 시작하기 위해 공유를 지원하는 노드에게 통지하는 것을 포함한다. 다시 말하면, 실패가 발생하는 경우, 오래된 스냅샷 버전으로 쓰기를 야기할 것이며, 폐기가 차후 발생할 수 있다. 세 번째 동작은 스냅샷이 성공적으로 완료됐음을 가리키도록 공유 테이블을 업데이트하는 업데이트 완료 동작이다. 파일 서비스가 클라이언트로 스냅샷이 성공적으로 완료됐다는 통지를 전송할 수 있다. 변경이 테이블에 커밋될 수 없는 경우, 클라이언트는 또한 유효한 버전 1에 쓰기를 할 것이다.

스냅샷 구성요소는 가비지 콜렉션(garbage collection)을 더 지원한다. 스냅샷 동작의 실패가 있을 시 가비지 콜렉션은 공유 테이블 상에서 수행될 수 있다. 예를 들어, 실패한 스냅샷 버전을 갖는 행이 지정 시간 후에 스스로 자동으로 폐기될 수 있다. 또한 스냅샷 구성요소는 또 다른 스냅샷을 생성하며, 테이블이 업데이트될 수 있고, 공유에 쓰기를 하는 노드가 스냅샷 버전 2에 쓰기를 할 수 있다.

스냅샷 구성요소는 원자적 스냅샷(atomic snapshot), 비-원자적 스냅샷(non-atomic snapshot), 및 교차-공유 원자적 스냅샷(cross-share atomic snapshot)을 더 지원할 수 있다. 스냅샷 구성요소는 원자적 스냅샷을 생성하기 위해 노드와 통신할 수 있다. 각각의 노드가 파일 스키마의 파티션을 수정할 수 있다. 특히, 각각의 노드는 파티션을 원자적으로 수정할 수 있다. 스냅샷 구성요소는 노드로 통지를 전송할 수 있다. 원자적 스냅샷 프로세스는 2개의 통지를 포함한다. 차단 통지가 하나 이상의 노드에게 선택된 파티션으로의 쓰기를 차단할 것을 지시한다. 차단 통지는 블록이 선택된 파티션에 쓰기하는 동안의 고정 시간을 포함할 수 있다. 쓰기 통지는 하나 이상의 노드에게 새 스냅샷 버전으로의 쓰기를 시작하도록 지시한다. 하나 이상의 노드 모두가 고정된 시간 내에 새 버전으로 쓰기를 시작할 수 없기 때문에 쓰기 동작이 완료될 수 없는 경우, 스냅샷 구성요소는 스냅샷을 실패할 수 있다. 실패 시, 스냅샷 구성요소는 또 다른 스냅샷 동작을 시도할 수 있다. 새 스냅샷 동작이 새 버전으로서 새 스냅샷을 생성할 수 있다.

스냅샷 구성요소가 또한 비-원자적 스냅샷을 생성하는 것을 촉진시킬 수 있다. 비-원자적 스냅샷은 단일 쓰기 통지를 이용해 생성될 수 있다. 스냅샷 구성요소는 하나 이상의 노드에게 새 스냅샷 버전으로의 쓰기를 시작하도록 지시하는 통지를 통신할 수 있다. 그 후 스냅샷 구성요소는 하나 이상의 노드가 모두 새 버전의 스냅샷을 사용 중인 때 공유 테이블을 업데이트할 수 있다.

또한 스냅샷 구성요소는 교차-공유 원자 스냅샷을 생성하는 것을 촉진시킬 수 있다. 교차-공유 원자 스냅샷은 복수의 공유 간에 확장될 수 있는 스냅샷을 지칭할 수 있다. 스냅샷 구성요소는 교차-공유 원자적 스냅샷을 실행하기 위한 일련의 동작을 수행한다. 스냅샷 구성요소는 새 행을 스냅샷의 일부인 공유의 테이블에 추가할 수 있다. 그 후 스냅샷 구성요소는 스냅샷의 공유에 대응하는 하나 이상의 노드에게 새 스냅샷 버전으로 쓰기를 시작하도록 지시하는 쓰기 통지를 통신한다. 그 후 스냅샷 구성요소가 공유 테이블을 업데이트할 수 있다. SFA 클라이언트 또는 REST 클라이언트가 스냅샷 버전과 연관된 타임스탬프에 기초해서 스냅샷 버전을 지칭할 수 있다. 동일한 타임스탬프가 복수의 공유로부터 스냅샷 버전에 할당될 수 있다. 이와 관련하여, 동일한 타임스탬프를 갖는 스냅샷 버전의 공유가 구조적으로 링크될 수 있다.

도 3을 다시 참조하면, 분산된 파일 시스템 내의 파일에 액세스하기 위한 방법(300)의 흐름도가 제공된다. 먼저 블록(300)에서, 분산된 파일 시스템 내의 파일에 대한 동작 수정자를 갖는 SFA 기반 동작이 수신된다. SFA 기반 동작은 파일-REST(representational state transfer) 인터페이스에 기초해서 정의된다. SFA-REST 인터페이스는 SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함한다. 블록(310)에서, 분산된 파일 시스템 내의 파일에 대한 REST 기반 동작이 SFA-REST 인터페이스에 기초해서 정의된다. 블록(330)에서, SFA 기반 동작이 동작 수정자를 이용해 실행된다. 블록(340)에서, 동작 수정자는 REST 기반 동작을 실행하도록 참조된다. REST 기반 동작이 SFA-REST 인터페이스에 기초해서 실행된다.

도 4를 다시 참조하면, 파일 공유를 스냅샷하기 위한 방법(400)을 도시하는 흐름도가 제공된다. 우선, 블록(410)에서, 파일 공유를 포함하는 공유 테이블이 업데이트된다. 공유 테이블을 업데이트하는 것은 행을 공유 테이블에 추가하는 것을 포함하며, 여기서 행은 파일 공유의 새로운 버전과 연관된다. 블록(420)에서, 노드에게 파일 공유의 새 버전으로 쓰기를 시작할 것을 지지하는 통지가 상기 파일 공유와 연관된 노드로 통신된다. 블록(430)에서, 노드가 파일 공유의 새 버전에 쓰기 중임이 결정된다. 블록(440)에서, 스냅샷이 성공적으로 완료됐음을 가리키도록 공유 테이블이 업데이트된다.

도 5를 다시 참조하면, 분산된 파일 시스템 내의 파일에 액세스하기 위한 방법(500)을 도시하는 흐름도가 제공된다. 우선, 블록(510)에서, 분산된 파일 시스템 내의 파일에 대한 SFA 기반 동작이 SFA 클라이언트로부터 수신된다. SFA 기반 동작이 SFA 기반 동작의 기회적 잠금을 나타내는 동작 수정자를 가진다. 상기 SFA 기반 동작은 SFA-REST 인터페이스에 기초해서 정의된다. 블록(520)에서, REST 기반 동작이 SFA 기반 동작의 동작 수정자를 참조하는 것에 기초해서 파일 상에서 실행된다. 블록(530)에서, 분산된 파일 시스템 내의 파일에 대한 REST 기반 동작이 REST 클라이언트로부터 수신된다. 상기 REST 기반 동작이 SFA-REST 인터페이스에 기초해서 정의된다. 블록(540)에서, REST 기반 동작이 SFA 기반 동작의 동작 수정자를 참조하는 것에 기초해서 파일에 대해 실행된다.

도면의 흐름도가 예시로서 더 기재될 수 있다. 상기에서 언급된 바와 같이 SMB 기회적 잠금(oplock)이 SMB 클라이언트가 성능을 개선하고 네트워크 전달을 감소시키기 위해 요청할 수 있는 캐싱 수단이다. 따라서 특정 파일 또는 디렉토리의 최신 상태가 SMB 클라이언트 상에 캐싱될 수 있다. SMB 임대 유형이라고 지칭되는 다음의 복수의 기회적 잠금 유형이 존재한다: 읽기(R): 획득될 때, 클라이언트는 로컬 캐시로부터 읽을 수 있다; 쓰기(W): 획득될 때, 클라이언트는 SMB 서비스로 데이터를 다시 플러싱할 필요 없이 로컬하게 쓰기를 할 수 있다; 핸들(H): 획득될 때, 클라이언트는 핸들 닫힘이 발생할 때 SMB 서비스에게 즉시 통지할 필요가 없다. 이는 애플리케이션이 동일한 액세스 및 공유 모드로 파일을 열고 닫는 것을 계속하는 경우 유용하다. 상기 SMB 임대 유형이 특정된 액세스 및 공유 모드에 독립적임을 통지하는 것이 중요하다. 일반적으로, 액세스 및 공유 모드에 무관하게, 파일에 대해 새로운 핸들을 열 때마다, SMB 클라이언트가 모든 임대 유형을 획득하려 시도한다.

호출되는 REST 동작에 따라, 요청이 기존 기회적 잠금을 파기할 필요가 있을 수 있다. 쓰기 oplock의 경우, SMB 클라이언트는 파일 서비스로 캐싱된 변경을 플러싱(flush)해야 한다. 각각의 유형의 oplock이 파기될 필요가 있는 일부 경우가 다음과 같다: 읽기(R) oplock이 쓰기 동작이 발행될 때마다, 가령, 범위 배치(Put Range) 때마다, 파기될 필요가 있다; 쓰기(W) oplock은, 읽기 동작이 발행될 때마다, 가령, 파일 얻기(Get File) 때마다, 파기될 필요가 있다; 핸들(H) oplock은, 삭제 동작이 성공적인 경우 파일 서비스가 어떠한 핸들도 열리지 않을 것을 요구하기 때문에 클라이언트가 삭제 동작을 발행할 때마다 파기될 필요가 있다. 핸들이 클라이언트 상의 애플리케이션에 의해 실제로 열려 있음을 검증하기 위해 REST 동작이 기존 SMB 핸들과 공유 위반에 직면할 때(상기 테이블 참조) 핸들 oplock은 또한 파기된다.

oplock을 파기하는 것은 캐싱된 SMB 클라이언트 변경을 플러싱하는 것을 필요로 할 수 있으며, 이로 인해, 동작 응답 시간의 지연이 야기되거나, 상태 코드 408(요청 타임아웃) 및 에러 코드 ClientCacheFlushDelay에 의해 동작이 실패할 수 있다. oplock이 파기되는 일부 시나리오가 다음에서 제공된다:

제1 예시에서, oplock 파기 및 SMB 클라이언트 플러싱이 요구되며 REST 클라이언트가 딜레이를 경험한다: (1) SMB 클라이언트가 파일을 열고, RWH oplock을 획득하며, 데이터를 로컬하게 쓴다. (2) REST 클라이어언트가 파일 얻기(Get File) 요청을 전송한다. (2)(i) 파일 서비스가 쓰기(W) oplock을 파기하여, 클라이언트에게 RH oplock을 남긴다. (2)(ii) SMB 클라이언트가 자신의 캐싱된 데이터를 파일 서비스에 대해 플러싱하고 oplock 파기를 긍정응답한다. (2)(iii) 파일 서비스는 파일 얻기(Get File) 요청을 처리하고 요청된 데이터로 다시 응답한다. 상기 예시에서, REST 클라이언트가 oplock 차단에 의해 야기되는 딜레이, 및 SMB 클라이언트가 자신의 데이터를 파일 서비스로 플러싱하는 데 걸리는 시간을 겪을 수 있다. 쓰기(W) oplock이 이미 파기되었기 때문에 파일 얻기(Get File)로의 다음 호출이 어떠한 추가 딜레이도 경험하지 않을 것이다.

제2 예시에서, oplock 파기가 요구되지만, REST 클라이언트가 딜레이를 경험한다. (1) SMB 클라이언트가 RH oplock을 획득했다. (2) REST 클라이언트가 범위 배치(Put Range) 요청을 전송한다. (2)(i) 파일 서비스는 SMB 클라이언트로 oplock 파기 요청을 전송하고 응답을 기다리지 않는다. (2)(ii) 파일 서비스는 범위 배치(Put Range) 요청을 처리한다. 상기 예시에서, oplock 파기가 요구되지만, 읽기 oplock을 파기할 때 응답이 필요하지 않기 때문에 범위 배치(Put Range) 요청은 어떠한 추가 딜레이도 경험하지 않을 것이다.

각각의 REST 동작에 대한 파일 서비스의 거동이 동일한 파일 상의 핸들을 이미 획득한 SMB 클라이언트의 oplock 상태에 기초해서 하며, SMB 핸들 액세스 및 공유가 REST 동작과 충돌하지 않는다고 가정하는 몇 가지 동작이 존재한다. 충돌이 존재하는 경우, 핸들 oplock이 또한 파기되어 핸들이 클라이언트 상에서 실제로 여전히 열려 있음을 보장할 수 있다. oplock 파기를 차단하는 경우, 파일 서비스가 파기가 성공적이었다는 긍정응답을 기다릴 수 있다. oplock 파기를 비-차단하는 경우, 기다릴 필요가 없다.

oplock 파기 차단이 요구되는 경우, 파기가 특정 요청 타임아웃 또는 30초 중 먼저 완료되는 시간 내에 성공하지 않는 경우, REST 동작이 상태 코드(408)(Request Timeout) 및 에러 코드 ClientCacheFlushDelay로 실패할 것이다. 파일 삭제(Delete File) 요청이 또한 oplock 핸들(H) 임대를 파기할 것을 요구한다. 이는 REST 클라이언트가 파일 삭제를 호출할 때 임의의 파일 핸들이 SMB 클라이언트 상의 애플리케이션에 의해 실제로 여전히 열려 있음을 보장한다. 공유 위반이 존재하는 경우, 요청이 상태 코드 409(Conflict(충돌)) 및 에러 코드 Sharing Violation(공유 위반)으로 실패한다.

도 6을 참조하면, 분산된 파일 시스템 내의 파일에 액세스하기 위한 방법(500)을 도시하는 흐름도가 제공된다. 우선, 블록(610)에서, 분산된 파일 시스템 내의 파일에 대한 SFA 기반 동작이 SFA 클라이언트로부터 수신된다. SFA 기반 동작이 SFA 기반 동작의 액세스 공유 모드를 가리키는 동작 수정자를 가진다. SFA 기반 동작이 SFA-REST 인터페이스에 기초해서 정의된다. 블록(620)에서, SFA 기반 동작의 동작 수정자를 참조하는 것에 기초해서 REST 기반 동작이 파일 상에서 실행된다. 블록(630)에서, 분산된 파일 시스템 내의 파일에 대한 REST 기반 동작이 REST 클라이언트로부터 수신된다. REST 기반 동작이 SFA-REST 인터페이스에 기초해서 정의된다. 블록(640)에서, REST 기반 동작이 SFA 기반 동작의 동작 수정자를 참조함으로써 파일 상에서 실행된다.

도면의 흐름도가 예시를 들어 더 기재될 수 있다. REST 파일 얻기 공유 위반(Get File Sharing Violation)이 SMB 클라이언트가 파일공유.쓰기(FileShare.Write)에 의해(그러나 그 밖의 다른 클라이언트가 동시에 파일을 읽을 수 있도록 허용할 파일공유.읽기(FileShare.Read)는 없이) 파일을 열 때 발생할 수 있다. 그 후 REST 클라이언트가 파일에 대한 파일 얻기(Get File)(REST API) 동작을 수행한다(따라서 앞서 테이블에서 특정된 바와 같이 파일 액세스.읽기(File Access.Read)를 이용한다). 이로 인해, SMB 클라이언트가 읽기/삭제 액세스를 거부하는 동안 파일이 여전히 열려 있도록 하기 때문에 REST 클라이언트의 요청이 상태 코드 409(Conflict(충돌)) 및 에러 코드 공유 위반을 도출한다.

표 1을 참조하면, REST 기반 동작이 액세스 모드에 기초해서 실행되도록 REST 기반 동작이 수신될 때 복수의 서로 다른 SMB 액세스 모드가 결정될 수 있다.

표 1에서 나타나는 바와 같이, 파일 나열(List Files) (REST API), 파일 속성 얻기(Get File Properties) (REST API), 및 파일 메타데이터 얻기(Get File Metadata) (REST API)가 SMB 파일 콘텐츠 상에서 동작하지 않고 파일로의 읽기 액세스를 필요로 하지 않는다(즉, 이들 동작은 SMB 클라이언트가 배타적 읽기 액세스를 위해 파일을 연 상태로 두는 경우라도 여전히 성공적일 것이다).

SMB 클라이언트가 파일을 열 때 특정된 공유 모드에 따라, REST 서비스가 앞서 표 2에서 기재된 바와 같이 에러 코드 공유 위반과 함께 상태 코드 409(충돌)를 반환할 수 있는 것도 생각할 수 있다.

본 발명의 실시예들이 한정이라기보다는 예시로서 의도된 특정 실시예와 관련하여 기재되었다. 대안적 실시예가 발명의 범위 내에서 본 발명이 속하는 해당 분야의 통상의 기술자에게 자명할 것이다.

상기의 내용으로부터, 앞서 제공된 모든 목적을 이루도록 구성된 하나의 발명이 본 발명의 구조에 내재적인 자명한 그 밖의 다른 이점도 함께 제공함이 자명할 것이다.

특정 특징 및 이들의 부분 조합이 유용하며 그 밖의 다른 특징 또는 하위 조합을 참조하지 않고 사용될 수 있음이 이해되어야 한다. 이는 이하의 청구범위에 의해 고려되고 상기 청구범위 내에 있다.

Claims

분산된 파일 시스템 내에서 REST 기반 동작 및 SFA 기반 동작을 실행하는 시스템으로서,
상기 시스템은 하나 이상의 하드웨어 프로세서와, 컴퓨터-실행 가능 명령어 및 구성요소(component)가 저장된 컴퓨터 저장 매체를 포함하고,
상기 컴퓨터-실행 가능 명령어 및 구성요소는 실행될 때, 상기 하나 이상의 하드웨어 프로세서로 하여금, SFA-REST(Shared File Access-Representational State Transfer) 인터페이스 구성요소를 실행하게 하고,
상기 SFA-REST 인터페이스 구성요소는,
분산된 파일 시스템 내에서 하나 이상의 SFA 기반 동작을 수신하고,
SFA-REST 인터페이스에 기초해서 상기 하나 이상의 SFA 기반 동작을 처리하며 - 상기 SFA-REST 인터페이스는 SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함함 - ,
상기 분산된 파일 시스템 내의 파일에 대한 하나 이상의 REST 기반 동작을 수신하고,
상기 SFA-REST 인터페이스에 기초해서 상기 하나 이상의 REST 기반 동작을 처리하며,
제 1 파일에 대해서 SFA 기반 동작을 실행하고,
제 2 파일에 대해서 SFA 기반 동작을 실행하며,
상기 제 2 파일에 액세스하는 현재 실행 중인 SFA 기반 동작을 부분적으로 참조하는 것에 기초해서 상기 제 2 파일에 대해서 REST 기반 동작을 실행하도록 구성되는
시스템.
제 1 항에 있어서,
상기 SFA-REST 인터페이스 구성요소는 데이터 액세스 구성요소를 더 포함하고, 상기 데이터 액세스 구성요소는
상기 SFA 기반 동작에 대한 상기 제 1 파일에 대응하는 핸들은 반환하고,
상기 REST 기반 동작에 대한 상기 제 2 파일에 대응하는 핸들은 반환하지 않도록 구성되는,
시스템.
제 1 항에 있어서,
상기 SFA-REST 인터페이스 구성요소는 임대 구성요소를 더 포함하고, 상기 임대 구성요소는,
상기 제 2 파일에 대한 REST 임대를 허가하고 - 상기 REST 임대는 상기 제 2 파일로의 배타적 쓰기 공유된 읽기 액세스를 지원함 - ,
REST 임대에 기초해서 혹은 파일들과 연관된 동작 수정자의 핸들에 기초해서 상기 파일들로의 공유된 액세스를 허가하도록 - 상기 하나 이상의 SFA 기반 동작은 상기 하나 이상의 SFA 기반 동작을 수정하는 제약(constraint)을 정의하는 동작 수정자를 포함함 - 구성되는
시스템.
제 1 항에 있어서,
상기 SFA-REST 인터페이스 구성요소는 캐시 구성요소를 더 포함하고, 상기 캐시 구성요소는,
상기 하나 이상의 SFA 기반 동작의 동작 수정자와 연관된 기회적 잠금을 식별하고 - 상기 기회적 잠금은 파일의 최신 상태가 상기 SFA 기반 동작과 연관된 SFA 클라이언트 상에 캐싱됨을 나타냄 - ,
상기 동작 수정자를 참조하는 것에 기초해서 상기 SFA 기반 동작의 상기 기회적 잠금을 파기하도록 결정하며,
상기 하나 이상의 REST 기반 동작이 실행되도록 기회적 잠금 파기 동작을 수행하도록 구성되는
시스템.
제 1 항에 있어서,
상기 SFA-REST 인터페이스 구성요소는 타임스탬프 구성요소를 더 포함하고, 상기 타임스탬프 구성요소는,
상기 하나 이상의 SFA 기반 동작 및 상기 하나 이상의 REST 기반 동작 모두에 대한 상기 분산된 파일 시스템 내의 파일들에 대한 복수의 타임스탬프를 생성하도록 구성되는 - 상기 복수의 타임스탬프는 적어도, 개체 태그(ETAG) 타임스탬프 및 생성 시점, 마지막 수정 시점, 마지막 쓰기 시점, 및 마지막 액세스 시점 중 하나 이상을 포함하고, 상기 ETAG 타임스탬프는 상기 하나 이상의 REST 기반 동작과 상기 하나 이상의 SFA 기반 동작 모두에 대해 낙관적 동시수행(optimistic concurrency)을 지원하도록 업데이트됨 -
시스템.
제 1 항에 있어서,
상기 SFA-REST 인터페이스 구성요소는,
상기 하나 이상의 REST 기반 동작과 상기 하나 이상의 SFA 기반 동작 모두에 대응하는 메타데이터에 대한 제한된 명칭 세트를 제공하도록 구성된 메타데이터 구성요소와,
대소문자 비구분 방식(case insensitive) 및 대소문자 보존 방식(case preserving) 디렉토리 명칭 및 파일명 시스템을 구현하도록 구성되는 명칭부여 및 참조 구성요소
를 더 포함하는
시스템.
제 1 항에 있어서,
상기 SFA-REST 인터페이스 구성요소는 바이트 잠금 구성요소를 더 포함하고,
상기 바이트 잠금 구성요소는, 상기 하나 이상의 SFA 기반 동작의 바이트 범위 잠금의 로직과 충돌이 존재할 때, 상기 하나 이상의 REST 기반 동작을 통한 읽기 동작 또는 쓰기 동작을 거절하도록 구성되고,
SFA 기반 바이트 범위 잠금은 파일의 영역으로의 읽기 및 쓰기 액세스를 정의하는
시스템.
제 1 항에 있어서,
상기 SFA-REST 인터페이스 구성요소는 상기 하나 이상의 SFA 기반 동작과 연관된 잠금 동작 수정자를 실행하도록 구성된 잠금 구성요소를 더 포함하고,
파일로의 액세스는 상기 하나 이상의 SFA 기반 동작의 잠금 동작 수정자에 기초해서 처리되는,
시스템.
제 1 항에 있어서,
복수의 테이블을 포함하는 파일 서비스 스키마를 더 포함하고,
상기 복수의 테이블은 상기 분산된 파일 시스템 내 파일의 상태를 저장하며,
상기 복수의 테이블은 상기 SFA-REST 인터페이스의 요소에 대응하는 필드를 포함하는
시스템.
제 1 항에 있어서,
파일 공유를 스냅샷해서 상기 파일 공유의 콘텐츠를 백업하도록 구성된 스냅샷 구성요소를 더 포함하고,
상기 파일 공유는, 쓰기 시 복사(copy-on-write) 유형 패턴을 사용해서 상기 파일 공유에 기록되는 상기 파일 공유에 대한 변경을 포함해서, 각각의 스냅샷의 이전 버전이 독립적으로 액세스될 수 있게 하며,
상기 파일 공유를 스냅샷하는 것은
2-패스 통지 및 기록 명령어 동작을 포함하는 원자적 스냅샷(atomic snapshot) 동작,
단일 패스 기록 명령어 동작을 포함하는 비-원자적 스냅샷(non-atomic snapshot) 동작, 또는
복수의 파일 공유를 스냅샷하는 것을 포함하는 교차-공유 원자적 스냅샷(cross-share atomic snapshot)
중 하나에 기초하는
시스템.
제 1 항에 있어서,
상기 파일 및 파일 공유의 스냅샷을 나타내는 스키마를 구비한 공유 테이블을 포함하는 스냅샷 구성요소를 더 포함하고,
상기 공유 테이블은 상기 파일 공유에 대한 항목(entry) 및 상기 파일 공유의 스냅샷에 대한 하나 이상의 항목을 포함하는
시스템.
분산된 파일 시스템 내에서 REST 기반 동작 및 SFA 기반 동작을 실행하는 시스템으로서,
상기 시스템은 하나 이상의 하드웨어 프로세서와, 컴퓨터-실행 가능 명령어가 저장된 컴퓨터 저장 매체를 포함하고,
상기 컴퓨터-실행 가능 명령어는 실행될 때, 상기 하나 이상의 하드웨어 프로세서로 하여금,
복수의 테이블을 포함하는 파일 서비스 스키마를 실행하게 하고,
상기 복수의 테이블은 상기 분산된 파일 시스템 내 파일의 상태를 저장하며,
상기 복수의 테이블은 SFA-REST(Shared File Access-Representational State Transfer) 인터페이스의 요소에 대응하는 필드를 포함하고,
상기 SFA-REST 인터페이스는, 상기 파일 시스템 내의 파일에 엑세스하도록 함께 실행되는 하나 이상의 REST 기반 동작과 하나 이상의 SFA 기반 동작을 참조하기 위해, SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함하는
시스템.
제 12 항에 있어서,
상기 파일 서비스 스키마는 파일 및 디렉토리의 대응하는 명칭에 기초해서 상기 파일 및 상기 디렉토리를 저장하기 위한 계층구조적 테이블(hierarchical table)을 더 포함하며,
상기 파일 및 상기 디렉토리는 복수의 파일 식별자를 저장하는 명칭공간(namespace) 테이블의 조사(lookup)를 이용해서 취득되는
시스템.
제 12 항에 있어서,
명칭공간 테이블을 더 포함하고,
상기 명칭공간 테이블은 상기 파일 서비스 스키마의 주 테이블(primary table)인
시스템.
제 12 항에 있어서,
파일 정보 테이블을 더 포함하고,
상기 파일 정보 테이블은 파일의 내용에 대한 정보를 저장하며,
상기 파일 정보 테이블은 파일에 대한 복수의 타임스탬프 필드를 포함하는
시스템.
제 12 항에 있어서,
파일 페이지 범위(page range) 테이블을 더 포함하고,
상기 파일 페이지 범위 테이블은 파일과 연관된 데이터를 포함하며,
상기 테이블에 대한 키는 파일 식별자 및 파일에 대해 저장된 페이지 범위의 오프셋 크기를 포함하는
시스템.
제 12 항에 있어서,
핸들 테이블을 더 포함하고,
상기 핸들 테이블은 하나 이상의 SFA-REST 인터페이스 동작에 대한 하나 이상의 오픈 핸들을 포함하는
시스템.
제 12 항에 있어서,
임대 테이블을 더 포함하고,
상기 임대 테이블은 파일과 연관된 임대를 저장하는
시스템.
제 12 항에 있어서,
변경 통지 테이블 및 변경 통지 이벤트 테이블을 더 포함하고,
상기 변경 통지 테이블은 디렉토리 내 변경을 검출하는 것을 등록할 때 업데이트되고, 상기 변경 통지 이벤트 테이블은 저장된 이벤트가 발생할 때 업데이트되는
시스템.
제 12 항에 있어서,
바이트 범위 잠금 테이블을 더 포함하고,
상기 바이트 범위 잠금 테이블은 적어도 잠금 식별자 및 핸들 식별자를 사용해서 파일에 대한 잠금을 저장하는
시스템.
분산된 파일 시스템 내에서 REST 기반 동작 및 SFA 기반 동작을 실행하는 컴퓨터 구현식 방법으로서,
SFA 클라이언트로부터 분산된 파일 시스템 내의 파일에 대한 SFA 기반 동작을 수신하는 단계 - 상기 SFA 기반 동작은 상기 SFA 기반 동작의 기회적 잠금을 나타내는 동작 수정자를 가지며, 상기 SFA 기반 동작은 SFA-REST 인터페이스에 기초해서 정의됨 - 와,
상기 SFA 기반 동작의 상기 동작 수정자를 참조하는 것에 기초해서 상기 파일에 대해서 SFA 기반 동작을 처리하는 단계와,
REST 클라이언트로부터 상기 분산된 파일 시스템 내의 상기 파일에 대한 REST 기반 동작을 수신하는 단계 - 상기 REST 기반 동작은 상기 SFA-REST 인터페이스에 기초해서 정의되고, 상기 SFA-REST 인터페이스는 SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함함 - 와,
상기 SFA-REST 인터페이스에 기초해서 상기 REST 기반 동작을 처리하는 단계와,
상기 파일에 대해서 상기 SFA 기반 동작을 실행하는 단계와,
현재 실행 중인 상기 SFA 기반 동작의 상기 동작 수정자를 참조하는 것에 기초해서 상기 파일에 대해서 상기 REST 기반 동작을 실행하는 단계
를 포함하는 방법.
제 21 항에 있어서,
상기 동작 수정자를 참조하는 것에 기초해서 상기 파일에 대해 상기 REST 기반 동작을 실행하는 단계는,
상기 SFA 기반 동작의 상기 동작 수정자와 연관된 기회적 잠금을 식별하는 단계 - 상기 기회적 잠금은 상기 파일의 최신 상태가 상기 SFA 기반 동작과 연관된 상기 SFA 클라이언트 상에 캐싱됨을 나타냄 - 와,
상기 동작 수정자를 참조하는 것에 기초해서 상기 SFA 기반 동작의 기회적 잠금을 파기하도록 결정하는 단계와,
상기 REST 기반 동작이 실행되도록 기회적 잠금 파기 동작을 수행하는 단계
를 더 포함하는,
방법.
제 21 항에 있어서,
상기 SFA 클라이언트는
읽기(R) - 상기 SFA 클라이언트가 로컬 캐시로부터 읽음 - 와,
쓰기(W) - 상기 SFA 클라이언트가 로컬하게 씀 - 와,
핸들(H) - 상기 SFA 클라이언트는 핸들이 닫힐 때 통지를 즉시 전송하지 않음 -
중 하나 이상을 포함하는 상기 기회적 잠금을 획득하고,
상기 읽기(R) 기회적 잠금은 상기 REST 기반 동작이 쓰기 동작일 때 파기되고,
상기 쓰기(W) 기회적 잠금은 상기 REST 기반 동작이 읽기 동작일 때 파기되며,
상기 핸들(H) 기회적 잠금은 상기 REST 기반 동작이 삭제 동작일 때 파기되는,
방법.
제 23 항에 있어서,
상기 핸들(H) 기회적 잠금은 상기 REST 기반 동작이 상기 SFA 기반 동작의 핸들(H)과 공유 위반을 개시할 때 파기되며,
상기 SFA 기반 동작의 액세스 모드 및 공유 모드는 상기 기회적 잠금과는 상이한,
방법.
제 23 항에 있어서,
상기 기회적 잠금 파기 동작은, 하나 이상의 캐싱된 SMB 클라이언트 변경을 플러싱하는 것(flushing), 및 클라이언트 캐시 플러싱이 지정된 요청 타임아웃 동안 딜레이되었다는 동작 실패 통지를 전송하는 것을 포함하는,
방법.
분산된 파일 시스템 내에서 REST 기반 동작 및 SFA 기반 동작을 실행하는 컴퓨터 구현식 방법으로서,
SFA 클라이언트로부터 분산된 파일 시스템 내의 파일에 대한 SFA 기반 동작을 수신하는 단계 - 상기 SFA 기반 동작은 SFA 기반 동작의 액세스 공유 모드를 나타내는 동작 수정자를 갖고, 상기 SFA 기반 동작은 SFA-REST 인터페이스에 기초해서 정의됨 - 와,
상기 SFA-REST 인터페이스에 기초해서 상기 SFA 기반 동작을 처리하는 단계 - 상기 SFA-REST 인터페이스는 SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함함 - 와,
상기 동작 수정자에 기초해서 상기 SFA 기반 동작을 실행하는 단계와,
REST 클라이언트로부터 상기 분산된 파일 시스템 내 상기 파일에 대한 REST 기반 동작을 수신하는 단계와,
상기 SFA-REST 인터페이스에 기초해서 상기 REST 기반 동작을 처리하는 단계와,
현재 실행 중인 상기 SFA 기반 동작의 상기 동작 수정자를 참조하는 것에 기초해서 상기 파일에 대해서 상기 REST 기반 동작을 실행하는 단계
를 포함하는
컴퓨터 구현식 방법.
제 26 항에 있어서,
상기 REST 기반 동작은 파일 생성(Create File) 동작이고,
상기 파일 생성 동작은, 상기 액세스 공유 모드를 나타내는 동작 수정자가 쓰기 공유 모드 및 쓰기/삭제 공유 모드 중 하나를 포함할 때만 실행되는
컴퓨터 구현식 방법.
제 26 항에 있어서,
상기 REST 기반 동작은 파일 얻기(Get File) 동작 또는 범위 나열(List Ranges) 동작이고,
상기 파일 얻기 동작 또는 범위 나열 동작은, 상기 액세스 공유 모드를 나타내는 동작 수정자가 읽기 공유 모드를 포함할 때만 실행되는
컴퓨터 구현식 방법.
제 26 항에 있어서,
상기 REST 기반 동작은 범위 배치(Put Range) 동작, 속성 설정(Set Properties) 동작, 또는 파일 메타데이터 설정(Set File Metadata) 동작이고,
상기 범위 배치 동작, 속성 설정 동작, 또는 파일 메타데이터 설정 동작은 상기 액세스 공유 모드를 나타내는 동작 수정자가 쓰기 공유 모드를 포함할 때만 실행되는
컴퓨터 구현식 방법.
제 26 항에 있어서,
상기 REST 기반 동작은 삭제(Delete) 동작이며,
상기 삭제 동작은 상기 액세스 공유 모드를 나타내는 동작 수정자가 삭제 공유 모드를 포함할 때만 실행되는,
컴퓨터 구현식 방법.
제 26 항에 있어서,
상기 REST 기반 동작은 파일 나열(List Files) 동작, 파일 속성 얻기(Get File Properties) 동작, 또는 파일 메타데이터 얻기(Get File Metadata) 동작이고,
상기 파일 나열 동작, 상기 파일 속성 얻기 동작, 또는 상기 파일 메타데이터 얻기 동작은, 공유 모드 수정자를 갖는 SFA 기반 동작을 기초로 하는 배타적 읽기 액세스에 의해서 파일이 오픈되는 동안 실행되는
컴퓨터 구현식 방법.
제 26 항에 있어서,
상기 액세스 공유 모드를 나타내는 동작 수정자가 수신된 상기 REST 기반 동작을 기초로 상기 파일로의 액세스를 배제할 때 공유 위반을 통신하는 단계를 더 포함하는
컴퓨터 구현식 방법.
분산된 파일 시스템 내에서 REST 기반 동작 및 SFA 기반 동작을 실행하는 컴퓨터 구현식 방법으로서,
SFA-REST 인터페이스에서 파일에 대한 동작을 수신하는 단계와,
상기 파일에 대응하는 동작을 수행하도록 파일 서비스를 액세스하는 단계 - 상기 파일 서비스는 복수의 테이블을 포함하고, 상기 복수의 테이블은 상기 분산된 파일 시스템 내의 파일의 상태를 저장하고 있으며, 상기 SFA-REST 인터페이스는 상기 파일 시스템 내 파일에 액세스하기 위한 SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함함 - 와,
상기 SFA-REST 인터페이스에 기초해서 상기 동작을 처리하는 단계와,
상기 파일 서비스의 파일 서비스 스키마에 기초해서 상기 저장된 파일의 상태를 식별하는 것에 적어도 부분적으로 기초해서 상기 동작을 실행하는 단계
를 포함하는
컴퓨터 구현식 방법.
제 33 항에 있어서,
상기 복수의 테이블은, 상기 파일 서비스 스키마에 정의된 상기 SFA-REST 인터페이스에 대응하는 필드를 포함하며,
상기 복수의 테이블은 SFA 클라이언트와 REST 클라이언트 사이의 동작 인터렉션을 조화시키는(coordinate) 상기 SFA-REST 인터페이스에 정의된 동작에 기초해서 관련되는
컴퓨터 구현식 방법.
제 33 항에 있어서,
상기 파일 서비스 스키마는, 파일 상태를 메모리내 상태로 저장하는 것을 클라우드 컴퓨팅 플랫폼 저장소에 직접 파일 상태를 저장하는 것으로 우회시키는 것을 지원하여, 복수의 SFA 클라이언트와 REST 클라이언트가 상기 파일 서비스 스키마를 이용해 상기 파일 상태를 동시에 액세스하도록 하는
컴퓨터 구현식 방법.
제 33 항에 있어서,
상기 파일 서비스 스키마는 상기 파일 및 디렉토리의 대응하는 명칭에 기초해서 상기 파일 및 상기 디렉토리를 저장하기 위한 계층구조적 테이블을 포함하며,
상기 파일 및 상기 디렉토리는 복수의 파일 식별자를 저장하는 명칭공간 테이블의 조사를 이용해서 취득되는
컴퓨터 구현식 방법.
분산된 파일 시스템 내에서 REST 기반 동작 및 SFA 기반 동작을 실행하는 컴퓨터 구현식 방법으로서,
SFA-REST 인터페이스에서 파일 공유에 대한 동작을 수신하는 단계 - 상기 SFA-REST 인터페이스는 상기 파일 시스템 내 파일에 액세스하기 위한 SFA 프로토콜과 REST 프로토콜의 통합된 기능을 포함함 - 와,
상기 파일 공유에 대한 동작을 수행하기 위해서 공유 테이블에 액세스하는 단계 - 상기 공유 테이블은 상기 SFA-REST 인터페이스의 시맨틱(semantic)을 사용해서 파일 공유 및 상기 파일 공유의 스냅샷을 나타내고, 상기 공유 테이블은 파일 공유에 대한 항목 및 스냅샷에 대한 항목을 포함함 - 와,
상기 SFA-REST 인터페이스에 기초해서 상기 동작을 처리하는 단계와,
상기 공유 테이블에 기초해서 저장된 상기 파일 공유에 대한 파일 공유 상태 혹은 스냅샷 상태를 식별하는 것에 적어도 부분적으로 기초해서 상기 동작을 실행하는 단계
를 포함하는 컴퓨터 구현식 방법.
제 37 항에 있어서,
상기 파일 공유를 스냅샷해서 상기 파일 공유의 콘텐츠를 백업하는 단계를 더 포함하고,
상기 파일 공유는, 쓰기 시 복사 유형 패턴을 사용해서 상기 파일 공유에 기록되는 상기 파일 공유에 대한 변경을 포함해서, 각각의 스냅샷의 이전 버전이 독립적으로 액세스될 수 있게 하며,
상기 파일 공유를 스냅샷하는 것은
2-패스 통지 및 기록 명령어 동작을 포함하는 원자적 스냅샷 동작,
단일 패스 기록 명령어 동작을 포함하는 비-원자적 스냅샷 동작, 또는
복수의 파일 공유를 스냅샷하는 것을 포함하는 교차-공유 원자적 스냅샷
중 하나에 기초하는
컴퓨터 구현식 방법.
제 37 항에 있어서,
상기 파일 공유를 스냅샷하는 것은
2-패스 통지 및 기록 명령어 동작을 포함하는 원자적 스냅샷 동작,
단일 패스 기록 명령어 동작을 포함하는 비-원자적 스냅샷 동작, 또는
복수의 파일 공유를 스냅샷하는 것을 포함하는 교차-공유 원자적 스냅샷
중 하나에 기초하는
컴퓨터 구현식 방법.
제 37 항에 있어서,
상기 파일 공유를 포함하는 상기 공유 테이블을 업데이트하는 단계 - 상기 공유 테이블을 업데이트하는 것은 상기 공유 테이블에 하나의 행(row)을 추가하는 것을 포함하며, 상기 행은 파일 공유의 새 버전과 연관됨 - 와,
상기 파일 공유와 연관된 노드로, 상기 노드에게 상기 파일 공유의 새 버전으로 쓰기를 시작할 것을 지시하는 통지를 통신하는 단계와,
상기 노드가 상기 파일 공유의 새 버전으로 쓰는 중임을 결정하는 단계와,
상기 스냅샷이 성공적으로 완료됐음을 나타내도록 상기 공유 테이블을 업데이트하는 단계
를 더 포함하는
컴퓨터 구현식 방법.