KR20140042522A - 디렉토리 엔트리 조회 장치, 그 방법 및 디렉토리 엔트리 조회 프로그램이 기록된 기록 매체 - Google Patents

Abstract

디렉토리 엔트리를 조회하기 위한 별도의 데이터 구조를 필요로 하지 않으면서도 신속한 디렉토리 엔트리 조회 기능을 구비한 호스트 장치가 제공된다. 본 발명에 따른 호스트 장치는 각 디렉토리의 디렉토리 엔트리(DENTRY)를 포함하는 멀티 레벨 해쉬 테이블을 저장하는 스토리지 장치와의 데이터 송수신을 중계하는 인터페이스 및 검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을 입력 받고, 상기 검색 파일명 및 조회 레벨이 반영된 해쉬 값을 연산하고, 상기 검색 디렉토리의 멀티 레벨 해쉬 테이블에 포함된 상기 조회 레벨의 버켓(bucket) 중 상기 해쉬 값에 대응하는 버켓에서 상기 검색 파일명을 포함하는 상기 디렉토리 엔트리를 검색하는 파일 시스템 모듈을 포함할 수 있다. 상기 파일 시스템 모듈은 상기 검색이 실패하면 상기 조회 레벨을 증가시켜 상기 해쉬 값 연산 및 상기 검색 파일명 검색을 재수행할 수 있다.

Description

디렉토리 엔트리 조회 장치, 그 방법 및 디렉토리 엔트리 조회 프로그램이 기록된 기록 매체 {Apparatus and method for directory entry look up, and recording medium recording the directory entry look up program thereof}

본 발명은 디렉토리 엔트리 조회 장치, 그 방법 및 디렉토리 엔트리 조회 프로그램이 기록된 기록 매체에 관한 것이다. 보다 자세하게는 조회 대상 디렉토리 내에 포함된 파일의 수가 매우 많을 때에도 신속하게 조회 대상 파일의 디렉토리 엔트리를 찾을 수 있고, 신속한 조회를 위한 별도의 데이터 구조를 관리할 필요가 없는 디렉토리 엔트리 조회 장치, 그 방법 및 디렉토리 엔트리 조회 프로그램이 기록된 기록 매체에 관한 것이다.

파일 시스템이 제공하는 기능 중 하나는 디렉토리 서비스이다. 파일 시스템은 각각의 파일에 대한 아이노드(inode)를 관리하는 것처럼, 각각의 디렉토리에 대한 아이노드(inode)도 관리한다. 파일 시스템은 각각의 파일에 포함되는 데이터를 상기 아이노드로부터 접근할 수 있도록 하는 것처럼, 각각의 디렉토리에 포함되는 파일 및 서브 디렉토리 각각에 대한 데이터인 디렉토리 엔트리를 상기 아이노드로부터 접근할 수 있도록 한다.

사용자가 필요로 할 때 빠르게 파일을 찾거나 혹은 생성 및 삭제하는 과정은 디렉토리 서비스의 주요 동작이다. 특히 디렉토리 내에 파일의 개수가 매우 많이 있을 경우, 파일을 빠르게 찾는 것이 매우 중요하다.

다수의 파일을 포함하고 있는 디렉토리에서 조회 대상 파일을 신속하게 찾기 위하여, 해쉬 함수를 이용한 탐색, 트리 기반의 탐색 방법 등이 사용될 수 있다.

해쉬 함수를 이용한 탐색 방식은 찾고자 하는 파일 이름을 해시 함수를 이용하여 특수한 값으로 변환하고, 해당 값에 해당하는 인덱스로 해시 테이블을 검색하여 해당 디렉토리 엔트리의 위치를 알아내는 방식이다. 이 방식은 해시 테이블에서 바로 원하는 디렉토리 엔트리의 위치를 알아낼 수 있기 때문에 이상적인 상황에서 가장 빠른 방식이나, 해시 충돌(collision)이 일어날 경우를 위한 처리 비용, 해시 테이블을 관리해야 하는 비용과 비어 있는 디렉토리 엔트리를 관리해야 하는 비용이 있다.

트리 기반의 탐색 방법은 해쉬 함수를 이용한 방식에서 문제가 되는 해시 충돌에 관한 문제와 해시 테이블을 구성하는데 드는 비용을 줄이기 위하여 일반적으로 널리 알려진 검색 방법인 이진 탐색 트리 등의 데이터 구조를 이용하는 방식이다. 찾고자 하는 파일 이름에 대한 해시 값을 키 값으로 이용하여 트리 구조 내에서 탐색하면 저장된 디렉토리 엔트리의 위치를 얻어내는 방식이다. 매우 다량의 디렉토리 엔트리들에 대해서 감내할만한 성능을 얻을 수 있는 장점이 있지만, 여전히 비어 있는 디렉토리 엔트리에 대하여도 별도의 노드를 생성해 줌으로써, 조회를 위한 데이터 구조가 차지하는 저장공간이 낭비되는 문제점이 있다.

본 발명이 해결하려는 과제는, 디렉토리 엔트리를 조회하기 위한 별도의 데이터 구조를 필요로 하지 않으면서도 신속한 디렉토리 엔트리 조회 기능을 구비한 호스트 장치를 제공하는 것이다.

본 발명이 해결하려는 다른 과제는, 파일명 길이의 불확실성으로 인하여 파일명 길이를 최대 사이즈로 미리 할당하는 것에 의하여 발생되는 저장공간 낭비 문제를 해결하는 호스트 장치를 제공하는 것이다.

본 발명이 해결하려는 또 다른 과제는, 디렉토리 엔트리를 저장하기 위한 별도의 인덱싱 구조를 사용하지 않고, 파일에 포함된 데이터를 저장하기 위한 인덱싱 구조를 그대로 사용하는 호스트 장치를 제공하는 것이다.

본 발명이 해결하려는 또 다른 과제는, 디렉토리 엔트리를 조회하기 위한 별도의 데이터 구조를 필요로 하지 않으면서도 신속한 디렉토리 엔트리 조회 기능을 구비한 디렉토리 엔트리 조회 방법을 제공하는 것이다.

본 발명이 해결하려는 또 다른 과제는, 디렉토리 엔트리를 조회하기 위한 별도의 데이터 구조를 필요로 하지 않으면서도 신속한 디렉토리 엔트리 조회 기능을 구비한 디렉토리 엔트리 조회 방법을 수행하는 프로그램이 기록된 기록매체를 제공하는 것이다.

본 발명이 해결하려는 과제들은 이상에서 언급한 과제들로 제한되지 않으며, 언급되지 않은 또 다른 과제들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

상기 문제점을 해결하기 위한 본 발명의 일 면(aspect)에 따른 호스트 장치는 각 디렉토리의 디렉토리 엔트리(DENTRY)를 포함하는 멀티 레벨 해쉬 테이블을 저장하는 스토리지 장치와의 데이터 송수신을 중계하는 인터페이스; 및 검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을 입력 받고, 상기 검색 파일명 및 조회 레벨이 반영된 해쉬 값을 연산하고, 상기 검색 디렉토리의 멀티 레벨 해쉬 테이블에 포함된 상기 조회 레벨의 버켓(bucket) 중 상기 해쉬 값에 대응하는 버켓에서 상기 검색 파일명을 포함하는 상기 디렉토리 엔트리를 검색하는 파일 시스템 모듈을 포함한다. 이 때, 상기 파일 시스템 모듈은 상기 검색이 실패하면 상기 조회 레벨을 증가시켜 상기 해쉬 값 연산 및 상기 검색 파일명 검색을 재수행한다.

일 실시예에 따르면, 상기 파일 시스템 모듈은, 검색된 디렉토리 엔트리에 포함된 아이노드 식별자를 상기 파일 조회 명령을 입력한 모듈에 출력할 수 있다.

일 실시예에 따르면, 상기 멀티 레벨 해쉬 테이블은 상기 디렉토리 엔트리 이외의 데이터를 포함하지 않을 수 있다. 즉, 상기 디렉토리 엔트리가 본 발명에 따른 방식으로 배치되어 저장됨으로써, 상기 멀티 레벨 해쉬 테이블로써 기능할 수 있다.

일 실시예에 따르면, 상기 멀티 레벨 해쉬 테이블에 포함된 각 레벨의 버켓은 zero-base 오프셋으로 접근되고, 상기 해쉬 값은 버켓 오프셋으로 사용될 수 있다.

일 실시예에 따르면, 상기 멀티 레벨 해쉬 테이블에 포함된 모든 버켓은 N(N=2이상의 기 지정된 자연수) 개의 블록을 포함하고, 하나의 블록의 데이터 사이즈는 기 지정된 것일 수 있다. 상기 블록 하나에는 기 지정된 개수의 디렉토리 엔트리 슬롯이 포함되고, 하나 이상의 상기 디렉토리 엔트리 슬롯은 하나의 디렉토리 엔트리를 구성할 수 있다. 상기 각각의 디렉토리 엔트리 슬롯은 파일 아이노드 식별자 저장영역과 기 지정된 사이즈의 파일명 저장 영역을 포함하고, 두개 이상의 디렉토리 엔트리 슬롯이 하나의 디렉토리 엔트리를 구성하는 경우, 상기 디렉토리 엔트리를 구성하는 디렉토리 엔트리 슬롯에 포함된 파일명 저장 영역에 저장된 문자열 전체가 연결되어 상기 디렉토리 엔트리에 대응되는 파일의 파일명이 형성될 수 있다.

상기 멀티 레벨 해쉬 테이블에 포함된 각 레벨의 버켓 수는 레벨이 증가할 수록 증가할 수 있다. 상기 멀티 레벨 해쉬 테이블에 포함된 각 레벨(LEVEL)의 버켓 수는 MLEVEL(M = 기지정된 베이스로써, 2이상의 자연수)일 수 있다. 상기 해쉬 값은 상기 검색 파일명에 해쉬 함수를 적용한 값에 상기 조회 레벨에서의 버켓 수를 나눈 나머지일 수 있다. 상기 멀티 레벨 해쉬 테이블은, 상기 멀티 레벨 해쉬 테이블에 대응하는 디렉토리의 아이노드를 루트로 하는 트리 구조의 인덱싱 구조에 따라 저장될 수도 있다. 상기 아이노드는, 데이터 블록을 가리키는 포인터, 다이렉트 노드 블록을 가리키는 포인터, 제1 인다이렉트 노드 블록을 가리키는 포인터, 제2 인다이렉트 노드 블록을 가라키는 포인터 중 적어도 하나를 포함하고, 상기 다이렉트 노드 블록은 데이터 블록을 가리키는 포인터를 하나 이상 포함하고, 상기 제1 인다이렉트 노드 블록은 상기 다이렉트 노드 블록을 가리키는 포인터를 하나 이상 포함하고, 상기 제2 인다이렉트 노드 블록은 상기 제1 인다이렉트 노드 블록을 가리키는 포인터를 하나 이상 포함하며, 상기 멀티 레벨 해쉬 테이블에 대응하는 디렉토리의 디렉토리 엔트리는 상기 데이터 블록에만 저장될 수 있다. 상기 멀티 레벨 해쉬 테이블은, 상기 스토리지 장치가 파일에 포함된 데이터를 저장하는 데 사용하는 인덱싱 구조와 동일한 인덱싱 구조에 따라 상기 스토리지 장치에 저장될 수 있다.

상기 문제점을 해결하기 위한 본 발명의 다른 면(aspect)에 따른 디렉토리 엔트리 조회 방법은 각 디렉토리의 디렉토리 엔트리(DENTRY)를 포함하는 멀티 레벨 해쉬 테이블을 저장하는 스토리지 장치를 제공하는 단계, 검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을 입력 받는 단계, 상기 검색 파일명 및 조회 레벨이 반영된 해쉬 값을 연산하고, 상기 스토리지 장치에 저장된, 상기 검색 디렉토리의 멀티 레벨 해쉬 테이블에 포함된 상기 조회 레벨의 버켓(bucket) 중 상기 해쉬 값에 대응하는 버켓에서 상기 검색 파일명을 포함하는 상기 디렉토리 엔트리를 검색하는 레벨 내 검색 단계 및 상기 검색이 실패하면 상기 조회 레벨을 증가시킨 후, 상기 레벨 내 검색 단계를 재수행하는 단계를 포함한다.

상기 디렉토리 엔트리 조회 방법은, 검색된 디렉토리 엔트리에 포함된 아이노드 식별자를 상기 파일 조회 명령을 입력한 모듈에 출력하는 단계를 더 포함할 수 있다.

상기 레벨 내 검색 단계는, 상기 파일 조회 명령을 입력 받은 후 최초 조회시에 상기 조회 레벨을 0으로 초기화하는 단계를 포함할 수 있다.

상기 문제점을 해결하기 위한 본 발명의 또 다른 면(aspect)에 따른 컴퓨터로 읽을 수 있는 기록 매체는 프로그램을 기록한 것이다. 상기 프로그램은 각 디렉토리의 디렉토리 엔트리(DENTRY)를 포함하는 멀티 레벨 해쉬 테이블을 저장하는 스토리지 장치를 제공하는 단계, 검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을 입력 받는 단계, 상기 검색 파일명 및 조회 레벨이 반영된 해쉬 값을 연산하고, 상기 스토리지 장치에 저장된, 상기 검색 디렉토리의 멀티 레벨 해쉬 테이블에 포함된 상기 조회 레벨의 버켓(bucket) 중 상기 해쉬 값에 대응하는 버켓에서 상기 검색 파일명을 포함하는 상기 디렉토리 엔트리를 검색하는 레벨 내 검색 단계 및 상기 검색이 실패하면 상기 조회 레벨을 증가시킨 후, 상기 레벨 내 검색 단계를 재수행하는 단계를 수행한다.

본 발명의 기타 구체적인 사항들은 상세한 설명 및 도면들에 포함되어 있다.

도 1은 본 발명의 일 실시예에 따른 컴퓨팅 시스템을 설명하기 위한 블록도이다.
도 2는 도 1의 호스트 장치를 설명하기 위한 블록도이다.
도 3은 도 1의 호스트 장치를 설명하기 위한 논리적 모듈 계층도이다.
도 4는 도 1의 스토리지 장치의 저장 영역 구성을 설명하기 위한 도면이다.
도 5는 도 1의 스토리지 장치에 저장 되는 데이터의 구성 단위를 설명하기 위한 도면이다.
도 6은 도 1의 스토리지 장치에 저장되는 파일의 구조를 설명하기 위한 도면이다.
도 7은 도 1의 스토리지 장치에 저장되는 디렉토리의 구조를 설명하기 위한 도면이다.
도 8은 도 7의 디렉토리에 포함된 파일 및 서브 디렉토리를 가리키는 디렉토리 엔트리의 배치를 개념적으로 설명하기 위한 도면이다.
도 9는 본 발명의 일 실시예에 따른 디렉토리 엔트리 조회 방법을 설명하기 위한 개념도이다.
도 10a 내지 10d는 도 1의 스토리지 장치에 저장되는 블록의 배치를 설명하기 위한 도면이다.
도 11은 노드 어드레스 테이블을 설명하기 위한 도면이다.
도 12 내지 도 14는 본 발명의 몇몇 실시예에 따른 컴퓨팅 시스템의 구체적인 다른 예를 설명하기 위한 블록도이다.
도 15는 본 발명의 일 실시예에 따른 디렉토리 엔트리 조회 방법의 순서도이다.

본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 것이며, 단지 본 실시예들은 본 발명의 개시가 완전하도록 하며, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

하나의 소자(elements)가 다른 소자와 "연결된(connected to)" 또는 "커플링된(coupled to)" 이라고 지칭되는 것은, 다른 소자와 직접 연결 또는 커플링된 경우 또는 중간에 다른 소자를 개재한 경우를 모두 포함한다. 반면, 하나의 소자가 다른 소자와 "직접 연결된(directly connected to)" 또는 "직접 커플링된(directly coupled to)"으로 지칭되는 것은 중간에 다른 소자를 개재하지 않은 것을 나타낸다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

예컨대, 어느 하나의 구성요소가 다른 구성요소로 데이터 또는 신호를 "전송, 제공, 송신 또는 출력"하는 경우에는 상기 구성요소는 상기 다른 구성요소로 직접 상기 데이터 또는 신호를 "전송, 제공, 송신 또는 출력"할 수 있고, 적어도 하나의 또 다른 구성요소를 통하여 상기 데이터 또는 신호를 상기 다른 구성요소로 "전송, 제공, 송신 또는 출력"할 수 있음을 의미한다.

"및/또는"은 언급된 아이템들의 각각 및 하나 이상의 모든 조합을 포함한다.

비록 제1, 제2 등이 다양한 소자, 구성요소들을 서술하기 위해서 사용되나, 이들 소자, 구성요소들은 이들 용어에 의해 제한되지 않음은 물론이다. 이들 용어들은 단지 하나의 소자, 구성요소 또는 섹션들을 다른 소자, 구성요소들과 구별하기 위하여 사용하는 것이다. 따라서, 이하에서 언급되는 제1 소자, 제1 구성요소 또는 제1 섹션은 본 발명의 기술적 사상 내에서 제2 소자, 제2 구성요소 또는 제2 섹션일 수도 있음은 물론이다.

본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다. 명세서에서 사용되는 "포함한다(comprises)" 및/또는 "포함하는(comprising)"은 언급된 구성요소, 단계, 동작 및/또는 소자는 하나 이상의 다른 구성요소, 단계, 동작 및/또는 소자의 존재 또는 추가를 배제하지 않는다.

다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있을 것이다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다.

도 1을 참조하면, 본 발명의 일 실시예에 따른 컴퓨팅 시스템(1)은 호스트 장치(10)와 스토리지 장치(20)를 포함한다.

호스트 장치(10)는 컴퓨터, UMPC (Ultra Mobile PC), 워크스테이션, 넷북(net-book), PDA (Personal Digital Assistants), 포터블(portable) 컴퓨터, 웹 타블렛(web tablet), 무선 전화기(wireless phone), 모바일 폰(mobile phone), 스마트폰(smart phone), e-북(e-book), PMP(portable multimedia player), 휴대용 게임기, 네비게이션(navigation) 장치, 블랙박스(black box), 디지털 카메라(digital camera), 3차원 수상기(3-dimensional television), 디지털 음성 녹음기(digital audio recorder), 디지털 음성 재생기(digital audio player), 디지털 영상 녹화기(digital picture recorder), 디지털 영상 재생기(digital picture player), 디지털 동영상 녹화기(digital video recorder), 디지털 동영상 재생기(digital video player), 정보를 무선 환경에서 송수신할 수 있는 장치, 홈 네트워크를 구성하는 다양한 전자 장치들 중 하나, 컴퓨터 네트워크를 구성하는 다양한 전자 장치들 중 하나, 텔레매틱스 네트워크를 구성하는 다양한 전자 장치들 중 하나, RFID 장치, 또는 컴퓨팅 시스템을 구성하는 다양한 구성 요소들 중 하나 등과 같은 전자 장치의 다양한 구성 요소들 중 하나로 제공된다.

호스트 장치(10)와 스토리지 장치(20)는 특정한 프로토콜(protocol)을 이용하여 서로 데이터를 송수신한다. 예를 들어, 호스트 장치(10)와 스토리지 장치(20)는 USB(Universal Serial Bus) 프로토콜, MMC(multimedia card) 프로토콜, PCI(peripheral component interconnection) 프로토콜, PCI-E(PCI-express) 프로토콜, ATA(Advanced Technology Attachment) 프로토콜, Serial-ATA 프로토콜, Parallel-ATA 프로토콜, SCSI (small computer small interface) 프로토콜, ESDI(enhanced small disk interface) 프로토콜, 그리고 IDE(Integrated Drive Electronics) 프로토콜 등과 같은 다양한 인터페이스 프로토콜 중 적어도 하나에 따라 통신할 수 있으나, 이에 한정되는 것은 아니다.

호스트 장치(10)는 스토리지 장치(20)를 컨트롤한다. 예를 들어, 호스트 장치(10)는 스토리지 장치(20)에 데이터를 라이트(write)하거나, 스토리지 장치(20)로부터 데이터를 리드(read)할 수 있다.

스토리지 장치(20)는 SSD(Static Solid Disk), HDD(Hard Disk Drive), eMMC와 같은 각종 카드 스토리지, 데이터 서버 등일 수 있으나, 이에 한정되지 않는다.

스토리지 장치(20)는 하나 이상의 파일을 저장하거나, 하나 이상의 디렉토리에 대한 데이터를 저장할 수 있다. 상기 디렉토리에 대한 데이터는 상기 디렉토리에 포함된 파일을 가리키는 아이노드 식별자와 상기 파일명 및 상기 디렉토리에 포함된 서브 디렉토리를 가리키는 아이노드 식별자와 상기 서브 디렉토리명을 포함할 수 있다. 하나의 디렉토리에 포함된 파일 및 서브 디렉토리 각각은 디렉토리 엔트리에 대응된다.

디렉토리 엔트리(DENTRY)는 파일명(또는 서브 디렉토리명)과 파일(또는 서브 디렉토리)을 가리키는 아이노드 식별자를 포함하는 구조체(structure)이다. 즉, 하나의 디렉토리를 가리키는 디렉토리 아이노드에는 상기 디렉토리에 포함된 파일 및 서브 디렉토리 들을 가리키는 디렉토리 엔트리들을 가리키는 포인터들이 포함되어 있고, 상기 디렉토리 아이노드에서 상기 포인트를 통하여 상기 디렉토리 엔트리들에 접근함으로써, 상기 디렉토리 내에 어떠한 파일 또는 어떠한 서브 디렉토리가 존재하는지 조회할 수 있다.

스토리지 장치(20)는 각 디렉토리의 디렉토리 엔트리를 포함하는 멀티 레벨 해쉬 테이블이 저장될 수 있다. 상기 멀티 레벨 해쉬 테이블에 대하여는 자세하게 후술하도록 한다.

도 2는 도 1에 도시된 호스트 장치(10)의 블록구성도이다.

도 2에 도시된 바와 같이 호스트 장치(10)는 스토리지 장치(20)에 대한 데이터 라이트(write)에 이용되는 후기입 캐쉬(write-back cache; WB CACHE)(104), 후기입 캐쉬(104)를 관리하는 캐쉬 관리 모듈(102), 파일 시스템 모듈(103) 및 스토리지 장치(20)와의 데이터 송수신을 중계하는 인터페이스(105)를 포함할 수 있다.

도 2에 도시된 각 구성요소는 소프트웨어(software) 또는, FPGA(field-programmable gate array)나 ASIC(application-specific integrated circuit)과 같은 하드웨어(hardware)를 의미할 수 있다. 그렇지만 상기 구성요소들은 소프트웨어 또는 하드웨어에 한정되는 의미는 아니며, 어드레싱(addressing)할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 실행시키도록 구성될 수도 있다. 상기 구성요소들 안에서 제공되는 기능은 더 세분화된 구성요소에 의하여 구현될 수 있으며, 복수의 구성요소들을 합하여 특정한 기능을 수행하는 하나의 구성요소로 구현할 수도 있다.

인터페이스(105)는 호스트 장치(10)와 스토리지 장치(20) 간의 데이터 송수신에 사용되는 상기 프로토콜을 지원하는 것일 수 있으며, 데이터 케이블 연결을 위한 커넥터 및 데이터 송수신을 처리하는 로직(logic) 등을 포함할 수 있다.

파일 시스템 모듈(103)은 검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을, 예를 들어 도 3에 도시된 가상 파일 시스템(14)으로부터 입력 받는다. 파일 시스템 모듈(103)은 상기 파일 조회 명령에 대한 응답으로, 상기 검색 파일명에 대응하는 파일의 디렉토리 엔트리에 포함된 상기 파일에 대한 아이노드 식별자를 리턴할 수 있다.

파일 시스템 모듈(103)은, 먼저 검색 디렉토리의 아이노드를 검색할 수 있다. 파일 시스템 모듈(103)은, 상기 검색 디렉토리를 파싱(parsing)하여, 상기 검색 디렉토리를 찾아가기 위하여 중간에 탐색되어야 할 서브 디렉토리들을 판정한다. 예를 들어, 상기 검색 디렉토리가 "c:\first\second\third\"인 경우, c드라이브의 루트 디렉토리에서 "first"라는 이름의 서브 디렉토리를 찾은 후, "c:\first\"에서 "second"라는 이름의 서브 디렉토리를 찾고, "c:\first\second\"에서 "third"라는 이름의 서브 디렉토리를 찾음으로써, 최종적으로 상기 검색 디렉토리의 아이노드에 접근할 수 있다. 파일 시스템 모듈(103)은 상기 검색 디렉토리를 찾는 용도로도 본 발명에 따른 디렉토리 엔트리 조회 방법을 사용할 수 있다. 다만, 설명의 편의를 위하여, 본 명세서에서는, 상기 검색 디렉토리의 아이노드가 구해진 것을 전제로 하여 상기 검색 디렉토리 내에 포함된 다수의 파일 중 상기 검색 파일명에 대응하는 파일의 디렉토리 엔트리를 어떻게 신속하게 검색하는지가 주로 설명될 것이다.

도 3을 더 참조하여, 호스트 장치(10)를 보다 자세히 설명한다. 도 3은 호스트 장치(10)를 설명하기 위한 논리적 모듈 계층도이다.

도 3을 참조하면, 호스트 장치(10)는 사용자 스페이스(user space)(11)와 커널 스페이스(kernel space)(13)를 포함한다.

사용자 스페이스(11)는 사용자 어플리케이션(user application)(12)이 실행되는 영역이고, 커널 스페이스(13)는 커널 실행 전용 영역이다. 사용자 스페이스(11)에서 커널 스페이스(13)를 접근하기 위해서, 커널이 제공하는 시스템 콜(system call)이 이용될 수 있다.

커널 스페이스(13)는 사용자 스페이스(11)의 I/O 콜 호출을 적절한 파일 시스템(16)으로 연결해주는 가상 파일 시스템(14), 호스트 장치(10)의 메모리를 관리하는 메모리 관리 모듈(15), 하나 이상의 파일 시스템(16), 스토리지 장치(20)를 제어하기 위한 하드웨어 제어 콜을 제공하는 장치 드라이버(18) 등을 포함할 수 있다. 예를 들어, 파일 시스템(16)은 ext2, ntfs, smbfs, proc 등일 수 있다. 또한, 본 발명에 따르면 파일 시스템(16) 중 하나는 본 발명에 따른 로그 구조화된 파일 시스템 기반의 F2FS 파일 시스템일 수 있다.

이하, 상기 로그 구조화된 파일 시스템에 대하여 설명한다.

로그 구조화된 파일 시스템은 하드 디스크 드라이브(Hard Disk Drive)를 사용하는 서버 스토리지 시스템에서 제안되었다. 하드 디스크 드라이브는 회전 모터를 사용하는 장치이므로, 검색 레이턴시(seek latency)와 회전 레이턴시(rotational latency)를 갖는다. 따라서, 로그 구조화된 파일 시스템은 디스크 전체를 하나의 로그(log)로 구성하여, 순차적인 라이트(sequential write)만을 한다. 즉, 로그 구조화된 파일 시스템은, 파일을 수정할 때, 원래 위치의 데이터를 수정하지 않고, 로그의 마지막 부분에 수정된 데이터를 부가한다.

따라서, 로그는 지속적으로 한방향으로 확장되며 데이터의 수정 및 부가에 따라 로그가 더 이상 확장될 수 없는 상황이 발생한다. 이 때, 로그 내에 포함 된 일부 세그먼트(빅팀 세그먼트)를 데이터가 저장될 수 있는 프리 영역으로 환원하는 세그먼트 클리닝(segment cleaning)이 요구된다. 상기 빅팀 세그먼트 내에 포함된 블록 중, 유효 데이터를 포함하는 라이브 블록은 로그의 끝에 라이트-백(write-back)되므로, 세그먼트 클리닝되더라도 데이터가 유실되지는 않는다.

가상 파일 시스템(14)은 하나 이상의 파일 시스템(16)이 서로 상호 동작할 수 있도록 한다. 서로 다른 미디어의 서로 다른 파일 시스템(16)에 대해 리드/라이트 작업을 하기 위해서, 표준화된 시스템 콜을 사용할 수 있도록 한다. 예를 들어, open(), read(), write()와 같은 시스템 콜은, 파일 시스템(16)의 종류에 관계없이 사용될 수 있다. 즉, 가상 파일 시스템(14)은 사용자 스페이스(11)와 파일 시스템(16) 사이에 존재하는 추상화 계층이다.

장치 드라이버(18)는 하드웨어와 사용자 어플리케이션(또는 운영체제) 사이의 인터페이스를 담당한다. 장치 드라이버(18)는 하드웨어가 특정 운영체제 하에서 정상적으로 동작하기 위해 필요한 프로그램이다. 장치 드라이버(18)는 인터페이스(105)를 제어할 수 있다.

도 2에 도시된 파일 시스템 모듈(103)은 상기 F2FS 파일 시스템으로 동작하는 것일 수 있다. 또한, 도 2에 도시된 캐쉬 관리 모듈(102)은 도 3에 도시된 가상 파일 시스템(14) 또는 메모리 관리 모듈(15)에 포함 된 서브-모듈일 수 있다.

이하에서, 상기 F2FS 파일 시스템이 스토리지 장치(20)를 어떻게 제어하는지를 도 4 내지 도 12를 이용하여 설명한다.

스토리지 장치(20)는 저장 수단을 구비한다. 상기 저장 수단의 저장 영역은 도 4에 도시된 것과 같이 제1 영역(30) 및 제2 영역(40)을 포함하여 구성될 수 있다. 제1 영역(30)은 랜덤 접근(random access) 방식으로 라이트 되는 영역이고, 제2 영역(40)은 순차적 접근(sequential access) 방식으로 라이트 되는 영역이다. 순차적 접근 방식의 라이트는 쓰여질 데이터를 점증하는 어드레스에 인접하여 라이트하는 것이고, 랜덤 접근 방식의 라이트는 쓰여질 데이터를 인접 여부와 무관하게 지정된 어드레스에 라이트하는 것이다.

세그먼트 클리닝이 진행됨에 따라, 로그 영역이 여러 개의 조각으로 분리될 수도 있으므로, 상기 순차적 접근 방식의 라이트는, 하나의 세그먼트 내에서 순차적 접근 방식의 라이트로 한정될 수 있다. 즉, 하나의 세그먼트 내에서는 블록이 순차적으로 라이트될 수 있다.

F2FS 파일 시스템은 포맷(format)할 때, 스토리지 장치(20)를 제1 영역(30)과 제2 영역(40)으로 나눌 수 있으나, 이에 한정되는 것은 아니다. 즉, F2FS 파일 시스템은 최초 포맷 이후에도 스토리지 장치(20)를 제1 영역(30)과 제2 영역(40)으로 나눌 수 있다. 제1 영역(30)은 시스템 전체로 관리되는 각종 정보가 저장되는 영역으로, 예를 들어, 현재 할당된 파일 수, 유효한 페이지 수, 위치, 상기 비트맵 등의 정보를 포함할 수 있다. 제2 영역(40)은 실제 사용자가 사용하고 있는 각종 디렉토리 정보, 데이터, 파일 정보 등을 저장하는 공간이다.

스토리지 장치(20)는 상기 랜덤 접근에 활용되는 버퍼를 구비할 수 있다. 상기 버퍼가 최적으로 활용되도록, 제1 영역(30)은 스토리지 장치(20)의 앞부분에 저장되고, 제2 영역(40)은 스토리지 장치(20)의 뒷부분에 저장될 수 있다. 여기서, 앞부분은 뒷부분보다 물리 어드레스(physical address)를 기준으로 앞에 있음을 의미한다.

스토리지 장치(20)가 예를 들어, SSD인 경우, SSD 내부에 버퍼(buffer)가 있을 수 있다. 버퍼는 예를 들어, 리드/라이트 속도가 빠른 SLC(Single Layer Cell) 메모리일 수 있다. 따라서, 이러한 버퍼는 한정된 공간의 랜덤 접근 방식의 라이트 속도를 빠르게 할 수 있다. 따라서, 이러한 버퍼를 활용해서, 제1 영역(30)을 스토리지 장치(20)의 앞부분에 위치시킴으로써 랜덤 억세스에 따른 스토리지 장치(20)의 I/O 속도 저하를 막을 수 있다.

제2 영역(40)은 로그 영역(41) 및 프리 영역(42)으로 구성될 수 있다. 도 4에 도시된 것과 같이, 로그 영역(41)은 하나의 연결된 영역일 수도 있으나, 세그먼트 클리닝 과정에서 로그 영역(41)에 포함 된 빅팀 세그먼트들이 프리 영역(42)으로 전환됨에 따라, 둘 이상의 조각으로 나뉠 수도 있다.

로그 영역(41)은 데이터가 쓰여진 영역이고, 프리 영역(42)은 데이터가 쓰여질 수 있는 영역이다. 제2 영역(40)은 순차적 접근 방식으로 라이트되므로, 데이터는 "로그 영역의 끝(end of log)"에 위치한 프리 영역에만 라이트 될 수 있다. 즉, "로그 영역의 끝"은 데이터가 라이트되는 지점을 가리킨다. 상기 설명한 바와 같이, 로그 영역(41)은 둘 이상의 조각으로 나뉠 수도 있으므로, "로그 영역의 끝"은 로그 영역(41) 사이에 위치하는 프리 영역(42)을 가리킬 수도 있다.

로그 영역(41)에 기 저장된 데이터가 수정될 때에도, 수정 후 데이터는 기 저장된 로그 영역(41) 내의 위치가 아니라 "로그 영역의 끝"에 위치한 프리 영역에 라이트 된다. 이 때, 기 저장 되었던 데이터는 무효 데이터가 된다.

데이터가 새로 라이트 되거나, 기 저장된 데이터가 수정됨에 따라, 로그 영역의 끝 지점은 점점 제2 영역(40)의 뒷부분으로 이동하여 프리 영역(42)이 부족해지게 된다. 이 때에 세그먼트 클리닝이 수행된다. 본 발명에 따른 세그먼트 클리닝 방법에 대하여는 추후 자세히 설명한다.

도 5는 스토리지 장치(20)에 저장 되는 데이터의 구성 단위를 설명하기 위한 도면이다.

세그먼트(SEGMENT)(53)는 다수의 블록(BLK)(51)을 포함하고, 섹션(SECTION)(55)은 다수의 세그먼트(53)를 포함하고, 존(ZONE)(57)은 다수의 섹션(55)을 포함할 수 있다. 예를 들어, 블록(51)은 4Kbyte이고, 세그먼트(53)는 512개의 블록(51)을 포함하여 2M byte일 수 있다. 이러한 구성은, 스토리지 장치(20)의 포맷(format) 시점에서 결정될 수 있으나, 이에 한정되는 것은 아니다. 섹션(55)과 존(57)의 사이즈는 포맷 시점에서 수정될 수도 있다. F2FS 파일 시스템은 모든 데이터를 4Kbyte의 페이지 단위로 리드/라이트할 수 있다. 즉, 블록(51)에 하나의 페이지가 저장되고, 세그먼트(53)에 다수의 페이지가 저장될 수 있다.

스토리지 장치(20)에 저장되는 파일은 도 6에 도시된 것과 같은, 인덱싱 구조(indexing structure)를 가질 수 있다. 본 발명에 따른 로그 구조화된 파일 시스템은 하나의 파일을 다수의 데이터와, 다수의 데이터와 연관된 다수의 노드를 포함하여 구성할 수 있다. 데이터 블록(70)은 상기 데이터를 저장하는 블록이고, 노드 블록(80, 81~88, 91~95)은 상기 노드를 저장하는 블록이다.

노드 블록(80, 81~88, 91~95)은 다이렉트 노드 블록(direct node block)(81~88), 인다이렉트 노드 블록(indirect node block)(91~95), 아이노드 블록(inode block)(80)을 포함할 수 있다. F2FS 파일 시스템에서, 하나의 파일은 하나의 아이노드 블록(80)을 가진다.

다이렉트 노드 블록(81~88)은 아이노드 블록(80)의 식별자 및 데이터 블록(70)을 직접 가리키는 데이터 포인터(data pointer)를 다이렉트 노드 블록(81~88)의 자식 블록인 데이터 블록의 수만큼 포함한다. 다이렉트 노드 블록(81~88)은 각 데이터 블록(70)이, 아이노드 블록(80)에 대응되는 파일 내에서 몇번째 블록인지에 대한 정보, 즉 블록의 오프셋 정보를 더 저장한다.

인다이렉트 노드 블록(91~95)은 다이렉트 노드 블록 또는 다른 인다이렉트 노드 블록을 가리키는 포인터를 포함한다. 인다이렉트 노드 블록(91~95)은 예를 들어, 제1 인다이렉트 노드 블록(91~94), 제2 인다이렉트 노드 블록(95) 등을 포함할 수 있다. 제1 인다이렉트 노드 블록(91~94)은 다이렉트 노드 블록(83~88)을 가리키는 제1 노드 포인터를 포함한다. 제2 인다이렉트 노드 블록(95)은 제1 인다이렉트 노드 블록(93, 94)을 가리키는 제2 노드 포인터를 포함한다.

아이노드 블록(80)은 데이터 포인터, 다이렉트 노드 블록(81, 82)를 가리키는 제1 노드 포인터, 제1 인다이렉트 노드 블록(91, 92)을 가리키는 제2 노드 포인터, 제2 인다이렉트 노드 블록(95)를 가라키는 제3 노드 포인터 중 적어도 하나를 포함할 수 있다. 하나의 파일은 예를 들어, 최대 3Tbyte일 수 있고, 이러한 대용량의 파일은 다음과 같은 인덱스 구조를 가질 수 있다. 예를 들어, 아이노드 블록(80) 내의 데이터 포인터는 994개이고, 994개의 데이터 포인터 각각은 994개의 데이터 블록(70) 각각을 가리킬 수 있다. 제1 노드 포인터는 2개이고, 2개의 제1 노드 포인터 각각은 2개의 다이렉트 노드 블록(81, 82)를 가리킬 수 있다. 제2 노드 포인터는 2개이고, 2개의 제2 노드 포인터 각각은 2개의 제1 인다이렉트 노드 블록(91, 92)을 가리킬 수 있다. 제3 노드 포인터는 1개이고, 제2 인다이렉트 노드 블록(95)를 가리킬 수 있다.

스토리지 장치(20)에 저장되는 디렉토리는 도 7에 도시된 것과 같은, 인덱싱 구조(indexing structure)를 가질 수 있다. 도 7에 도시된 것과 같이, 디렉토리에 포함된 디렉토리 엔트리를 저장하기 위한 인덱싱 구조는 도 6에 도시된 파일 데이터 저장을 위한 인덱싱 구조와 동일할수 있다. 즉, 하나의 디렉토리는 하나의 아이노드(80)에 대응하고, 아이노드(80)를 통하여 접근할 수 있는 디렉토리 엔트리는 데이터 블록(70)에 저장된다. 파일의 인덱싱 구조와 동일하게, 데이터 블록(70) 중 일부(제1 데이터 블록)는 아이노드(80)로부터 바로 접근할 수도 있고, 다른 일부(제2 데이터 블록)는 아이노드(80)로부터 다이렉트 노드(81, 82)를 경유하여 접근할 수도 있으며, 또 다른 일부(제3 데이터 블록)는 아이노드(80)로부터 제1 인다이렉트 노드(91, 92) 및 다이렉트 노드(83, 84, 85, 86)를 순차로 경유하여 접근할 수도 있으며, 또 다른 일부(제4 데이터 블록)는 아이노드(80)로부터 제2 인다이렉트 노드(95), 제1 인다이렉트 노드(93, 94) 및 다이렉트 노드(87, 88)를 순차로 경유하여 접근할 수도 있다.

이때, 각각의 데이터 블록 숫자는 아래와 같다.

제4 데이터 블록 > 제3 데이터 블록 > 제2 데이터 블록 > 제1 데이터 블록

도 8은 노드 블록을 제외하고, 디렉토리의 아이노드(80)로부터 디렉토리 엔트리가 어떻게 배치되는지를 개념적으로 나타낸 도면이다. 도 8에서 디렉토리 엔트리 #1과 디렉토리 엔트리 #2 사이에 빈 공간이 도시되어 있는데, 이는 삭제 또는 갱신으로 인하여 로그 영역 내에 무효 데이터 블록들이 존재할 수 있음을 나타낸다. 만약 디렉토리의 아이노드(80)가 가리키는 디렉토리에 신규 파일이 생성되는 경우, 디렉토리 엔트리 #1과 디렉토리 엔트리 #2 사이의 빈 공간에 상기 신규 파일에 대응하는 디렉토리 엔트리가 라이트될 수 있을 것이다.

도 7에 도시된, 스토리지 장치(20)에 저장되는 디렉토리의 인덱싱 구조는 본 발명에 따른 멀티-레벨 해쉬 테이블로도 사용될 수 있다. 즉, 본 발명에 따르면 디렉토리에 포함된 디렉토리 엔트리들을 스토리지 장치(20)에 저장하되, 멀티-레벨 해쉬 테이블로도 사용될 수 있도록, 사전이 정의된 규칙에 따른 위치에 저장함으로써, 추후 상기 디렉토리 엔트리를 조회할 때 신속하게 조회할 수 있도록 한다. 즉, 본 발명에 따르면, 디렉토리에 포함된 디렉토리 엔트리를 조회하기 위한 별도의 데이터 구조를 관리하지 않고도, 디렉토리 엔트리를 신속하게 조회할 수 있는 효과가 있다. 이와 관련하여, 도 9를 참조하여 보다 자세히 설명한다.

도 9는 도 7에 도시된 디렉토리 엔트리의 인덱싱 구조를 멀티-레벨 해쉬 테이블로 해석하는 경우의 설명을 돕기위한 개념도이다.

도 9에 도시된 바와 같이, 본 발명에 따른 멀티 레벨 해쉬 테이블은 각 레벨 별로 하나 이상의 버킷이 포함된다. 레벨이 증가할수록 버킷의 수도 같이 증가한다. 예를 들어, 레벨 A의 버켓 수는 MA(M = 기지정된 베이스로써, 2이상의 자연수)일 수 있다. 이 때, 도 7에 도시된 인덱싱 구조에 부합하도록 상기 멀티 레벨 해쉬 테이블이 구성되어야 하므로, M은 각 노드 블록이 가지는 포인터의 수에 비례하는 값으로 정해질 수 있다.

하나의 버킷 안에는 기 지정된 수의 블록이 포함될 수 있다. 도 9에는 하나의 버킷 안에 2개의 블록이 포함되는 것이 도시되어 있다. 그러나, 본 발명은 하나의 버킷 안에 2개의 블록이 포함되는 것에 한정되지 않는다. 이 때, 도 7에 도시된 인덱싱 구조에 부합하도록 상기 멀티 레벨 해쉬 테이블이 구성되어야 하므로, 하나의 버킷 안에 포함되는 블록의 수는, 하나의 노드 블록를 통하여 접근할 수 있는 데이터 블록의 수에 비례하는 값으로 정해질 수 있다.

또한, 하나의 블록 안에는 기 지정된 수의 디렉토리 엔트리 슬롯이 포함될 수 있다. 하나의 디렉토리 엔트리는 하나의 디렉토리 엔트리 슬롯으로 구성될 수도 있으나, 둘 이상의 디렉토리 엔트리 슬롯으로 구성될 수도 있다.

하나 이상의 디렉토리 엔트리 슬롯으로 디렉토리 엔트리를 구성하는 이유는, 디렉토리 엔트리에 포함되는 파일명 또는 서브 디렉토리명의 길이가 고정된 것이 아니기 때문이다. 만약 파일명 또는 서브 디렉토리명이 가질 수 있는 최대 길이를 미리 할당해 놓는다면, 대다수의 파일 또는 서브 디렉토리는 상기 최대 길이보다 훨씬 짧은 명칭을 가지므로, 저장공간의 낭비가 심할 것이다. 따라서, 상기 최대 길이보다 작은 데이터 사이즈를 파일 또는 서브 디렉토리의 명칭을 위한 저장 공간으로 가지는 고정된 데이터 사이즈의 디렉토리 엔트리 슬롯을 기 지정된 수만큼 하나의 블록 안에 포함시키고, 디렉토리 엔트리 슬롯에 포함된 파일 명칭 또는 서브 디렉토리 명칭 저장 공간이 부족한 경우, 다음 디렉토리 엔트리 슬롯을 더 이용함으로써, 상기 저장공간 낭비 문제를 해결할 수 있다.

예를 들어, 두개 이상의 디렉토리 엔트리 슬롯이 하나의 디렉토리 엔트리를 구성하는 경우, 상기 디렉토리 엔트리를 구성하는 디렉토리 엔트리 슬롯에 포함된 파일명 저장 영역에 저장된 문자열 전체가 연결되어 상기 디렉토리 엔트리에 대응되는 파일의 파일명이 형성될 것이다.

이미 설명한 바와 같이, 스토리지 장치(20)에 저장되는 디렉토리의 인덱싱 구조가 본 발명에 따른 멀티-레벨 해쉬 테이블로도 사용될 수 있도록, 각 버켓에 포함된 블록들은 레벨 0의 버켓#0으로부터, 버켓의 오프셋 및 레벨을 증가시켜가며 순차적으로 저장된다. 예를 들어, 도 9에 도시된 바와 같이, 스토리지 장치(20)에는 레벨 0의 블록#0과 블록#1, 레벨 1의 블록#2, #3, empty 블록, 블록 #4, 레벨 2의 블록 #5, empty 블록, 블록 #6 내지 #9가 도 7에 도시된 것과 같은 인덱싱 구조에 따라 저장될 수 있다.

이하, 도 9를 참조하여, 본 발명의 일 실시예에 따라 F2FS 파일 시스템이 상기 멀티 레벨 해쉬 테이블을 참조하여 디렉토리 엔트리를 조회하는 것을 설명한다. 상기 멀티 레벨 해쉬 테이블은 상기 디렉토리 엔트리 이외의 데이터를 포함하지 않는 점에서, 디렉토리 엔트리가 저장된 인덱싱 구조와 동일한 것을 지칭한다. 따라서, 상기 멀티 레벨 해쉬 테이블은, 상기 멀티 레벨 해쉬 테이블에 대응하는 디렉토리의 아이노드를 루트로 하는 트리 구조의 인덱싱 구조에 따라 저장되는 것일 수 있다. 상기 아이노드는, 데이터 블록을 가리키는 포인터, 다이렉트 노드 블록을 가리키는 포인터, 제1 인다이렉트 노드 블록을 가리키는 포인터, 제2 인다이렉트 노드 블록을 가라키는 포인터 중 적어도 하나를 포함하고, 상기 다이렉트 노드 블록은 데이터 블록을 가리키는 포인터를 하나 이상 포함하고, 상기 제1 인다이렉트 노드 블록은 상기 다이렉트 노드 블록을 가리키는 포인터를 하나 이상 포함하고, 상기 제2 인다이렉트 노드 블록은 상기 제1 인다이렉트 노드 블록을 가리키는 포인터를 하나 이상 포함하며, 상기 멀티 레벨 해쉬 테이블에 대응하는 디렉토리의 디렉토리 엔트리는 상기 데이터 블록에만 저장된다.

F2FS 파일 시스템은 해쉬 값을 얻기 위한 해쉬 함수로써, 상기 검색 파일명 및 조회 레벨이 모두 반영된 해쉬 함수를 사용한다. 상기 조회 레벨은, 현 단계에서의 멀티 레벨 해쉬 테이블 내 레벨을 의미하는 것으로, 0으로부터 시작하여 해당 레벨에서 조회를 실패할 때마다 1씩 증가한다. 상기 해쉬 함수는 아래와 같다.

버켓 오프셋 = hash("검색 파일명") % 조회 레벨에서의 버켓 수

즉, 조회 레벨에서 찾아보아야할 버켓의 오프셋은 검색 파일명에 해쉬 함수를 적용한 해쉬 값을 그 레벨에서의 버켓 수로 나눈 값으로 정해질 수 있다. 즉, 각 레벨의 버켓은 zero-base 오프셋으로 접근되고, 상기 해쉬 값은 버켓 오프셋으로 사용될 수 있다.

예를 들어, "READ.me" 파일이 검색 파일명인 경우, 레벨 0에서는 버켓 0을 찾아본 결과, "READ.me"를 파일명으로 저장하는 디렉토리 엔트리가 검색되지 않아, 레벨 1로 넘어가고, 레벨 1에서 버켓 오프셋이 0으로 정해진 결과, 버켓 0을 찾아봐서 "READ.me"를 파일명으로 저장하는 디렉토리 엔트리를 찾게될 것이다.

도 9에 도시된 해쉬 테이블은 레벨이 증가할수록 버켓의 수가 증가하지만, 해당 레벨에서의 해쉬 함수 역시 상기 증가된 버켓의 수를 반영하므로, 특정 레벨에서 히트된 버켓의 오프셋을 O(1) 시간 내에 찾을 수 있다. 또한, 도 7에 도시된 인덱싱 구조에 따라 상기 해쉬 테이블을 저장함으로써, 레벨이 증가할수록 하나의 레벨에 포함되는 버켓의 수도 증가시킬 수 있으므로, 하나의 디렉토리에 포함되는 디렉토리 엔트리의 숫자(N)가 증가하더라도 O(logN) 시간 내에 디렉토리 엔트리를 찾을 수 있는 효과가 있다.

도 10a 내지 10d는, 본 발명의 몇몇 실시예들에 따라, F2FS 파일 시스템이 구성하는 스토리지 장치(20)의 저장 영역 구성을 보다 자세하게 도시한 것이다.

먼저, 일 실시예에 따르면, 상기 F2FS 파일 시스템은 스토리지 장치(20)의 저장 영역을 랜덤 접근 방식의 제1 영역(30) 및 순차적 접근 방식의 제2 영역(40)을 포함하도록 도 10a에 도시된 것과 같이 구성할 수 있다.

구체적으로, 제1 영역(30)은 슈퍼블록(61, 62), 체크 포인트 영역(CheckPoint area, CP)(63), 세그먼트 정보 테이블(Segment Information Table, SIT)(64), 노드 어드레스 테이블(Node Address Table, NAT)(65), 세그먼트 요약 영역(Segment Summary Area, SSA)(66) 등을 포함할 수 있다.

먼저, 슈퍼블록(61, 62)에는, 파일 시스템(16)의 디폴트 정보가 저장된다. 예를 들어, 블록(51)의 크기, 블록(51)의 개수, 파일 시스템(16)의 상태 플러그(clean, stable, active, logging, unknown) 등이 저장될 수 있다. 도시된 것과 같이, 슈퍼블록(61, 62)은 2개일 수 있고, 각각에는 동일한 내용이 저장될 수 있다. 따라서, 둘 중 어느 하나에 문제가 발생하더라도, 다른 하나를 이용할 수 있다.

체크 포인트 영역(63)은 체크 포인트를 저장한다. 체크 포인트는 논리적인 중단점으로서, 이러한 중단점까지의 상태가 완전하게 보존된다. 컴퓨팅 시스템의 동작 중에 사고(예를 들어, 셧다운(shutdown))가 발생하면, 파일 시스템(16)은 보존된 체크 포인트를 이용하여 데이터를 복구할 수 있다. 이러한 체크 포인트의 생성 시점은, 예를 들어, 주기적으로 생성, Umount 시점, System shutdown 시점 등일 수 있으나, 이에 한정되는 것은 아니다.

도 11에 도시된 것과 같이, 노드 어드레스 테이블(65)은 노드 각각에 대응되는 다수의 노드 식별자(NODE ID)와, 다수의 노드 식별자 각각에 대응되는 다수의 물리 어드레스(physical address)를 포함할 수 있다. 예를 들어, 노드 식별자 N0에 대응되는 노드 블록은 물리 어드레스 a에 대응되고, 노드 식별자 N1에 대응되는 노드 블록은 물리 어드레스 b에 대응되고, 노드 식별자 N2에 대응되는 노드 블록은 물리 어드레스 c에 대응될 수 있다. 모든 노드(아이노드, 다이렉트 노드, 인다이렉트 노드 등)는 각각 고유의 노드 식별자를 갖는다. 다르게 설명하면, 모든 노드(아이노드, 다이렉트 노드, 인다이렉트 노드 등)는 노드 어드레스 테이블(65)로부터 고유의 노드 식별자를 할당 받을 수 있다. 노드 어드레스 테이블(65)은 아이노드의 노드 식별자, 다이렉트 노드의 노드 식별자 및 인다이렉트 노드의 노드 식별자 등을 저장할 수 있다. 각 노드 식별자에 대응되는 각 물리 어드레스는 업데이트(update)될 수 있다.

세그먼트 정보 테이블(Segment Information Table)(64)은 각 세그먼트 내에 포함 된 라이브 블록의 개수와, 각 블록이 라이브 블록인지 여부를 나타내는 비트맵을 포함할 수 있다. 비트맵을 구성하는 각 비트는 대응 되는 각 블록이 라이브 블록인지 여부를 나타낸다. 세그먼트 정보 테이블(64)은 세그먼트 클리닝 작업에서 사용될 수 있다. 즉, 파일 시스템 모듈(103)은 빅팀 세그먼트 내에 포함 된 라이브 블록을 식별하기 위하여 세그먼트 정보 테이블(64)에 포함 된 상기 비트맵을 참조할 수 있다.

세그먼트 정보 테이블(64)은 빅팀 세그먼트를 선정하는 용도로도 참조될 수 있다. 즉, 세그먼트 내에 포함된 블록들 중 라이브 블록의 갯수가 몇 개인지 또는 라이브 블록의 비율이 몇 개인지에 따라 상기 빅팀 세그먼트가 선정될 수 있다.

세그먼트 요약 영역(Segment Summary Area)(66)은 제2 영역(40)의 각 세그먼트에 포함 된 각 블록이 속하는 부모 노드의 식별자를 기술한다.

다이렉트 노드 블록(81~88)은 자신의 자식 블록인 데이터 블록(70)에 대한 접근을 위하여, 각 데이터 블록(70)의 어드레스 정보를 가진다. 반면, 인다이렉트 노드 블록(91~95)은 자신의 자식 노드 블록에 대한 접근을 위하여, 자신의 각 자식 노드의 식별자 목록을 가진다. 특정 노드 블록의 식별자를 알게 되면, 노드 어드레스 테이블(65)을 조회하여 그 물리 어드레스도 알 수 있다.

한편, 로그 구조화된 파일시스템에서는 데이터 블록에 쓰여진 데이터를 기존의 저장 위치에서 다른 값으로 오버라이트(overwrite)하지 않고, 로그 끝에 갱신 된 데이터를 가진 새로운 데이터 블록을 라이트하는 방식을 취한다. 따라서, 기존 데이터 블록의 부모 노드 블록 역시 데이터 블록에 대한 어드레스를 수정해야 한다. 따라서, 특정 데이터 블록을 오버라이트하거나, 세그먼트 클리닝 단계에서 로그 끝으로 라이트-백 하는 경우, 그 데이터 블록의 부모 노드에 대한 정보가 필요하다. 그러나, 각 데이터 블록 또는 각 노드 블록은 자신의 부모 노드에 대한 정보를 알기 어렵다. 따라서, 본 발명에 따른 F2FS 파일 시스템은 각 데이터 블록 또는 각 노드 블록이 자신의 부모 노드 블록의 식별자를 확인할 수 있는 인덱스(index)가 기재된 세그먼트 요약 영역(66)을 두어, 데이터 블록 또는 노드 블록이 부모 노드 블록의 식별자를 쉽게 알 수 있도록 한다.

하나의 세그먼트 요약 블록은, 제2 영역(40)에 위치한 하나의 세그먼트에 대한 정보를 가지고 있다. 또한, 세그먼트 요약 블록은 다수의 요약 정보로 구성되어 있으며, 하나의 요약 정보는 하나의 데이터 블록 또는 하나의 노드 블록에 대응된다.

제2 영역(40)은 도 10a에 도시된 바와 같이, 서로 분리된 데이터 세그먼트(data segment)(DS0, DS1)과 노드 세그먼트(node segment)(NS0, NS1)을 포함할 수 있다. 다수의 데이터는 데이터 세그먼트(DS0, DS1)에 저장되고, 다수의 노드는 노드 세그먼트(NS0, NS1)에 저장될 수 있다. 데이터와 노드가 분리되는 영역이 서로 다르면, 효율적으로 세그먼트를 관리할 수 있고, 데이터를 리드할 때 보다 효과적으로 빠른 시간 내에 리드할 수 있다.

도면에서는, 제1 영역(30)은 슈퍼블록(61, 62), 체크 포인트 영역(62), 세그먼트 정보 테이블(64), 노드 어드레스 테이블(65), 세그먼트 요약 영역(66) 순서로 되어 있으나, 이에 한정되는 것은 아니다. 예를 들어, 세그먼트 정보 테이블(64)과 노드 어드레스 테이블(65)의 위치가 바뀌어도 무방하고, 노드 어드레스 테이블(65)과 세그먼트 요약 영역(66)의 위치가 바뀌어도 무방하다.

F2FS 파일 시스템은 스토리지 장치(20)의 저장 영역을 도 10b에 도시된 것과 같이 구성할 수도 있다. 도 10b를 참조하면, 본 발명의 다른 실시예에 따른 컴퓨팅 시스템의 스토리지 장치에서, 제2 영역(40)은 서로 분리된 다수의 세그먼트(S1~Sn, 단, n은 자연수)를 포함할 수 있다. 각 세그먼트(S1~Sn)에는, 데이터와 노드 구분없이 저장될 수 있는 점에서, 데이터 세그먼트와 노드 세그먼트가 별도로 관리되는 도 10a와 다르다.

F2FS 파일 시스템은 스토리지 장치(20)의 저장 영역을 도 10c에 도시된 것과 같이 구성할 수도 있다. 도 10c를 참조하면, 제1 영역(30)은 세그먼트 요약 영역(도 10a의 66 참조)을 포함하지 않는다. 즉, 제1 영역(30)은 슈퍼블록(61, 62), 체크 포인트 영역(62), 세그먼트 정보 테이블(64), 노드 어드레스 테이블(65)을 포함한다. 대신, 세그먼트 요약 정보는 제2 영역(40)내에 저장될 수 있다. 구체적으로, 제2 영역(40)은 다수의 세그먼트(S0~Sn)를 포함하고, 각 세그먼트(S0~Sn)는 다수의 블록으로 구분된다. 각 세그먼트(S0~Sn)의 적어도 하나의 블록(SS0~SSn)에 세그먼트 요약 정보가 저장될 수 있다.

F2FS 파일 시스템은 스토리지 장치(20)의 저장 영역을 도 10d에 도시된 것과 같이 구성할 수도 있다. 도 10d를 참조하면, 도 10c와 마찬가지로, 제1 영역(30)은 세그먼트 요약 영역(도 10a의 66 참조)을 포함하지 않는다. 즉, 제1 영역(30)은 슈퍼블록(61, 62), 체크 포인트 영역(62), 세그먼트 정보 테이블(64), 노드 어드레스 테이블(65)을 포함한다. 세그먼트 요약 정보는 제2 영역(40) 내에 저장될 수 있다. 제2 영역(40)은 다수의 세그먼트(53)를 포함하고, 각 세그먼트(53)는 다수의 블록(BLK0~BLKm)으로 구분되고, 각 블록(BLK0~BLKm)은 OOB(Out Of Band)(OOB1~OOBm, 단, m은 자연수) 영역을 포함할 수 있다. OOB 영역(OOB1~OOBm)에 세그먼트 요약 정보를 저장할 수 있다.

도 12 내지 도 14는 본 발명의 몇몇 실시예에 따른 컴퓨팅 시스템의 구체적인 다른 예를 설명하기 위한 블록도이다.

우선, 도 12를 참조하면, 스토리지 장치(20)는 비휘발성 메모리 장치(22) 및 컨트롤러(21)를 포함할 수 있다.

비휘발성 메모리 장치(22)는 컨트롤러(21)의 제어에 따라 데이터를 리드/라이트(read/write)하고, 랜덤 접근(random access) 방식으로 라이트(write)되는 제1 영역(30) 및 순차적 접근(sequential access) 방식으로, 복수의 블록으로 구성되는 복수의 세그먼트가 라이트 되는 제2 영역(40)으로 저장 영역이 구성된다. 제2 영역(40)은 상기 복수의 세그먼트가 저장 된 로그 영역 및 세그먼트가 저장 될 수 있는 프리 영역으로 구성되고, 제1 영역(30)에는 제2 영역(40)에 저장된 데이터에 대한 메타 데이터가 저장되고, 상기 메타 데이터는 대응 블록의 라이브 여부를 가리키는 비트맵(640)을 포함한다. 비트맵(640)은 세그먼트 클리닝 프로세스에서 빅팀 세그먼트(victim segment) 내의 라이브 블록(live block)을 식별하기 위해 참조되는 데이터이다.

여기서, 비휘발성 메모리 장치(22)의 제1 영역(30)에는, 전술한 슈퍼블록(61, 62), 체크 포인트 영역(63), 세그먼트 정보 테이블(64), 노드 어드레스 테이블(65) 등이 상기 메타 데이터로써 저장되어 있을 수 있다. 세그먼트 정보 테이블(64)에는 비트맵(640)이 포함된다.

비트맵(640)을 구성하는 비트와 상기 블록은 일대일 대응한다.

컨트롤러(21)는 호스트 장치(10) 및 비휘발성 메모리 장치(22)에 연결된다. 호스트 장치(10)로부터의 요청에 응답하여, 컨트롤러(21)는 비휘발성 메모리 장치(22)를 액세스하도록 구성된다. 예를 들면, 컨트롤러(21)는 비휘발성 메모리 장치(22)의 리드, 라이트, 이레이즈, 그리고 백그라운드(background) 동작을 제어하도록 구성된다. 컨트롤러(21)는 비휘발성 메모리 장치(22) 및 호스트(Host) 사이에 인터페이스를 제공하도록 구성된다. 컨트롤러(21)는 비휘발성 메모리 장치(22)를 제어하기 위한 펌웨어(firmware)를 구동하도록 구성된다.

컨트롤러(21)는, 상기 세그먼트 클리닝 프로세스의 진행 중, 호스트 장치(10)의 제어에 따라 상기 로그 영역의 끝에 위치한 프리 영역에 상기 라이브 블록으로 구성 된 클린 세그먼트를 라이트-백하고, 비트맵(640)을 업데이트 하되, 상기 비트맵에 포함된 비트 중, 상기 빅팀 세그먼트 내의 라이브 블록 위치에 대응하는 비트를 무효 블록을 의미하는 값으로 세팅하고, 비트맵(640)에 포함된 비트 중, 상기 클린 세그먼트 내의 라이브 블록 위치에 대응하는 비트를 라이브 블록을 의미하는 값으로 세팅할 수 있다.

예시적으로, 컨트롤러(21)는 램(RAM, Random Access Memory), 프로세싱 유닛(processing unit), 호스트 인터페이스(host interface), 그리고 메모리 인터페이스(memory interface)와 같은 잘 알려진 구성 요소들을 더 포함한다. 램(RAM)은 프로세싱 유닛의 동작 메모리, 비휘발성 메모리 장치(22) 및 호스트 장치(10) 사이의 캐쉬 메모리, 그리고 비휘발성 메모리 장치(22) 및 호스트 장치(10) 사이의 버퍼 메모리 중 적어도 하나로서 이용된다. 프로세싱 유닛은 컨트롤러(21)의 제반 동작을 제어한다.

컨트롤러(21)는 버퍼(210)를 구비한 것일 수 있다. 버퍼(210)는 예를 들어 램(RAM, Random Access Memory), 특히 D램으로 구성될 수 있다.

컨트롤러(21) 및 비휘발성 메모리 장치(22)는 하나의 반도체 장치로 집적될 수 있다. 예시적으로, 컨트롤러(21) 및 비휘발성 메모리 장치(22)는 하나의 반도체 장치로 집적되어, 메모리 카드를 구성할 수 있다. 예를 들면, 컨트롤러(21) 및 비휘발성 메모리 장치(22)는 하나의 반도체 장치로 집적되어 PC 카드(PCMCIA, personal computer memory card international association), 컴팩트 플래시 카드(CF), 스마트 미디어 카드(SM, SMC), 메모리 스틱, 멀티미디어 카드(MMC, RS-MMC, MMCmicro), SD 카드(SD, miniSD, microSD, SDHC), 유니버설 플래시 기억장치(UFS) 등과 같은 메모리 카드를 구성할 것이다.

컨트롤러(21) 및 비휘발성 메모리 장치(22)는 하나의 반도체 장치로 집적되어 SSD(Solid State Drive)를 구성할 수 있다. SSD는 반도체 메모리에 데이터를 저장하도록 구성되는 저장 장치를 포함한다. 호스트 장치(10)에 SSD가 연결되는 경우, 호스트 장치(10)의 동작 속도는 획기적으로 개선될 수 있다.

예시적으로, 비휘발성 메모리 장치(22) 또는 스토리지 장치(20)는 다양한 형태들의 패키지로 실장될 수 있다. 예를 들면, 비휘발성 메모리 장치(22) 또는 스토리지 장치(20)는 PoP(Package on Package), Ball grid arrays(BGAs), Chip scale packages(CSPs), Plastic Leaded Chip Carrier(PLCC), Plastic Dual In Line Package(PDIP), Die in Waffle Pack, Die in Wafer Form, Chip On Board(COB), Ceramic Dual In Line Package(CERDIP), Plastic Metric Quad Flat Pack(MQFP), Thin Quad Flatpack(TQFP), Small Outline(SOIC), Shrink Small Outline Package(SSOP), Thin Small Outline(TSOP), Thin Quad Flatpack(TQFP), System In Package(SIP), Multi Chip Package(MCP), Wafer-level Fabricated Package(WFP), Wafer-Level Processed Stack Package(WSP) 등과 같은 방식으로 패키지화되어 실장될 수 있다.

이어서, 도 13을 참조하면, 스토리지 장치(20)는 비휘발성 메모리 장치(24) 및 컨트롤러(23)를 포함할 수 있다. 비휘발성 메모리 장치(24)는 복수의 비휘발성 메모리 칩들을 포함한다. 복수의 비휘발성 메모리 칩들은 복수의 그룹들로 분할된다. 복수의 비휘발성 메모리 칩들의 각 그룹은 하나의 공통 채널을 통해 컨트롤러(23)와 통신하도록 구성된다. 예를 들어, 복수의 비휘발성 메모리 칩들은 제 1 내지 제 k 채널들(CH1~CHk)을 통해 컨트롤러(23)와 통신하는 것으로 도시되어 있다.

도 13에서, 하나의 채널에 복수의 비휘발성 메모리 칩들이 연결되는 것으로 설명되었다. 그러나, 하나의 채널에 하나의 비휘발성 메모리 칩이 스토리지 장치(20)가 변형될 수 있음이 이해될 것이다.

이어서, 도 14를 참조하면, 시스템(3000)은 중앙 처리 장치(3100), 램(3200, RAM, Random Access Memory), 사용자 인터페이스(3300), 전원(3400), 그리고 도 12의 스토리지 장치(20)를 포함할 수 있다.

시스템(3000)은 시스템 버스(3500)를 통해, 중앙처리장치(3100), 램(3200), 사용자 인터페이스(3300), 그리고 전원(3400)에 전기적으로 연결된다. 사용자 인터페이스(3300)를 통해 제공되거나, 중앙 처리 장치(3100)에 의해서 처리된 데이터는 시스템(3000)에 저장된다.

도 14에서, 비휘발성 메모리 장치(24)는 컨트롤러(23)를 통해 시스템 버스(3500)에 연결되는 것으로 도시되어 있다. 그러나, 비휘발성 메모리 장치(24)는 시스템 버스(3500)에 직접 연결되도록 구성될 수도 있다.

이하, 본 발명의 일 실시예에 따른 디렉토리 엔트리 조회 방법에 대하여 도 15를 참조하여 설명한다.

본 실시예에 따른 디렉토리 엔트리 조회 방법은 도 7에 도시된 인덱싱 구조에 따라 디렉토리 엔트리가 저장된 스토리지 장치에 저장된 디렉토리 엔트리를 조회한다.

우선, 검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을 입력 받는다.

다음으로, 상기 검색 파일명에 해쉬 함수를 적용한 해쉬 값(H)을 얻는다(S100). 상기 해쉬 함수는 이미 알려진 소정의 해쉬 함수 중 하나가 사용될 수 있다. 초기화로써, 조회 레벨을 0으로 세팅한다(S102).

다음으로, 상기 해쉬 값과 상기 조회 레벨이 반영된 버켓 오프셋을 연산한다(S104).

다음으로, 상기 스토리지 장치에 저장된, 상기 검색 디렉토리의 멀티 레벨 해쉬 테이블에 포함된 상기 조회 레벨의 버켓(bucket) 중 상기 해쉬 값에 대응하는 버켓에서 상기 검색 파일명을 포함하는 상기 디렉토리 엔트리를 검색(S106)한다.

상기 검색이 성공하면, 검색된 디렉토리 엔트리에 포함된 아이노드 식별자를 리턴한다(S110). 반면에, 상기 검색이 실패하면 상기 조회 레벨을 증가(S108)시킨 후, 레벨 내 검색 단계(S104, S106)를 재수행한다. 마지막 레벨에서도 검색을 실패하는 경우(S112), 조회 실패 코드(예를 들어, -1)을 리턴한다(S114).

본 발명의 일 실시예에 따른 컴퓨터로 읽을 수 있는 기록 매체는 본 발명에 따른 상기 디렉토리 엔트리 조회 방법을 수행하기 위한 프로그램이 기록된 것일 수 있다. 상기 프로그램은 운영 체제의 일부로써 사용되는 파일 시스템 모듈일 수 있다. 본 발명의 일 실시예에 따른 호스트 장치는 상기 프로그램을 설치한 것일 수 있다.

이상 첨부된 도면을 참조하여 본 발명의 실시예를 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적이 아닌 것으로 이해해야만 한다.

Claims (10)

1. 각 디렉토리의 디렉토리 엔트리(DENTRY)를 포함하는 멀티 레벨 해쉬 테이블을 저장하는 스토리지 장치와의 데이터 송수신을 중계하는 인터페이스; 및
   검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을 입력 받고, 상기 검색 파일명 및 조회 레벨이 반영된 해쉬 값을 연산하고, 상기 검색 디렉토리의 멀티 레벨 해쉬 테이블에 포함된 상기 조회 레벨의 버켓(bucket) 중 상기 해쉬 값에 대응하는 버켓에서 상기 검색 파일명을 포함하는 상기 디렉토리 엔트리를 검색하는 파일 시스템 모듈을 포함하되,
   상기 파일 시스템 모듈은 상기 검색이 실패하면 상기 조회 레벨을 증가시켜 상기 해쉬 값 연산 및 상기 검색 파일명 검색을 재수행하는, 호스트 장치.
2. 제1 항에 있어서,
   상기 멀티 레벨 해쉬 테이블에 포함된 각 레벨의 버켓은 zero-base 오프셋으로 접근되고, 상기 해쉬 값은 버켓 오프셋으로 사용되는, 호스트 장치.
3. 제1 항에 있어서,
   상기 멀티 레벨 해쉬 테이블에 포함된 모든 버켓은 N(N=2이상의 기 지정된 자연수) 개의 블록을 포함하고, 하나의 블록의 데이터 사이즈는 기 지정된 것인, 호스트 장치.
4. 제3 항에 있어서,
   상기 블록 하나에는 기 지정된 개수의 디렉토리 엔트리 슬롯이 포함되고,
   하나 이상의 상기 디렉토리 엔트리 슬롯은 하나의 디렉토리 엔트리를 구성하는, 호스트 장치.
5. 제4 항에 있어서,
   상기 각각의 디렉토리 엔트리 슬롯은 파일 아이노드 식별자 저장영역과 기 지정된 사이즈의 파일명 저장 영역을 포함하고,
   두개 이상의 디렉토리 엔트리 슬롯이 하나의 디렉토리 엔트리를 구성하는 경우, 상기 디렉토리 엔트리를 구성하는 디렉토리 엔트리 슬롯에 포함된 파일명 저장 영역에 저장된 문자열 전체가 연결되어 상기 디렉토리 엔트리에 대응되는 파일의 파일명이 형성되는, 호스트 장치.
6. 제1 항에 있어서,
   상기 멀티 레벨 해쉬 테이블에 포함된 각 레벨의 버켓 수는 레벨이 증가할 수록 증가하는, 호스트 장치.
7. 제6 항에 있어서,
   상기 멀티 레벨 해쉬 테이블에 포함된 각 레벨(LEVEL)의 버켓 수는 MLEVEL(M = 기지정된 베이스로써, 2이상의 자연수)인, 호스트 장치.
8. 제7 항에 있어서,
   상기 해쉬 값은 상기 검색 파일명에 해쉬 함수를 적용한 값에 상기 조회 레벨에서의 버켓 수를 나눈 나머지인, 호스트 장치.
9. 각 디렉토리의 디렉토리 엔트리(DENTRY)를 포함하는 멀티 레벨 해쉬 테이블을 저장하는 스토리지 장치를 제공하는 단계;
   검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을 입력 받는 단계;
   상기 검색 파일명 및 조회 레벨이 반영된 해쉬 값을 연산하고, 상기 스토리지 장치에 저장된, 상기 검색 디렉토리의 멀티 레벨 해쉬 테이블에 포함된 상기 조회 레벨의 버켓(bucket) 중 상기 해쉬 값에 대응하는 버켓에서 상기 검색 파일명을 포함하는 상기 디렉토리 엔트리를 검색하는 레벨 내 검색 단계; 및
   상기 검색이 실패하면 상기 조회 레벨을 증가시킨 후, 상기 레벨 내 검색 단계를 재수행하는 단계를 포함하는, 디렉토리 엔트리 조회 방법.
10. 각 디렉토리의 디렉토리 엔트리(DENTRY)를 포함하는 멀티 레벨 해쉬 테이블을 저장하는 스토리지 장치를 제공하는 단계;
    검색 디렉토리와 검색 파일명이 지정된 파일 조회(lookup) 명령을 입력 받는 단계;
    상기 검색 파일명 및 조회 레벨이 반영된 해쉬 값을 연산하고, 상기 스토리지 장치에 저장된, 상기 검색 디렉토리의 멀티 레벨 해쉬 테이블에 포함된 상기 조회 레벨의 버켓(bucket) 중 상기 해쉬 값에 대응하는 버켓에서 상기 검색 파일명을 포함하는 상기 디렉토리 엔트리를 검색하는 레벨 내 검색 단계; 및
    상기 검색이 실패하면 상기 조회 레벨을 증가시킨 후, 상기 레벨 내 검색 단계를 재수행하는 단계를 수행하기 위한 프로그램이 기록된 컴퓨터로 읽을 수 있는 기록 매체.

Images