KR20200079729A - 데이터 일관성을 위한 버퍼 캐시 및 방법 - Google Patents

Abstract

파일 시스템에 연관되며, 보다 특정하게는 데이터 일관성을 보장하는 버퍼 캐시 및 방법이 제공된다. 일 실시예에 따른 버퍼 캐시는 제1 데이터가 캐싱되는 제1 영역과 상기 제1 데이터가 생성 시 상기 제1 데이터에 부여되는 고유값을 포함하는 제2 데이터가 캐싱되는 제2 영역을 포함하는 비휘발성 메모리, 및 응용 프로그램으로부터 상기 제1 데이터에 대한 연산을 요청 받는 경우, 상기 고유값에 기초하여 상기 제1 데이터가 캐싱되는 위치를 결정하는 컨트롤러를 포함할 수 있다.

Description

데이터 일관성을 위한 버퍼 캐시 및 방법{COMPUTING SYSTEM AND METHOD FOR DATA CONSISTENCY}

파일 시스템에 연관되며, 보다 특정하게는 데이터 일관성을 보장하는 버퍼 캐시 및 방법이 제공된다.

파일 시스템에 이용되는 휘발성 램(RAM: Random Access Memory)은 시스템의 붕괴 시 데이터를 소실한다. 따라서, 데이터 갱신에 이용되는 연산 처리의 일관성이나 원자성(atomicity)의 보장이 큰 이슈가 되지 않는다.

반면, 비휘발성 메모리(NVRAM: Non-volatile Random Access Memory)를 데이터 스토리지의 용도로 사용하는 경우에는 시스템 붕괴 시에도 데이터가 소실되지 않는데, 소실되지 않은 데이터의 재사용을 위해서는 상기 데이터의 일관성 또는 원자성이 보장되어야 한다.

이를 테면 중앙처리장치(CPU: Central Processing Unit)의 캐시 플러시 호출에 대응하여 비휘발성 메모리에 저장되는 데이터의 일관성이 유지될 필요가 존재한다. 종래에는 비휘발성 메모리 내의 데이터 구조를 B+ 트리(B+ tree) 구조로서 구현하고, 로깅 영역(logging area)에 새롭게 저장될 데이터를 미리 저장하고 캐시 플러시 호출에 대한 연산을 수행하는 로깅 방법이나 엔트리(entry)에 포함되는 데이터를 복사하여 업데이트한 이후에 포인트를 바꾸는 방식의 쉐도잉(shadowing) 방법이 그 해결 방안으로 이용되었다. 다만, B+ 트리 구조는 엔트리 내의 키(key)와 포인터의 크기가 원자성이 유지되는 8 byte를 초과한다는 점에서 갑작스러운 크래쉬(crash)가 발생하는 경우에 데이터의 일관성이 깨지게 될 가능성이 존재하여 그 새로운 해결 방안이 필요한 실정이다.

일 실시예에 따른 버퍼 캐시는 제1 데이터가 캐싱되는 제1 영역과 상기 제1 데이터가 생성 시 상기 제1 데이터에 부여되는 고유값을 포함하는 제2 데이터가 캐싱되는 제2 영역을 포함하는 비휘발성 메모리; 및 응용 프로그램으로부터 상기 제1 데이터에 대한 연산을 요청 받는 경우, 상기 고유값에 기초하여 상기 제1 데이터가 캐싱되는 위치를 결정하는 컨트롤러를 포함한다.

상기 제1 영역은 2-way 구조를 갖을 수 있다.

상기 제1 영역은 청크 단위로 구성되고, 각 청크들은 상기 2-way 구조에 따라 청크 쌍으로 이루어진 슬롯을 구성할 수 있다.

상기 컨트롤러는 상기 응용 프로그램으로부터 상기 제1 데이터에 대한 연산을 요청 받는 경우, 상기 고유값과 상기 제1 영역을 구성하는 청크들의 수에 기초하여 상기 제1 데이터가 캐싱되는 상기 슬롯의 인덱스를 결정할 수 있다.

상기 제2 데이터는 상기 제1 데이터의 상태를 나타내는 비트를 더 포함할 수 있다.

상기 비트는 상기 제1 데이터의 유효 여부를 지칭하는 제1 비트와 슬롯의 두 청크에 있어서 캐싱의 선후 관계를 지칭하는 제2 비트를 포함할 수 있다.

상기 제1 비트는 상기 제1 데이터에 대한 연산이 완료된 이후에 변경될 수 있다.

상기 비트는 상기 제1 데이터의 더티 상태(dirty state)를 지칭하는 제3 비트를 더 포함할 수 있다.

상기 컨트롤러는 상기 제1 데이터가 유효한 경우 상기 제1 비트는 제1 논리값을 갖고, 상기 슬롯의 상기 두 청크 중 나중에 캐싱된 청크의 경우 상기 제2 비트는 제1 논리값을 갖도록 제어할 수 있다.

상기 컨트롤러는 상기 응용 프로그램으로부터 상기 제1 데이터에 대한 업데이트(update) 연산을 요청 받는 경우, 상기 제1 데이터를 상기 제1 데이터가 캐싱된 청크의 토클(toggle) 청크에 복사할 수 있다.

상기 컨트롤러는 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 제1 데이터를 백그라운드 프로세스를 통해 플러시(flush)하고, 스토리지로부터 응답을 기다리지 않고 다음 연산을 진행시킬 수 있다.

상기 컨트롤러는 상기 제1 데이터가 캐싱된 청크에 새로운 파일 데이터에 대한 연산을 요청 받는 경우, 상기 제1 데이터의 상기 쓰기 연산이 완료될 때까지 상기 새로운 파일 데이터에 대한 연산을 계류(pending)시킬 수 있다.

상기 버퍼 캐시는 가상 파일 시스템 레이어(Virtual file system layer)상에 존재할 수 있다.

상기 컨트롤러는 상기 제1 데이터의 크기가 단위 청크의 크기보다 큰 경우, 상기 제1 데이터가 캐싱되는 상기 슬롯의 인덱스 영역을 결정하고, 상기 인덱스 영역에 기초하여, 상기 제1 데이터를 복수개의 청크에 캐싱할 수 있다.

상기 컨트롤러는 상기 제1 데이터의 크기가 단위 청크의 크기보다 크고, 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 복수개의 청크 전부에 상기 제1 데이터의 상기 쓰기 연산이 완료되면 상기 제1 데이터를 백그라운드 프로세스를 통해 상기 제1 데이터를 플러시(flush)할 수 있다.

상기 비트는 상기 제1 데이터의 크기가 단위 청크의 크기보다 크고, 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 제1 데이터의 상기 쓰기 연산의 완료 여부를 지칭하는 제4 비트를 포함할 수 있다.

복수개의 청크 중 마지막 청크에 상기 제1 데이터의 상기 쓰기 연산이 완료되는 경우, 상기 마지막 청크의 상기 제4 비트는 제1 논리값을 갖을 수 있다.

상기 컨트롤러는 상기 복수개의 청크 중 첫번째 청크의 오프셋 비트를 결정하고, 복수개의 청크 중 마지막 청크에 상기 제1 데이터의 상기 쓰기 연산이 완료되는 경우, 상기 오프셋 비트를 초기화 할 수 있다.

상기 컨트롤러는 상기 오프셋 비트를 초기화한 이후에, 제4 비트를 제2 논리값으로 바꿔줄 수 있다.

일 실시예에 따른 버퍼 캐시 동작 방법은 응용 프로그램으로부터 제1 데이터에 대한 연산을 요청 받는 단계; 상기 제1 데이터에 부여되는 고유값에 기초하여 상기 제1 데이터가 캐싱되는 위치를 결정하는 단계를 포함하고, 상기 제1 데이터는 비휘발성 메모리의 제1 영역에 캐싱되고, 상기 고유값을 포함하는 제2 데이터는 상기 비휘발성 메모리의 제2 영역에 캐싱된다.

상기 제1 데이터가 캐싱되는 위치를 결정하는 단계는 상기 응용 프로그램으로부터 상기 제1 데이터에 대한 연산을 요청 받는 경우, 상기 고유값과 상기 제1 영역을 구성하는 청크들의 수에 기초하여 상기 제1 데이터가 캐싱되는 상기 슬롯의 인덱스를 결정하는 단계를 포함할 수 있다.

일 실시예에 따른 버퍼 캐시의 동작 방법은 상기 제1 데이터가 유효한 경우 상기 제1 비트는 제1 논리값을 갖고, 상기 슬롯의 상기 두 청크 중 나중에 캐싱된 청크의 경우 상기 제2 비트는 제1 논리값을 갖도록 제어하는 단계를 더 포함할 수 있다.

일 실시예에 따른 버퍼 캐시의 동작 방법은 응용 프로그램으로부터 상기 제1 데이터에 대한 업데이트(update) 연산을 요청 받는 경우, 상기 제1 데이터를 상기 제1 데이터가 캐싱된 청크의 토클(toggle) 청크에 복사하는 단계를 더 포함할 수 있다.

일 실시예에 따른 버퍼 캐시의 동작 방법은 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 제1 데이터를 백그라운드 프로세스를 통해 플러시(flush)하고, 스토리지로부터 응답을 기다리지 않고 다음 연산을 진행시키는 단계를 더 포함할 수 있다.

일 실시예에 따른 버퍼 캐시의 동작 방법은 상기 제1 데이터가 캐싱된 청크에 새로운 파일 데이터에 대한 연산을 요청 받는 경우, 상기 제1 데이터의 상기 쓰기 연산이 완료될 때까지 상기 새로운 파일 데이터에 대한 연산을 계류(pending)시키는 단계를 더 포함할 수 있다.

상기 제1 데이터가 캐싱되는 위치를 결정하는 단계는 상기 제1 데이터의 크기가 단위 청크의 크기보다 큰 경우, 상기 제1 데이터가 캐싱되는 상기 슬롯의 인덱스 영역을 결정하는 단계를 포함하고, 일 실시예에 따른 버퍼 캐시의 동작 방법은 상기 인덱스 영역에 기초하여, 상기 제1 데이터를 복수개의 청크에 캐싱하는 단계를 더 포함할 수 있다.

상기 제1 데이터를 복수개의 청크에 캐싱하는 단계는 상기 제1 데이터의 크기가 단위 청크의 크기보다 크고, 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 복수개의 청크 전부에 상기 제1 데이터의 상기 쓰기 연산이 완료되면 상기 제1 데이터를 백그라운드 프로세스를 통해 상기 제1 데이터를 플러시(flush)하는 단계를 포함할 수 있다.

상기 비트는 상기 제1 데이터의 크기가 단위 청크의 크기보다 크고, 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 제1 데이터의 상기 쓰기 연산의 완료 여부를 지칭하는 제4 비트를 포함할 수 있다.

복수개의 청크 중 마지막 청크에 상기 제1 데이터의 상기 쓰기 연산이 완료되는 경우, 상기 마지막 청크의 상기 제4 비트는 제1 논리값을 갖을 수 있다.

상기 제1 데이터를 복수개의 청크에 캐싱하는 단계는 상기 복수개의 청크 중 첫번째 청크의 오프셋 비트를 결정하는 단계; 및 복수개의 청크 중 마지막 청크에 상기 제1 데이터의 상기 쓰기 연산이 완료되는 경우, 상기 오프셋 비트를 초기화 해주는 단계를 포함할 수 있다.

일 실시예에 따른 버퍼 캐시의 동작 방법은 상기 오프셋 비트를 초기화한 이후에, 제4 비트를 제2 논리값으로 바꿔주는 단계를 더 포함할 수 있다.

도 1은 일 실시예에 따른 영속적 버퍼 캐시(Persistent Buffer Cache: PBC)를 사용한 파일 시스템을 도시한 도면.
도 2는 일 실시예에 따른 영속적 버퍼 캐시의 구조를 도시한 도면.
도 3은 일 실시예에 따른 인덱싱 된 슬롯에 있는 청크 쌍의 상태를 도시한 도면.
도 4는 일 실시예에 따른 청크와 태그를 이용하여 연산을 처리하는 방법을 케이스별로 도시한 도면.
도 5는 일 실시예에 따른 시스템 장애 발생 시 영속적 버퍼 캐시의 내용이 오류로부터 항상 복구 될 수 있음을 설명하기 위한 도면.
도 6은 일 실시예에 따른 백그라운드 플러시 기법을 설명하기 위한 도면.
도 7은 일 실시예에 따른 제1 데이터의 크기가 단위 청크의 크기보다 큰 경우의 취급을 설명하기 위한 도면.
도 8은 일 실시예에 따른 영속적 버퍼 캐시의 동작 방법을 도시한 도면.

본 명세서에 개시되어 있는 본 발명의 개념에 따른 실시예들에 대해서 특정한 구조적 또는 기능적 설명들은 단지 본 발명의 개념에 따른 실시예들을 설명하기 위한 목적으로 예시된 것으로서, 본 발명의 개념에 따른 실시예들은 다양한 형태로 실시될 수 있으며 본 명세서에 설명된 실시예들에 한정되지 않는다.

본 발명의 개념에 따른 실시예들은 다양한 변경들을 가할 수 있고 여러 가지 형태들을 가질 수 있으므로 실시예들을 도면에 예시하고 본 명세서에 상세하게 설명하고자 한다. 그러나, 이는 본 발명의 개념에 따른 실시예들을 특정한 개시형태들에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 변경, 균등물, 또는 대체물을 포함한다.

제1 또는 제2 등의 용어를 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만, 예를 들어 본 발명의 개념에 따른 권리 범위로부터 이탈되지 않은 채, 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소는 제1 구성요소로도 명명될 수 있다.

어떤 구성요소가 다른 구성요소에 “연결되어” 있다거나 “접속되어” 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 “직접 연결되어” 있다거나 “직접 접속되어” 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다. 구성요소들 간의 관계를 설명하는 표현들, 예를 들어 “~사이에”와 “바로~사이에” 또는 “~에 직접 이웃하는” 등도 마찬가지로 해석되어야 한다.

본 명세서에서 사용한 용어는 단지 특정한 실시예들을 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 명세서에서, “포함하다” 또는 “가지다” 등의 용어는 설시된 특징, 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것이 존재함으로 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가진다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥상 가지는 의미와 일치하는 의미를 갖는 것으로 해석되어야 하며, 본 명세서에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

이하, 실시예들을 첨부된 도면을 참조하여 상세하게 설명한다. 각 도면에 제시된 동일한 참조 부호는 동일한 부재를 나타낸다.

도 1은 일 실시예에 따른 영속적 버퍼 캐시(Persistent Buffer Cache: PBC)를 사용한 파일 시스템을 도시한 도면이다.

도 1을 참조하면, 일 실시예에 따른 파일 시스템은 영속적 버퍼 캐시를 사용할 수 있다.

컴퓨터 시스템 내의 메모리 계층과 스토리지 계층의 속도 차이를 완충하기 위해 버퍼 캐싱 기법이 널리 사용되고 있다. 스토리지에서 데이터를 읽는 속도는 메모리에서 데이터를 읽는 속도보다 느리기 때문에, 스토리지의 동일한 영역을 짧은 시간 동안 반복해서 계속 읽는 일이 빈번할 경우 컴퓨터 시스템의 속도가 느려질 수 있다. 스토리지로부터 한번 읽어들인 정보를 메모리에 상당시간 보관한다면, 첫번째로 읽을 때만 시간이 좀 걸릴 뿐 속도가 전반적으로 빨라질 수 있고, 이런 목적으로 쓰이는 메모리가 버퍼 캐쉬(buffer cache)일 수 있다. 이미 버퍼 캐시에 존재하는 데이터에 대해 읽기 또는 쓰기 연산이 다시 발생한 경우 해당 데이터를 버퍼 캐시에서 직접 서비스하여 스토리지로 접근하는 횟수를 줄일 수 있다.

파일 시스템 버퍼 캐시는 느린 스토리지 접근 횟수를 줄여 파일 입출력 성능 향상에 크게 기여할 수 있지만, 일반적인 버퍼 캐시는 휘발성 메모리로 구형되기 때문에, 버퍼 캐시에서 수정된 데이터를 스토리지 상의 파일 시스템에 오랫동안 반영하지 않을 경우 크래쉬 발생 시 최신 데이터가 유실되거나 데이터의 일관성이 깨어지는 문제가 발생할 수 있다. 크래쉬는 시스템 붕괴나 비정상 종료와 같은 시스템 장애를 포함할 수 있다.

이를 방지하기 위해 수정된 더티 데이터(dirty data)를 주기적으로 스토리지에 반영하는 멀티 버저닝(Multi-versioning)이 사용될 수 있다. 더티 데이터(dirty data)는 버퍼 캐시에만 업데이트(update)되고 스토리지에는 업데이트 안되어 있는 데이터일 수 있다. 멀티 버저닝의 일 예로 저널링 기법이 있을 수 있다.

저널링 기법을 통해 데이터를 별도의 스토리지 영역에 기록한 후 추후 원래 위치에 반영할 수 있다. 저널링 기법은 파일시스템이 갱신될 때마다 해당 사실을 주기적으로 특정 저널공간에 미리 기록한 후에 갱신된 내용을 실제 파일시스템에 반영함으로써 파일시스템 일관성과 데이터에 대한 높은 안정성을 보장하는 기법일 수 있다.

저널링 기법은 파일 데이터를 스토리지와 항상 동기화를 해야하므로 오버헤드(overhead)가 증가될 수 있다. 예를 들어, 저널링 기법은 추가적인 기록과정으로 인한 파일시스템의 성능 저하를 동반하며, 저널공간이 늘어남에 따라 시스템 붕괴 이후의 복구시간이 길어진다는 한계가 있을 수 있다. 저널링 기법을 사용할 경우 좀 더 높은 신뢰성을 유지할 수 있으나, 많은 양의 추가적인 쓰기를 발생시키므로, 일반적으로 메타데이터에 대해서만 저널링 기법을 사용하고 파일 데이터에 대해서는 플러시를 적용할 수 있다. 저널링 기법은 캐시 공간이 부족하지 않은 상황에서 상당 부분의 쓰기 연산이 디스크 입출력으로 이어지게 하므로 버퍼 캐시의 효과를 크게 떨어뜨릴 수 있다.

일 실시예에 따른 파일 시스템은 비휘발성 메모리로 버퍼 캐시를 구현한 영속적 버퍼 캐시를 사용하여, 비정상 종료(system failure)가 발생하더라도 파일 시스템의 일관성(consistency)을 유지할 수 있다. 파일 시스템의 일관성이란, 버퍼 캐시 데이터와 스토리지 데이터 사이의 일관성을 의미할 수 있다. 데이터는 메타 데이터 뿐만 아니라 파일 데이터도 포함할 수 있다.

영속적 버퍼 캐시는 가상 파일 시스템 레이어(Virtual file system layer)상에 존재할 수 있다. 가상 파일 시스템은 실제 파일 시스템 위의 추상 계층으로, 클라이언트 응용 프로그램이 여러 파일 시스템에 같은 방법으로 접근할 수 있게 할 수 있다. 예를 들어, 가상 파일 시스템을 사용하면 클라이언트 응용 프로그램은 로컬인 기억 장치에도 네트워크 위의 기억 장치에 직접적으로 접근할 수 있기 때문에 로컬과 네트워크의 차이를 느끼지 못할 수 있다. 영속적 버퍼 캐시는 가상 파일 시스템 레이어상에 존재하기 때문에, 사용자로부터 넘어오는 데이터가 깊은 스택(stack)을 타지 않을 수 있다. 데이터가 깊은 스택(stack)을 타지 않기 때문에, 저장하고자 하는 데이터가 영속성을 가지기까지의 경로(critical path)가 짧고, 이로 인하여 기존의 휘발성 메모리로 구현된 버퍼 캐시에 비해 고성능을 가질 수 있다.

일 실시예에 따른 영속적 버퍼 캐시의 동작 방법을 설명하기에 앞서, 일반적인 버퍼 캐시의 동작 방법을 간략하게 설명한다.

버퍼 캐시의 크기에는 한도가 있을 수 있다. 버퍼 캐시는 필요한 모든 데이터를 담아둘 수 있을 정도로 크지 않기 때문에 버퍼 캐시가 다 차게 되면 오랫동안 쓰이지 않은 데이터는 버려지며 그 빈 공간을 새로운 데이터를 메꿀 수 있다. 버퍼 캐시는 그 한도내에서 최고의 효율을 얻기 위해 여러 알고리즘을 사용할 수 있다. 예를 들어, LRU 알고리즘(Least Recently Used Algorism)은 가장 오랫동안 사용하지 않은 데이터를 제거하는 알고리즘일 수 있다. LRU 알고리즘의 기본 가설은 가장 오랫동안 사용하지 않았던 데이터는 앞으로도 사용할 확률이 적다는 것일 수 있다.

기존 버퍼 캐시의 관리 체계는 데이터를 즉시 영속적으로 보장해야하는 상황에서는 적합하지 않을 수 있다. 예를 들어, 기존의 버퍼 캐시는 스토리지와 버퍼 캐시로 사용하고 있는 메모리의 지연 차이에 의한 불일치를 정교하게 관리하기 때문에, 최적의 희생 공간을 찾는 것에 비용을 많이 들 수 있다.

비휘발성 메모리는 접근 및 반응 속도가 짧기 때문에, 비휘발성 메모리를 버퍼 캐시로 사용하는 영속적 버퍼 캐시에서는 기존 버퍼 캐시의 메커니즘은 낭비가 될 수 있다. 이 상황은 중앙처리장치(CPU) 캐시에서 정교한 희생 공간 선택 메커니즘이 전체적인 성능에 악영향을 미치는 것과 유사할 수 있다. 일 실시예에 따른 영속적 버퍼 캐시는 단순한 교체 알고리즘을 이용하여 배치에 의한 오버헤드를 줄일 수 있음과 동시에 일관성을 보장할 수 있다. 영속적 버퍼 캐시의 동작 방법은 아래에서 도 2 내지 도 7을 참조하여 상세히 설명된다.

도 2는 일 실시예에 따른 영속적 버퍼 캐시의 구조를 도시한 도면이다.

도 2를 참조하면, 일 실시예에 따른 영속적 버퍼 캐시(200)는 비휘발성 메모리(210)와 컨트롤러(220)를 포함한다.

일 실시예에서 설명되는 비휘발성 메모리(210)의 종류에는 이를 테면, PCRAM(Phase change RAM), MRAM(Magnetroresistive RAM), FeRAM(Ferroelectric RAM)등이 존재할 수 있다. 다만, 이러한 비휘발성 메모리(210)의 종류 또한 본 발명의 일부 실시예에 불과하며, 본 발명이 이러한 실시예에 의해 제한적으로 해석되어서는 안될 것이다.

비휘발성 메모리(210)는 제1 데이터가 캐싱되는 제1 영역과 제1 데이터가 생성 시 제1 데이터에 부여되는 고유값을 포함하는 제2 데이터가 캐싱되는 제2 영역을 포함할 수 있다. 본 명세서의 제1 데이터는 파일 데이터일 수 있고, 제2 데이터는 메타 데이터일 수 있다. 메타 데이터는 디스크에 구조적으로 존재하는 파일 데이터의 관리를 위한 구조 관리용 2차적 데이터로서, 파일의 생성, 삭제, 디렉토리의 생성과 삭제, 파일 크기의 증가 감소 등에 따라 생성되는 데이터일 수 있다. 예를 들어, 메타 데이터는 파일 시스템에 반영되는 변경 사항들에 관한 정보들을 포함하는 데이터일 수 있다. 캐싱은 데이터를 스토리지가 아닌 메모리에 일시적으로 저장하는 프로세스를 의미할 수 있다.

비휘발성 메모리(210)는 제1 영역과 제2 영역을 포함할 수 있다. 본 명세서의 제1 영역은 청크 영역, 제2 영역은 태그 영역을 포함할 수 있다. 청크 영역은 청크 단위로 구성될 수 있다. 예를 들어, 청크 영역에는 총 N개의 연속된 청크가 존재할 수 있고, 해당 청크들은 스토리지로의 로드/저장의 단위가 될 수 있다. 청크 영역은 2-way 구조를 갖을 수 있다. 각 청크들은 2-way 구조에 따라 청크 쌍으로 이루어진 슬롯을 구성할 수 있고, 이는 중앙처리장치 캐시에서 사용되는 2-way 연관 캐시 설계와 유사할 수 있다.

태그 영역은 태그 단위로 구성될 수 있고, 태그 영역의 청크와 슬롯은 일대일 대응 관계를 가질 수 있다. N개의 태그들은 각각 하나의 청크와 연관되어 관리 될 수 있다. 태그는 해당 청크에 들어있는 데이터가 어떤 파일의 데이터인지 구분할 수 있는 고유값과 청크의 상태를 나타내는 비트로 구성될 수 있다. 이하, 고유값은 키 값이라고 지칭될 수 있다. 키 값은 파일 생성 시 영속적 버퍼 캐시(200)가 부여한 번호로서 파일 마다 연결된 고유 번호일 수 있다. 키 값은 영속적 버퍼 캐시(200)가 관리하는 전역적인 값이며, 초기 값 0부터 모든 파일이 생성 될 때, 파일들끼리의 충돌을 줄이기 위해 정해진 보폭 값 만큼 증분된 값을 부여 할 수 있다. 생성할 수 있는 파일의 개수는 키 값을 담고 있는 변수의 타입에 제한 받을 수 있다. 예를 들어, 현재 구현에서 사용하고 있는 변수는 unsigned long이기 때문에, 이 타입이 담을 수 있는 값까지 키로 부여할 수 있다.

파일에 접근하는 상황에서는, 파일 데이터를 영속적 버퍼 캐시(200)로부터 가져와야 할 수 있다. 기존의 버퍼 캐시에서는, 데이터는 캐시에서 운영하는 대체 알고리즘에 의해 결정되는 위치에 상주할 수 있었다. 실제로 배치된 블록들은 교체 알고리즘에 의해 다시 로드 될 때 마다 위치가 변경될 수 있었다. 대조적으로, 영속적 버퍼 캐시(200)의 경우 교체를 위한 인덱싱 체계를 정적으로 고정시키는 단순한 교체 알고리즘을 사용할 수 있다. 컨트롤러(220)에서 교체 알고리즘을 수행할 수 있다.

컨트롤러(220)는 응용 프로그램으로부터 제1 데이터에 대한 연산을 요청 받는 경우, 고유값에 기초하여 제1 데이터가 캐싱되는 위치를 결정할 수 있다. 구체적으로, 컨트롤러(220)는 응용 프로그램으로부터 제1 데이터에 대한 연산을 요청 받는 경우, 고유값과 제1 영역을 구성하는 청크들의 수에 기초하여 제1 데이터가 캐싱되는 슬롯의 인덱스를 결정할 수 있다.

예를 들어, 슬롯 인덱스는 수학식 1과 같이 계산될 수 있다.

a MOD b는 a와 b를 나누었을 때의 나머지를 의미하고, N은 영속적 버퍼 캐시(200)에서의 청크의 개수일 수 있다. 수학식 1을 통해 모든 파일 데이터는 영속적 버퍼 캐시(200)내에서 목적지가 결정되어 있으므로, 배치에 의한 오버헤드가 거의 없을 수 있다. 예를 들어, 청크의 개수가 20이고, 키 값이 5인 데이터의 경우, 수학식 1에 의해 5번 슬롯으로 캐싱 위치가 정해질 수 있다. 청크의 개수가 20이고, 키 값이 7인 데이터의 경우, 7번 슬롯으로 캐싱 위치가 정해질 수 있다. 청크의 개수가 20이고, 키 값이 15인 데이터의 경우, 5번 슬롯으로 캐싱 위치가 정해질 수 있다.

또한, 수학식 1을 통해 모든 파일 데이터는 영속적 버퍼 캐시(200)내에서 목적지가 결정되어 있으므로, 영속적 버퍼 캐시(200)가 다 차게 되어 기존 파일 데이터를 새로운 파일 데이터로 교체할 경우, 교체할 기존 파일 데이터를 찾기 위한 교체 알고리즘도 필요 없을 수 있다. 예를 들어, 5번 슬롯에 키 값이 5, 15인 파일 데이터가 캐싱되었을 때, 키 값이 25인 파일 데이터를 로드하는 경우, 키 값이 25인 파일 데이터는 수학식 1에 의해 5번 슬롯으로 목적지가 결정되어 있기 때문에, 기존의 LRU 알고리즘과 같은 복잡한 교체 알고리즘이 필요 없을 수 있다.

영속적 버퍼 캐시(200)의 청크 교체 인덱싱 기법은 기존 LRU 알고리즘과 같은 교체 인덱싱 기법들에 비해 단점이 있을 수 있다. 예를 들어, 영속적 버퍼 캐시(200)의 청크 교체 인덱싱 기법에 따르면, 자주 사용되는 파일 데이터와 자주 사용되지 않는 파일 데이터의 구별없이 무조건 순차적으로 교체되기 때문에 청크에 원하는 데이터가 없는 캐시 미스의 상황이 발생 자주 발생할 수 있고, 이로 인하여 잦은 플러시(flush)가 발생할 수 있다. 플러시는 데이터를 버퍼 캐시에서 스토리지로 내보내는 프로세스를 의미할 수 있다. 영속적 버퍼 캐시(200)의 청크 교체 인덱싱 기법에 따를 경우, 잦은 플러시로 인해 오버헤드가 증가할 수 있다.

일견하기에, 영속적 버퍼 캐시(200)의 청크 교체 인덱싱 기법은 잦은 플러시(flush)가 발생할 수 있으나, 대기 시간이 짧아진 최근의 저장 장치의 출현으로 기존의 I/O 경로가 오히려 시스템 전체 성능에 해가 될 수 있다. 대기 시간이 매우 짧은 비휘발성 메모리를 사용할 경우, 기본적으로 I/O 바운드 응용 프로그램들이 중앙처리장치 바운드 응용 프로그램으로 간주 될 수 있으며, 뿐만 아니라, 실행 크리티컬 경로(critical path)에서의 약간의 명령 수의 증가가 계속해서 누적되어 시스템 성능에 부적적인 영향을 미칠 수 있다. 비휘발성 메모리와 같은 대기 시간이 매우 짧은 매체에서는 복잡한 대체 알고리즘 대신, 단순한 영속적 버퍼 캐시(200)의 청크 교체 인덱싱 기법이 효과적일 수 있다. 또한, 영속적 버퍼 캐시(200)는 잦은 플러시(flush) 발생을 보상하기 위한 방법을 아래에서 상세히 설명한다.

도 3은 일 실시예에 따른 인덱싱 된 슬롯에 있는 청크 쌍의 상태를 도시한 도면이다.

태그는 해당 청크에 들어있는 데이터가 어떤 파일의 데이터인지 구분할 수 있는 고유값과 청크의 상태를 나타내는 비트로 구성될 수 있다. 청크의 상태를 나타내는 비트는 파일 데이터의 유효 여부를 지칭하는 제1 비트와 슬롯의 두 청크에 있어서 캐싱의 선후 관계를 지칭하는 제2 비트를 포함할 수 있다. 파일 데이터가 유효한 경우 제1 비트는 제1 논리값을 갖고, 슬롯의 두 청크 중 나중에 캐싱된 청크의 경우 제2 비트는 제1 논리값을 가질 수 있다. 예를 들어, 파일 데이터가 유효한 경우 '1' 비트를, 유효하지 않은 경우 '0' 비트을 가질 수 있다. 또한, 슬롯의 두 청크 중 나중에 캐싱된 청크의 경우 '1' 비트를, 먼저 캐싱된 청크의 경우 '0' 비트를 가질 수 있다.

도 3을 참조하면, 일 실시예에 따른 청크 쌍은 세가지 상태 중 하나일 수 있다.

상태(310)는 S[C(0, 0), C(0, 0)]으로 나타낼 수 있고, 이러한 경우 어느 청크도 유효하지 않기 때문에 슬롯이 비어 있음을 알 수 있다. 해당 슬롯의 모든 청크에 데이터가 비어 있거나 유효하지 않을 수 있다.

상태(320)는 S[C(1, 1), C(0, 0)]으로 나타낼 수 있고, 이러한 경우 하나의 청크만 유효한 데이터를 가짐을 알 수 있다.

상태(330)는 S[C(1, 1), C(1, 0)]으로 나타낼 수 있고, 이러한 경우 두 청크 모두 유효한 데이터를 가지고, 파일 데이터 'L'이 캐싱된 청크가 나중에 캐싱된 청크임을 알 수 있다.

비트는 제1 데이터의 더티 상태(dirty state)를 지칭하는 제3 비트를 더 포함할 수 있다. 제1 데이터가 유효한 경우 제1 비트는 제1 논리값을 갖고, 슬롯의 두 청크 중 나중에 캐싱된 청크의 경우 제2 비트는 제1 논리값을 갖을 수 있다.

도 4는 일 실시예에 따른 청크와 태그를 이용하여 연산을 처리하는 방법을 케이스별로 도시한 도면이다.

도 4를 참조하면, 일 실시예에 따른 연산을 처리하는 방법을 6개의 케이스로 나누어 설명할 수 있다.

케이스(410)는 초기 상태가 슬롯의 두 청크가 모두 유효하지 않은 경우([C(0, 0), C(0, 0)])일 수 있다. 이러한 경우, 슬롯에서 어떤 청크든 사용할 수 있다. K에 대한 업데이트 쓰기 연산 요청 시(Write(K’)), 온전한 K에 대한 파일 데이터가 스토리지에 존재한다면, 그 데이터가 먼저 영속적 버퍼 캐시(200)로 로드 될 수 있다. 그 후, K'에 대한 쓰기가 이루어 지고, clush, sfence 명령들을 통해 영속적 버퍼 캐시(200)로의 데이터 쓰기에 대한 통제(ordering) 및 내구성을 보장할 수 있다. 다음으로, 태그 C(0, 0)이 C(1, 1)로 수정되고, 이렇게 모두 설정 된 후에 요청이 완료될 수 있다. 영속적 버퍼 캐시(200)로의 쓰기에 대한 영속성을 보장하기 위해서는 clush 및 sfence를 이용한 기법이 쓰기가 발생될 때마다 수행되어야 할 수 있다. 이하 중복되는 내용의 설명은 생략한다. 또한, 추가적인 언급 없이 태그의 플래그 비트들을 수정하는 것은 원자적(atomic)으로 수행된다는 것을 내포한다. 원자적(atomic)으로 수행된다는 것은 실제로 모든 동작이 완료된 이후에 제1 비트를 변경한다는 것을 의미하는 것으로, 도 5를 참조하여 상세히 설명된다.

케이스(420)와 케이스(430)는 초기 상태가 하나의 청크가 유효한 객체 K를 가지고 있고, 다른 청크는 유효하지 않은 경우(S[C(1, 1), C(0, 0)])일 수 있다. 이 상황에서는 두가지의 경우를 고려할 수 있다. 케이스(420)는 K가 수정되는 경우이고, 케이스(430)는 새로운 객체가 쓰여지는 경우일 수 있다.

케이스(420)의 경우, K가 업데이트 될 때(Write(K’)), K는 여전히 유효하지만, 가장 최근 청크를 나타내는 제2 비트를 클리어 해줄 수 있다(C(1, 1) -> C(1, 0)). 제2 비트를 클리어한 후에, K가 상태 C(0, 0)인 토글(toggle) 청크에 복사되고, 업데이트 요청이 해당 청크에 반영될 수 있다. 토글 청크는 같은 슬롯에 있는 자신이 아닌 청크를 의미할 수 있다. 태그의 상태는 C(0, 0)에서 C(1, 1)로 수정되고, 마지막으로, 원래의 청크의 상태 C(1, 0)은 C(0, 0)로 수정될 수 있다. 이와 같은 일련의 절차가 마무리 되면, Write(K’) 요청이 완료되었다고 응용프로그램으로 수신할 수 있다. 유효한 데이터 K에 대해 업데이트 요청 Write(K’)가 발생될 때, 유효한 K를 토글 청크에 옮긴 다음 그 곳에 K’를 덮어쓰기 할 수 있다. 해당 업데이트 요청이 K를 포함하는 부분 쓰기일 수 있는데, 이 경우 토글 청크에 복사하지 않고 쓰게 되면, 쓰기 실패 시 회복 불가능한 상태가 될 수 있기 때문이다. 케이스(420)의 경우 2-way 청크 구조를 사용하기 때문에, K가 업데이트 될 때 토글 청크가 존재하여 토클 청크에 복사할 수 있지만, 1-way 청크를 사용하는 경우 토글 청크가 없기 때문에 K를 플러시하고 새로 K'를 업데이트해야 할 수 있다. 케이스(420)와 같이 토글 청크가 비어있고 파일 데이터를 업데이트할 때는 2-way 청크 구조를 이용하여 플러시를 줄여 영속적 버퍼 캐시(200)의 청크 교체 인덱싱 기법을 사용함에 따라 떨어진 효율을 보상할 수 있다.

케이스(430)의 경우는 객체 L’이 객체 K가 존재하는 청크가 포함된 슬롯에 기록되는 경우일 수 있다. K가 존재하는 청크는 더 이상 최근에 접근된 청크가 아니게 되므로, C(1, 1)은 C(1, 0)으로 먼저 수정될 수 있다. L’ 객체에 대한 쓰기가 덮어 쓰기인 경우, 스토리지로 부터 L을 먼저 로드한 후, 해당 청크에 L’ 객체가 덮어 쓰여질 수 있다. 이 때의 상태는 C(0, 0)이며, 덮어쓰기가 완료 된 후, C(0, 0)은 C(1, 1)로 수정될 수 있다.

케이스(440, 450, 460)는 초기 상태가 슬롯 내의 두 청크가 유효할 때, 즉, S[C(1, 1), C(1, 0)]일 때의 상황일 수 있다. 슬롯이 K와 L을 포함한다고 가정하였을 때, 제2 비트를 참고하면 L이 포함된 청크가 더 최근에 캐싱된 청크라는 것을 알 수 있다.

케이스(440, 450)는 객체 K 혹은 L에 대한 업데이트 요청 수행될 때를 나타낼 수 있다. 케이스(440, 450)의 경우, 업데이트 되지 않는 객체가 포함된 청크가 먼저 스토리지로 플러시 될 수 있다.

케이스(440)의 경우에서는 L을 포함하는 청크가 스토리지로 플러시 되고, 해당 플러시가 완료되었다는 신호를 기다릴 수 있다. 완료 수신이 확인 된 후, 상태 C(1, 1)은 C(0, 0)으로 변경되며, 이 때의 상황은 케이스(420)의 1단계 상태와 동일하게 될 수 있고, 이 이후부터 진행되는 과정은 케이스(420)와 동일하게 진행될 수 있다.

객체 L에 대한 업데이트 요청이 수행되는 케이스(450)의 경우, 먼저 K가 포함된 청크가 플러시 되고, 완료 수신이 확인 된 후, 해당 청크의 상태 C(1, 0)은 C(0, 0)으로 변경될 수 있고, 이 때의 상황 또한, 케이스(420)의 1단계 상태와 동일하게 될 수 있다. 이 과정 이후에도, 마찬가지로, 케이스(420)의 이후 과정대로 진행될 수 있다.

케이스(460)의 경우는 영속적 버퍼 캐시(200)에 존재하지 않는 객체에 대한 쓰기 혹은 업데이트 연산이 요청 될 때(Write (M’)) 일 수 있다. 케이스(440, 450) 경우와 마찬가지로, 둘 중 하나의 청크는 플러시가 되어야 하는데, 더 이전에 쓰여진 청크가 플러시될 수 있다. 케이스(460)의 경우, K 객체가 포함된 청크가 플러시 될 수 있다. 플러시 완료가 확인 되면, 상태 C(1, 0)는 C(0, 0)으로 변경되고, 케이스(430)의 초기 상태가 되고, 그 다음 단계는 케이스(430)의 이후 과정과 동일할 수 있다.

플러시 동작은 쓰기 연산 요청시 발생 될 수 있으며, 동기적으로 발생되기 때문에 성능 오버헤드가 발생할 수 있다. 오버헤드를 줄이기 위해 백그라운드 플러시 기법을 사용할 수 있고, 이에 대한 설명은 아래에서 상세히 설명된다.

읽기 연산 과정은 쓰기과정과 유사하게 진행될 수 있다. 읽어야할 슬롯을 찾기 위해, 쓰기 때와 동일하게 키 값을 이용할 수 있다. 해당 슬롯의 청크에 읽고자 하는 데이터가 있을 경우, 영속적 버퍼 캐시(200)에서 데이터를 읽을 수 있다. 청크에 원하는 데이터가 없는 캐시 미스의 상황이 발생되면, 스토리지에서 해당 데이터를 로드 한 후 읽을 수 있다. 로드하는 데이터를 담기 위한 공간으로 선택되는 청크는 제일 먼저, 유효하지 않은 청크가 사용되며, 유효하지 않은 청크가 없을 경우, 오래된 청크가 선택될 수 있다. 청크가 선택되면, 해당 청크에 원래 있던 데이터가 플러시 된 후, 그 곳에 데이터가 로드 되고, 마지막으로 사용자의 유저 버퍼로 해당 데이터가 읽혀질 수 있다. 읽기 연산 과정에서 태그 값 또한 원자적으로 변경되며, 동일하게 영속성(persistency)을 위하여, clush, sfence 명령들이 이용될 수 있다.

도 5는 일 실시예에 따른 시스템 장애 발생 시 영속적 버퍼 캐시의 내용이 오류로부터 항상 복구 될 수 있음을 설명하기 위한 도면이다.

도 5를 참조하면, 일 실시예에 따른 영속적 버퍼 캐시(200)는 미디어 자체적인 장애로 인해 영속적 버퍼 캐시(200) 내용 자체에 대한 손상이 발생된 경우를 제외하고 항상 복구가 가능할 수 있다. 영속적 버퍼 캐시(200)는 어떠한 경우에서 허용되는 장애가 발생되어도 항상 일관된 상태로 돌아갈 수 있다.

최종적으로 상태의 변경이 발생한 후에 파일 데이터의 유효 여부를 지칭하는 제1 비트를 변경하기 때문에 케이스(410 내지 460) 중 어떤 단계에서 오류가 발생 되더라도 태그 값의 상태는 각 케이스의 초기 상태 중 하나가 될 수 있다. 쓰기 요청 자체가 완료 되지는 않았지만, 어떤 상태에 멈추더라도, 상태 C값은 온전하며, 이 상태는 시스템이 복구 된 후에 바로 특정 케이스의 초기 값이 되므로, 파일 시스템의 일관성에는 문제를 발생시키지 않는다.

예를 들어, 케이스(450)의 1단계(520)에서 장애가 발생되었다고 가정할 수 있다. K를 포함하는 청크가 플러시 되는 도중 장애가 발생 되면, 플러시는 실패 되지만, 상태는 케이스(450)의 초기 상태(510)인 S[C(1, 0), C(1, 1)]와 같을 수 있다. 만약 플러시가 완료 되었지만, 완료 수신을 받기 전에 장애가 발생한다고 해도, 백그라운드 플러시 기법에 의해 복구될 수 있다. 백그라운드 플러시 기법은 아래 도 6을 참조하여 자세히 설명된다. 영속적 버퍼 캐시(200) 청크의 K는 단순히 저장 장치에 있는 데이터의 복사본일 뿐일 수 있다. 플러시가 완료되지 않은 경우, 기존 파일 시스템은 단순히 쓰기 요청이 실패된 것으로 삭제 시키지만, 영속적 버퍼 캐시(200) 청크의 K 객체는 여전히 활성화된 상태일 수 있다. 두 경우 모두 초기 상태에서 작업이 다시 시작될 수 있다. K에 대한 요청은 실패 되었다고 사용자가 인식하여 해당 작업을 재 실행 했을 때, 다시 플러시가 발생되게 되는데, 이 때는 저장 장치 관점에서 이미 쓰여진 것을 다시 덮어쓰거나, 없는 데이터 공간에 새롭게 쓰는 상황이 될 수 있다.

플러시 완료 확인에 대한 수신이 된 후, 예를 들어 1단계(520)와 2단계(530) 사이에서 상태 C(1, 0)이 C(0, 0)으로 변경되기 전에 장애가 발생할 수 있는데, 이 경우 또한 위에 설명한 상황과 동일할 수 있다. 만약 2단계(530) 이후에 오류가 발생하게 되면, 슬롯의 상태는 S[C(1, 1), C(0, 0)]이 되는데, 이 상태는 케이스(420)의 초기 상태와 동일할 수 있다. 또한, 2단계(530)의 수행 과정은 원자성이 보장되기 때문에 수행하는 도중에는 오류가 발생할 수 없다.

케이스(420, 430, 440)에서 발생 될 수 있는 상태 S[C(1, 0), C(0, 0)]의 경우에는 태그 값의 상태는 각 케이스의 초기 상태와 다른 경우가 발생할 수 있지만, 이러한 경우에서도 하나의 상태가 C(0, 0)이므로, 상태 C(1, 0)과 C(1, 1)의 유효 상태는 실제로 동일하다고 간주할 수 있다. 상태 C(1, 0)을 C(1, 1)로 간주하게 되면, 케이스(420, 430)의 초기 상태와 동일하게 될 수 있다.

케이스(420)의 4단계에 대해서 설명하면, 이 상황은 실질적으로 케이스(440, 450, 460)의 초기 상태와 동일할 수 있지만, 청크는 같은 파일의 동일한 블록에 대해 참조하고 있고, 하나는 이전 데이터에 대해 참고하고 있으며, 또 다른 하나는 가장 최근 데이터에 대해 참조하고 있을 수 있다. 복구 시 오래된 데이터는 무효해야 하지만, 유효한 상태인 C(1, 0)으로 남게 될 수 있다. 이러한 경우에서도, 알고리즘에 따라 K’에 대한 플러시가 항상 K 보다 먼저 발생 될 것이기 때문에, 일관성 측면에서는 문제가 되지 않을 수 있다. 모든 상황에서 파일 시스템의 일관성이 보장 되는 영속적 버퍼 캐시(300)의 특성 때문에, 복구를 위해 추가적으로 수행해줘야 하는 복구 메커니즘이 필요하지 않을 수 있다

영속적 버퍼 캐시(200)는 일반적으로 파일 시스템에서 사용하고 있는 버퍼 캐시를 대체하는 버퍼 캐시일 수 있다. 읽기 및 쓰기 요청(파일 삭제 시에는 영속적 버퍼 캐시(200)의 태그 내용 무효화)을 제외하고, 파일 시스템과 상호작용하는 부분에서 발생되는 일관성 문제는 해당 파일 시스템에서 제공하는 일관성 메커니즘을 그대로 이용할 수 있다. 파일 시스템에서 제공하는 일관성 메커니즘에 영속적 버퍼 캐시(200)에 데이터를 보존함을 추가로 협력하여 제공할 수 있는 일관성 수준을 보장할 수 있다. 예를 들어, 영속적 버퍼 캐시(200)를 적용 시킨 Ext4 파일 시스템은 기본적으로 메타데이터에 대한 일관성을 보장하는 ordered 모드 저널링을 제공할 수 있고, 추가적으로 영속적 버퍼 캐시(200)가 배치 되면, 영속적 버퍼 캐시(200)에 상주하게 되는 데이터 또한 적절한 수준으로 보존될 수 있기 때문에, 기존 Ext4 파일 시스템에서 최고 수준의 일관성을 제공하는 데이터 모드 저널링과 유사하게 일관성을 보장할 수 있다.

기존 파일 시스템에서 파일 시스템의 일관성이 깨질 수 있는 위치에 대해서 고려해보면, 기존의 휘발성 버퍼 캐시는 성능을 향상 시키기 위한 용도로 사용될 뿐, 그 안에 저장 된 데이터에 대한 보존을 전혀 할 수 없을 수 있다. 명시적 명령 혹은 적절한 주기에 따라 버퍼 캐시에 저장 된 데이터가 저장 장치로 동기화가 이루어지긴 하지만, 동기화가 이루어 지기 전과, 이루어 지는 도중에는 일관성 불일치 문제가 생길 수 있다. 파일 시스템의 일관성을 보존하기 위해 저널링이 사용되긴 하지만, 본질적으로 휘발성 정보가 손실 될 수 있는 시간 간격은 일관성을 유지하는데 중요할 수 있다. 영속적 버퍼 캐시(200)를 사용하게 되면, 유실 될 수 있는 데이터에 대한 양이 현저하게 줄어들 수 있다. 모든 기록은 영속적 버퍼 캐시(200)에 즉시 기록되며, 비 휘발성 매체에 영속적으로 저장되는 것이기 때문에, 장애 시 그대로 유지 될 수 있다. 영속적 버퍼 캐시(200)의 유효한 상태의 데이터가 저장 장치에 동기화 되지 않을 수는 있지만, 영속적 버퍼 캐시(200)에 있는 최신 데이터의 모든 읽기 및 쓰기는 영속적 버퍼 캐시(200)에서만 처리 되고, 결국은 영속적 버퍼 캐시(200)에서 플러시를 통해 저장 장치로 동기화 되기 때문에 문제 되지 않을 수 있다. 또한 메타 데이터 또한 데이터가 파일 시스템으로 플러시 될 때, 조정 되기 때문에 해당 메타데이터에 대한 일관성은 하위 파일 시스템의 일관성 메커니즘에 의해 보장되며, 추가적으로 영속적 버퍼 캐시(200)에서 보존되어 있는 데이터들을 통하여 상대적으로 고수준 데이터 일관성을 보장할 수 있다.

도 6은 일 실시예에 따른 백그라운드 플러시 기법을 설명하기 위한 도면이다.

영속적 버퍼 캐시(200)의 청크 교체 인덱싱 기법에 따르면 자주 사용되는 파일 데이터와 자주 사용되지 않는 파일 데이터의 구별없이 무조건 순차적으로 교체되기 때문에 효율성이 떨어질 수 있다. 예를 들어, 청크에 원하는 데이터가 없는 캐시 미스의 상황이 발생되면, 캐시에 있는 데이터를 플러시한 이후에 스토리지에서 해당 데이터를 로드 한 후 읽어야 할 수 있다. 캐시 미스율은 (1 - 캐시 히트율)일 수 있고, 캐시 히트율은 (캐시에 적중되는 횟수/전체 스토리지 액세스 횟수)일 수 있다. 캐시 미스가 발생하면 플러시가 발생하고, 플러시 동작은 성능 오버헤드를 발생할 수 있다. 오버헤드를 줄이기 위해 백그라운드 플러시 기법을 사용할 수 있다.

기존의 비휘발성 메모리를 사용하는 경우 라이트 스루(write through) 기법을 사용하여 데이터가 캐시에 기입됨과 동시에 스토리지에도 기입할 수 있다. 라이트 스루 기법을 사용하는 경우, 스토리지로부터 기입 완료 신호를 받은 이후에 다음 연산을 진행할 수 있다. 라이트 스루 기법에 따르면, 속도가 느린 스토리지에 데이터를 기록하는 조작이 완료될 때까지 대기하는 시간이 필요하기 때문에 성능이 떨어질 수 있다.

도 6을 참조하면, 일 실시예에 따른 백그라운드 플러시 기법에 따르면, 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 컨트롤러는 제1 데이터를 백그라운드 프로세스를 통해 제1 데이터를 플러시하고, 스토리지로부터 응답을 기다리지 않고 다음 연산을 진행시킬 수 있다. 예를 들어, 컨트롤러는 A 데이터에 대한 쓰기 연산을 요청 받고, A 데이터를 백그라운드 프로세스를 통해 플러시하고 스토리지로부터 기입 완료 신호를 받기 전에 B 데이터 읽기 연산을 진행시킬 수 있다. 백그라운드 프로세스는 예를 들어 workqueue api를 이용하여 동작할 수 있다. 영속적 버퍼 캐시(200)는 비휘발성 메모리를 사용하기 때문에 스토리지로부터 응답을 기다리지 않고 다음 연산을 진행시켜도 시스템 붕괴되어도 복구에 문제가 없을 수 있다.

영속적 버퍼 캐시(200)의 구조로 인해 발생하는 캐시 미스에 의한 오버헤드를 백그라운드 플러시 기법으로 보상해줄 수 있다. 원하는 데이터가 없는 캐시 미스의 상황이 발생되면, 캐시에 있는 데이터를 플러시한 이후에 스토리지에서 해당 데이터를 로드 한 후 읽어야 할 수 있다. 일 실시예에 따른 백그라운드 플러시 기법을 사용하는 경우, 데이터를 백그라운드 프로세스를 통해 즉시 플러시 시켰기 때문에 캐시 미스가 발생하는 경우에 플러시할 필요없이 해당 데이터를 로드만 하면 되기 때문에 플러시로 인한 오버헤드를 줄일 수 있다.

컨트롤러는 일반적인 경우 백그라운드 플러시 기법에 따라 스토리지로부터 응답을 기다리지 않고 다음 연산을 진행시킬 수 있지만, 제1 데이터가 캐싱된 청크에 새로운 파일 데이터에 대한 연산을 요청 받는 경우에는 제1 데이터의 쓰기 연산이 완료될 때까지 새로운 파일 데이터에 대한 연산을 계류(pending)시킬 수 있다. 예를 들어, 도 4의 케이스(460)는 K 데이터가 캐싱된 청크에 새로운 M 데이터에 대한 연산을 요청 받은 경우로, K 데이터를 백그라운드 플러시 하고 스토리지로부터 응답을 기다리지 않고 M 데이터에 대한 쓰기 연산을 진행시킨다면 시스템 장애 발생 시 복구에 문제가 생길 수 있다. 제1 데이터가 캐싱된 청크에 새로운 파일 데이터에 대한 연산을 요청 받는 경우에는 제1 데이터의 쓰기 연산이 완료될 때까지 새로운 파일 데이터에 대한 연산을 계류시켜야 일관성을 유지할 수 있다.

도 7은 일 실시예에 따른 제1 데이터의 크기가 단위 청크의 크기보다 큰 경우의 취급을 설명하기 위한 도면이다.

도 7을 참조하면, 일 실시예에 따른 1 데이터의 크기가 단위 청크의 크기보다 큰 경우, 제1 데이터는 복수개의 청크에 캐싱될 수 있다. 키 값에 기초하여 복수 개의 청크 중 가장 먼저 캐싱하는 청크를 결정할 수 있다. 파일 데이터의 크기에 기초하여 필요한 청크 수를 결정할 수 있다. 예를 들어, 청크 사이즈는 4KB, 파일 데이터의 크기는 12KB인 경우에는 파일 데이터를 캐싱하기 위해 3개의 청크, 2번 청크 내지 4번 청크를 결정할 수 있다. 이하, 설명의 편의를 위하여 2번 청크 내지 4번 청크에 제1 데이터가 캐싱되는 예를 기준으로 설명한다. 또한, 일 실시예에 따른 청크는 2-way로 구성되어 있으나, 설명의 편의를 위하여 도 7에서는 2-way 청크들 중 한 면의 청크만을 도시하였다.

여러개의 청크에 업데이트가 발생될 때, 청크별로 업데이트 될 때의 상태를 표시하기 위한 제4 비트를 태그에 추가할 수 있다. 제4 비트는 C(Complete)로 표현될 수 있다. 일 실시예에 따른 태그는 1byte의 크기를 가지며, 제1 데이터의 유효 여부를 지칭하는 제1 비트(V), 슬롯의 두 청크에 있어서 캐싱의 선후 관계를 지칭하는 제2 비트(N), 더티 상태(dirty state)를 지칭하는 제3 비트(D), 청크별로 업데이트 될 때의 상태를 표시하기 위한 제4 비트(C)와 업데이트 되는 사이즈에 따라 마지막 데이터가 쓰여질 청크의 오프셋을 나타내는 4개의 오프셋 비트를 포함할 수 있다.

도면(710)을 참조하면, 12KB의 데이터 중 4KB의 데이터가 2번 청크에 쓰여진 후, 최종적으로 8KB~12KB의 데이터가 쓰여질 4번 청크의 오프셋를 태그의 오프셋 비트 영역에 '0010'으로 표시할 수 있다. 오프셋은 마지막 청크의 위치와 처음 청크의 위치 차이로 계산 될 수 있다.

단일 청크에 데이터가 쓰여지거나 업데이트 될 때의 메커니즘에 따르면, 청크에 데이터를 쓴 후에 바로 백그라운드 플러시가 발생하여 해당 데이터를 아래 저장 장치에 옮기게 되는데, 여러개의 청크에 데이터가 쓰여질 경우에는 이를 펜딩시킬 수 있다. 백그라운드 플러시를 펜딩시키는 이유는 12KB의 데이터를 모두 쓰기 전에 시스템 장애가 발생하였을 경우, 그 전에 청크에 새롭게 쓰여진 데이터가 백그라운드 플러시를 통해 저장 장치에 부분적으로 적용되는 상황을 막기 위해서일 수 있다.

도면(720)을 참조하면, 2번 청크와 마찬가지로 3번 청크에 4KB~8KB까지의 데이터가 쓰여진 후에 백그라운드 플러시를 펜딩시킬 수 있다. 또한, 3번 청크에 대한 태그에는 아무 변화를 주지 않을 수 있다.

도면(730)을 참조하면, 동일하게 4번 청크에 나머지 4KB의 데이터가 쓰여진 후에 백그라운드 플러시가 펜딩될 수 있다. 복수개의 청크 중 마지막 청크에 제1 데이터의 쓰기 연산이 완료되는 경우, 마지막 청크의 제4 비트는 제1 논리값을 갖을 수 있다. 예를 들어, 4번 청크에 나머지 4KB의 데이터가 쓰여진 후에 4번 청크에 대한 태그의 제4 비트(C 비트)를 '1'로 표시할 수 있다. 제4 비트가 제1 논리값을 갖는 것은 데이터가 온전히 청크에 모두 쓰여졌다는 것을 의미할 수 있다. 그런 후에 2번 청크에 표시되어 있던 오프셋 비트 '0010'을 다시 초기화 해줄 수 있다. 2번 청크의 오프셋 비트를 초기화 해주는 이유는 시스템 장애시 복구 과정에서는 지금과 같은 예제 케이스들을 판별하기 위해 청크들을 순회하면서 태그의 앞의 오프셋 비트가 '0000'으로 초기화 되어있지 않은 청크들을 찾게되는데, 수행이 온전히 완료된 쓰기 및 업데이트 행위에 대해서는 초기화를 해줌으로서 복구 과정에서 불필요한 검사를 하지 않도록 해줄 수 있다. 다음으로, 다시 4번 청크의 제4 비트(C 비트)를 '0'으로 바꿔준 후에 앞서 펜딩되어있던 2~4번 청크의 백그라운드 플러시들을 릴리즈 시켜줄 수 있다.

일 실시예에 따른 여러개의 청크 캐싱 방법에 따르면, 장애 발생시 복구 과정이 매우 단순해질 수 있다. 만약 여러개의 청크에 데이터가 업데이트 되는 도중 시스템 장애가 발생하게 된다면, 청크들의 태그에는 앞서 설명한 런타임 과정을 통해 처음 쓰기가 시작된 청크의 태그에는 마지막에 쓰여져야할 청크의 오프셋이 쓰여져 있을 것이며, 마지막 청크의 태그에는 해당 업데이트 행위가 마무리가 되지 않았으므로, 제4 비트('C' 비트)가 '0'으로 표시되어 있을 것이다. 이런 상태로 표시되어 있는 영역을 찾는 것이 복구 과정에서 발생할 수 있는 성능적 부하의 전부이며, 이 상태가 발생된 영역의 청크들의 태그는 모두 0으로 초기화 해줌으로써 시스템의 일관성을 보장할 수 있다. 이를 가능하게 하는 이유는 런타임 과정에서 모든 업데이트가 청크에 온전히 반영되지 않았을 경우에는 백그라운드 플러시를 펜딩시킴으로 아래의 저장 장치에 부분적 업데이트가 적용되지 않을 것이기 때문이다.

도 8은 일 실시예에 따른 영속적 버퍼 캐시의 동작 방법을 도시한 도면이다. 도 8을 참조하면, 단계(810, 820)은 영속적 버퍼 캐시(200)에 의해 동작할 수 있다.

단계(810)에서, 영속적 버퍼 캐시(200)는 응용 프로그램으로부터 제1 데이터에 대한 연산을 요청 받는다.

단계(820)에서, 영속적 버퍼 캐시(200)는 제1 데이터에 부여되는 고유값에 기초하여 제1 데이터가 캐싱되는 위치를 결정한다.

제1 데이터는 비휘발성 메모리의 제1 영역에 캐싱되고, 고유값을 포함하는 제2 데이터는 비휘발성 메모리의 제2 영역에 캐싱된다.

이상에서 설명된 실시예들은 하드웨어 구성요소, 소프트웨어 구성요소, 및/또는 하드웨어 구성요소 및 소프트웨어 구성요소의 조합으로 구현될 수 있다. 예를 들어, 실시예들에서 설명된 장치, 방법 및 구성요소는, 예를 들어, 프로세서, 콘트롤러, ALU(arithmetic logic unit), 디지털 신호 프로세서(digital signal processor), 마이크로컴퓨터, FPGA(field programmable gate array), PLU(programmable logic unit), 마이크로프로세서, 또는 명령(instruction)을 실행하고 응답할 수 있는 다른 어떠한 장치와 같이, 하나 이상의 범용 컴퓨터 또는 특수 목적 컴퓨터를 이용하여 구현될 수 있다. 처리 장치는 운영 체제(OS) 및 상기 운영 체제 상에서 수행되는 하나 이상의 소프트웨어 애플리케이션을 수행할 수 있다. 또한, 처리 장치는 소프트웨어의 실행에 응답하여, 데이터를 접근, 저장, 조작, 처리 및 생성할 수도 있다. 이해의 편의를 위하여, 처리 장치는 하나가 사용되는 것으로 설명된 경우도 있지만, 해당 기술분야에서 통상의 지식을 가진 자는, 처리 장치가 복수 개의 처리 요소(processing element) 및/또는 복수 유형의 처리 요소를 포함할 수 있음을 알 수 있다. 예를 들어, 처리 장치는 복수 개의 프로세서 또는 하나의 프로세서 및 하나의 콘트롤러를 포함할 수 있다. 또한, 병렬 프로세서(parallel processor)와 같은, 다른 처리 구성(processing configuration)도 가능하다.

소프트웨어는 컴퓨터 프로그램(computer program), 코드(code), 명령(instruction), 또는 이들 중 하나 이상의 조합을 포함할 수 있으며, 원하는 대로 동작하도록 처리 장치를 구성하거나 독립적으로 또는 결합적으로(collectively) 처리 장치를 명령할 수 있다. 소프트웨어 및/또는 데이터는, 처리 장치에 의하여 해석되거나 처리 장치에 명령 또는 데이터를 제공하기 위하여, 어떤 유형의 기계, 구성요소(component), 물리적 장치, 가상 장치(virtual equipment), 컴퓨터 저장 매체 또는 장치, 또는 전송되는 신호 파(signal wave)에 영구적으로, 또는 일시적으로 구체화(embody)될 수 있다. 소프트웨어는 네트워크로 연결된 컴퓨터 시스템 상에 분산되어서, 분산된 방법으로 저장되거나 실행될 수도 있다. 소프트웨어 및 데이터는 하나 이상의 컴퓨터 판독 가능 기록 매체에 저장될 수 있다.

실시예에 따른 방법은 다양한 컴퓨터 수단을 통하여 수행될 수 있는 프로그램 명령 형태로 구현되어 컴퓨터 판독 가능 매체에 기록될 수 있다. 상기 컴퓨터 판독 가능 매체는 프로그램 명령, 데이터 파일, 데이터 구조 등을 단독으로 또는 조합하여 포함할 수 있다. 상기 매체에 기록되는 프로그램 명령은 실시예를 위하여 특별히 설계되고 구성된 것들이거나 컴퓨터 소프트웨어 당업자에게 공지되어 사용 가능한 것일 수도 있다. 컴퓨터 판독 가능 기록 매체의 예에는 하드 디스크, 플로피 디스크 및 자기 테이프와 같은 자기 매체(magnetic media), CD-ROM, DVD와 같은 광기록 매체(optical media), 플롭티컬 디스크(floptical disk)와 같은 자기-광 매체(magneto-optical media), 및 롬(ROM), 램(RAM), 플래시 메모리 등과 같은 프로그램 명령을 저장하고 수행하도록 특별히 구성된 하드웨어 장치가 포함된다. 프로그램 명령의 예에는 컴파일러에 의해 만들어지는 것과 같은 기계어 코드뿐만 아니라 인터프리터 등을 사용해서 컴퓨터에 의해서 실행될 수 있는 고급 언어 코드를 포함한다. 상기된 하드웨어 장치는 실시예의 동작을 수행하기 위해 하나 이상의 소프트웨어 모듈로서 작동하도록 구성될 수 있으며, 그 역도 마찬가지이다.

이상과 같이 실시예들이 비록 한정된 도면에 의해 설명되었으나, 해당 기술분야에서 통상의 지식을 가진 자라면 상기를 기초로 다양한 기술적 수정 및 변형을 적용할 수 있다. 예를 들어, 설명된 기술들이 설명된 방법과 다른 순서로 수행되거나, 및/또는 설명된 시스템, 구조, 장치, 회로 등의 구성요소들이 설명된 방법과 다른 형태로 결합 또는 조합되거나, 다른 구성요소 또는 균등물에 의하여 대치되거나 치환되더라도 적절한 결과가 달성될 수 있다.

그러므로, 다른 구현들, 다른 실시예들 및 특허청구범위와 균등한 것들도 후술하는 특허청구범위의 범위에 속한다.

Claims (37)

1. 제1 데이터가 캐싱되는 제1 영역과 상기 제1 데이터가 생성 시 상기 제1 데이터에 부여되는 고유값을 포함하는 제2 데이터가 캐싱되는 제2 영역을 포함하는 비휘발성 메모리; 및
   응용 프로그램으로부터 상기 제1 데이터에 대한 연산을 요청 받는 경우, 상기 고유값에 기초하여 상기 제1 데이터가 캐싱되는 위치를 결정하는 컨트롤러
   를 포함하는 버퍼 캐시.
   
2. 제1항에 있어서,
   상기 제1 영역은 2-way 구조를 갖는, 버퍼 캐시.
   
3. 제2항에 있어서,
   상기 제1 영역은 청크 단위로 구성되고, 각 청크들은 상기 2-way 구조에 따라 청크 쌍으로 이루어진 슬롯을 구성하는, 버퍼 캐시.
   
4. 제3항에 있어서,
   상기 컨트롤러는
   상기 응용 프로그램으로부터 상기 제1 데이터에 대한 연산을 요청 받는 경우, 상기 고유값과 상기 제1 영역을 구성하는 청크들의 수에 기초하여 상기 제1 데이터가 캐싱되는 상기 슬롯의 인덱스를 결정하는, 버퍼 캐시.
   
5. 제1항에 있어서,
   상기 제2 데이터는 상기 제1 데이터의 상태를 나타내는 비트를 더 포함하는, 버퍼 캐시.
   
6. 제5항에 있어서,
   상기 비트는 상기 제1 데이터의 유효 여부를 지칭하는 제1 비트와 슬롯의 두 청크에 있어서 캐싱의 선후 관계를 지칭하는 제2 비트를 포함하는, 버퍼 캐시.
   
7. 제6항에 있어서,
   상기 제1 비트는 상기 제1 데이터에 대한 연산이 완료된 이후에 변경되는, 버퍼 캐시
   
8. 제6항에 있어서,
   상기 비트는 상기 제1 데이터의 더티 상태(dirty state)를 지칭하는 제3 비트를 더 포함하는, 버퍼 캐시.
   
9. 제6항에 있어서,
   상기 컨트롤러는
   상기 제1 데이터가 유효한 경우 상기 제1 비트는 제1 논리값을 갖고, 상기 슬롯의 상기 두 청크 중 나중에 캐싱된 청크의 경우 상기 제2 비트는 제1 논리값을 갖도록 제어하는, 버퍼 캐시.
   
10. 제1항에 있어서,
    상기 컨트롤러는
    상기 응용 프로그램으로부터 상기 제1 데이터에 대한 업데이트(update) 연산을 요청 받는 경우, 상기 제1 데이터를 상기 제1 데이터가 캐싱된 청크의 토클(toggle) 청크에 복사하는, 버퍼 캐시.
    
11. 제1항에 있어서,
    상기 컨트롤러는
    상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 제1 데이터를 백그라운드 프로세스를 통해 플러시(flush)하고, 스토리지로부터 응답을 기다리지 않고 다음 연산을 진행시키는, 버퍼 캐시.
    
12. 제11항에 있어서,
    상기 컨트롤러는
    상기 제1 데이터가 캐싱된 청크에 새로운 파일 데이터에 대한 연산을 요청 받는 경우, 상기 제1 데이터의 상기 쓰기 연산이 완료될 때까지 상기 새로운 파일 데이터에 대한 연산을 계류(pending)시키는, 버퍼 캐시.
    
13. 제1항에 있어서,
    상기 버퍼 캐시는 가상 파일 시스템 레이어(Virtual file system layer)상에 존재하는, 버퍼 캐시.
    
14. 제1항에 있어서,
    상기 컨트롤러는
    상기 제1 데이터의 크기가 단위 청크의 크기보다 큰 경우, 상기 제1 데이터가 캐싱되는 슬롯의 인덱스 영역을 결정하고,
    상기 인덱스 영역에 기초하여, 상기 제1 데이터를 복수개의 청크에 캐싱하는, 버퍼 캐시.
    
15. 제14항에 있어서,
    상기 컨트롤러는
    상기 제1 데이터의 크기가 단위 청크의 크기보다 크고, 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 복수개의 청크 전부에 상기 제1 데이터의 상기 쓰기 연산이 완료되면 상기 제1 데이터를 백그라운드 프로세스를 통해 상기 제1 데이터를 플러시(flush)하는, 버퍼 캐시.
    
16. 제 6항에 있어서,
    상기 비트는 상기 제1 데이터의 크기가 단위 청크의 크기보다 크고, 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 제1 데이터의 상기 쓰기 연산의 완료 여부를 지칭하는 제4 비트를 포함하는, 버퍼 캐시의 동작 방법.
    
17. 제 16항에 있어서,
    복수개의 청크 중 마지막 청크에 상기 제1 데이터의 상기 쓰기 연산이 완료되는 경우, 상기 마지막 청크의 상기 제4 비트는 제1 논리값을 갖는, 버퍼 캐시의 동작 방법.
    
18. 제 14항에 있어서,
    상기 컨트롤러는
    상기 복수개의 청크 중 첫번째 청크의 오프셋 비트를 결정하고,
    복수개의 청크 중 마지막 청크에 상기 제1 데이터의 쓰기 연산이 완료되는 경우, 상기 오프셋 비트를 초기화 하는, 버퍼 캐시의 동작 방법.
    
19. 제 18항에 있어서,
    상기 컨트롤러는
    상기 오프셋 비트를 초기화한 이후에, 제4 비트를 제2 논리값으로 바꿔주는, 버퍼 캐시의 동작 방법.
    
20. 응용 프로그램으로부터 제1 데이터에 대한 연산을 요청 받는 단계;
    상기 제1 데이터에 부여되는 고유값에 기초하여 상기 제1 데이터가 캐싱되는 위치를 결정하는 단계
    를 포함하고,
    상기 제1 데이터는 비휘발성 메모리의 제1 영역에 캐싱되고, 상기 고유값을 포함하는 제2 데이터는 상기 비휘발성 메모리의 제2 영역에 캐싱되는, 버퍼 캐시의 동작 방법.
    
21. 제 20항에 있어서,
    상기 제1 영역은 2-way 구조를 갖는, 버퍼 캐시의 동작 방법.
    
22. 제 21항에 있어서,
    상기 제1 영역은 청크 단위로 구성되고, 각 청크들은 상기 2-way 구조에 따라 청크 쌍으로 이루어진 슬롯을 구성하는, 버퍼 캐시의 동작 방법.
    
23. 제 22항에 있어서,
    상기 제1 데이터가 캐싱되는 위치를 결정하는 단계는
    상기 응용 프로그램으로부터 상기 제1 데이터에 대한 연산을 요청 받는 경우, 상기 고유값과 상기 제1 영역을 구성하는 청크들의 수에 기초하여 상기 제1 데이터가 캐싱되는 상기 슬롯의 인덱스를 결정하는 단계
    를 포함하는, 버퍼 캐시의 동작 방법.
    
24. 제 20항에 있어서,
    상기 제2 데이터는 상기 제1 데이터의 상태를 나타내는 비트를 더 포함하는, 버퍼 캐시의 동작 방법.
    
25. 제 24항에 있어서,
    상기 비트는 상기 제1 데이터의 유효 여부를 지칭하는 제1 비트와 슬롯의 두 청크에 있어서 캐싱의 선후 관계를 지칭하는 제2 비트를 포함하는, 버퍼 캐시의 동작 방법.
    
26. 제 25항에 있어서,
    상기 제1 비트는 상기 제1 데이터에 대한 연산이 완료된 이후에 변경되는, 버퍼 캐시의 동작 방법.
    
27. 제 25항에 있어서,
    상기 제1 데이터가 유효한 경우 상기 제1 비트는 제1 논리값을 갖고, 상기 슬롯의 상기 두 청크 중 나중에 캐싱된 청크의 경우 상기 제2 비트는 제1 논리값을 갖도록 제어하는 단계
    를 더 포함하는, 버퍼 캐시의 동작 방법.
    
28. 제 20항에 있어서,
    응용 프로그램으로부터 상기 제1 데이터에 대한 업데이트(update) 연산을 요청 받는 경우, 상기 제1 데이터를 상기 제1 데이터가 캐싱된 청크의 토클(toggle) 청크에 복사하는 단계
    를 더 포함하는, 버퍼 캐시의 동작 방법.
    
29. 제 20항에 있어서,
    상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 제1 데이터를 백그라운드 프로세스를 통해 플러시(flush)하고, 스토리지로부터 응답을 기다리지 않고 다음 연산을 진행시키는 단계
    를 더 포함하는, 버퍼 캐시의 동작 방법.
    
30. 제 29항에 있어서,
    상기 제1 데이터가 캐싱된 청크에 새로운 파일 데이터에 대한 연산을 요청 받는 경우, 상기 제1 데이터의 상기 쓰기 연산이 완료될 때까지 상기 새로운 파일 데이터에 대한 연산을 계류(pending)시키는 단계
    를 더 포함하는, 버퍼 캐시의 동작 방법.
    
31. 제 20항에 있어서,
    상기 제1 데이터가 캐싱되는 위치를 결정하는 단계는
    상기 제1 데이터의 크기가 단위 청크의 크기보다 큰 경우, 상기 제1 데이터가 캐싱되는 슬롯의 인덱스 영역을 결정하는 단계
    를 포함하고,
    상기 인덱스 영역에 기초하여, 상기 제1 데이터를 복수개의 청크에 캐싱하는 단계
    를 더 포함하는, 버퍼 캐시의 동작 방법.
    
32. 제 31항에 있어서,
    상기 제1 데이터를 복수개의 청크에 캐싱하는 단계는
    상기 제1 데이터의 크기가 단위 청크의 크기보다 크고, 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 복수개의 청크 전부에 상기 제1 데이터의 상기 쓰기 연산이 완료되면 상기 제1 데이터를 백그라운드 프로세스를 통해 상기 제1 데이터를 플러시(flush)하는 단계를
    포함하는, 버퍼 캐시의 동작 방법.
    
33. 제 25항에 있어서,
    상기 비트는 상기 제1 데이터의 크기가 단위 청크의 크기보다 크고, 상기 제1 데이터에 대한 쓰기 연산을 요청 받는 경우, 상기 제1 데이터의 상기 쓰기 연산의 완료 여부를 지칭하는 제4 비트를 포함하는, 버퍼 캐시의 동작 방법.
    
34. 제 33항에 있어서,
    복수개의 청크 중 마지막 청크에 상기 제1 데이터의 상기 쓰기 연산이 완료되는 경우, 상기 마지막 청크의 상기 제4 비트는 제1 논리값을 갖는, 버퍼 캐시의 동작 방법.
    
35. 제 31항에 있어서,
    상기 제1 데이터를 복수개의 청크에 캐싱하는 단계는
    상기 복수개의 청크 중 첫번째 청크의 오프셋 비트를 결정하는 단계; 및
    복수개의 청크 중 마지막 청크에 상기 제1 데이터의 쓰기 연산이 완료되는 경우, 상기 오프셋 비트를 초기화 해주는 단계
    를 포함하는, 버퍼 캐시의 동작 방법.
    
36. 제 35항에 있어서,
    상기 오프셋 비트를 초기화한 이후에, 제4 비트를 제2 논리값으로 바꿔주는 단계
    를 더 포함하는, 버퍼 캐시의 동작 방법.
    
37. 하드웨어와 결합되어 제20항 내지 제36항 중 어느 하나의 항의 방법을 실행시키기 위하여 매체에 저장된 컴퓨터 프로그램.
    
    

Images