KR100790991B1

KR100790991B1 - 데이터베이스 관리 시스템을 이용하여 파일시스템의메타데이터를 관리하는 방법

Info

Publication number: KR100790991B1
Application number: KR1020060053116A
Authority: KR
Inventors: 황주영; 장민성; 배재경; 김하영; 알렉산더 키르나소브
Original assignee: 삼성전자주식회사
Priority date: 2006-03-22
Filing date: 2006-06-13
Publication date: 2008-01-03
Also published as: CN101042703A; CN100585595C; US20070226219A1; EP1837783A1; US20130262535A1; KR20070095737A; US9384201B2

Abstract

본 발명은 데이터베이스 솔루션을 이용하여 파일 시스템의 메타 데이터를 관리하는 방법에 관한 것으로, 본 발명에 따르면 파일 시스템의 메타 데이터는 데이터베이스 관리 시스템을 이용하여 관리하되, 디스크에 데이터를 쓰거나 읽는 것은 다른 파일 시스템 또는 데이터베이스 관리 시스템을 통하지 않고 본 발명에 따른 파일 시스템이 직접 수행함으로써 사용자는 안정적인 트랜잭션을 보장받는 동시에 멀티미디어 환경에 따라 최적화된 디스크 할당 알고리즘을 설계하여 사용할 수 있다.

Description

데이터베이스 관리 시스템을 이용하여 파일시스템의 메타데이터를 관리하는 방법{Method for managing metadata of file system using DBMS}

도 1은 데이터베이스를 이용하여 메타 데이터를 관리하는 종래의 파일 시스템의 구성을 나타낸 도면,

도 2는 본 발명의 일실시예에 따른 파일 시스템에서 데이터를 디스크에 저장하는 과정을 나타낸 순서도,

도 3은 본 발명의 일실시예에 따른 파일 시스템의 메타 데이터를 저장하는 데이터베이스의 스키마(schema)를 나타낸 도면,

도 4는 본 발명의 일실시예에 따른 파일 시스템을 나타낸 블록도,

도 5는 본 발명의 일실시예에 따른 파일 시스템에서 파일을 생성(create)하는 과정을 나타낸 흐름도,

도 6은 본 발명의 일실시예에 따른 파일 시스템에서 파일을 쓰는(write) 과정을 나타낸 흐름도,

도 7은 본 발명의 일실시예에 따른 파일 시스템에서 파일을 읽는(read) 과정을 나타낸 흐름도이다.

본 발명은 파일 시스템에 관한 것으로, 더욱 상세하게는 데이터베이스 솔루션을 이용하여 파일 시스템의 메타 데이터를 관리하는 방법에 관한 것이다.

예전과 달리, 최근 멀티미디어 기술이 발달하며 PVR(Personal Video Recorder), 캠코더, 휴대폰 등 많은 가전 기기들이 하드 디스크를 장착하여 출시되고 있으며, 이에 따라 디스크를 이용하여 데이터를 효율적으로 관리하는 기술에 대한 연구가 활발히 진행되고 있다.

디스크의 데이터 입출력과 관련된 다양한 정책을 결정하는 파일 시스템에서 일관성(consistency)은 매우 중요한 이슈이다. 파일 시스템의 일관성은 메타 데이터의 일관성과 데이터의 일관성으로 구분할 수 있다. 파일 시스템의 메타 데이터에는 아이노드(I-node), 디렉토리, 디스크의 빈 공간에 관한 정보, 빈(free) 아이노드에 관한 정보 등이 있는데, 이러한 메타 데이터와 관련된 동작들(operations)이 하나의 트랜잭션(transaction)으로서 수행되면 메타 데이터의 일관성이 지켜질 수 있다. 마찬가지로, 데이터의 일관성은 데이터 트랜잭션에 의해 지켜질 수 있으며, 파일의 일부를 업데이트하는 데이터 트랜잭션이 업데이트 도중에 철회(abort)되면, 그 데이터 트랜잭션은 완료(complete)되거나, 또는 아예 처음부터 일어나지 않은 것처럼 버려진다.

한편, 데이터베이스 관리 시스템(Database Management System, 이하 DBMS라 칭함)은 빠르고 효과적인 데이터 구조를 이용하여 데이터를 신뢰성있게 저장하며, 트랜잭션을 보장한다. 종래에는 이러한 DBMS 솔루션을 오퍼레이팅 시스 템(Operating System, 이하 OS라고 칭함)에 적용하여 파일 시스템의 일관성을 확보하려는 시도가 있었다.

도 1은 데이터베이스를 도입한 파일 시스템의 구성을 나타낸 도면이다.

도 1에 도시된 파일 시스템에서는 커널 버클리 데이터베이스(KBDM)를 DBMS로 이용하여 파일 시스템의 메타데이터 및 파일 데이터를 관리하고 있으며, 데이터베이스는 기존의 파일 시스템(Ext2)에 저장되어 있다. 이러한 구성에 의하면, 파일 시스템의 모든 동작들(operations)은 DBMS를 통하여 수행된다.

예를 들면, 특정 파일을 읽어올 때에는 DBMS에 액세스하여 block.db에 저장되어 있는 파일 데이터를 버퍼 캐쉬에 복사하며, 파일에 데이터를 쓸 때에는 버퍼 캐쉬에 저장된 데이터를 block.db의 해당 기록(record)에 저장한다. 그 밖에 파일 I/O 외의 동작들도 마찬가지로 관련된 데이터베이스를 통하여 수행되므로, 결국 파일 시스템의 일관성을 보장할 수 있다.

그러나, 이러한 파일 시스템(KBDBFS)은 데이터베이스가 저장된 파일 시스템(Ext2)에 종속적이어서 다양한 환경에 맞추어 최적화할 수 없다. 즉, DBMS(KBDB)는 단지 트랜잭셔널한 동작들(transactional operations)을 제공할 뿐, 파일 시스템의 크기, 디스크 할당(disk allocation) 등은 데이터베이스가 저장된 파일 시스템에 의해 결정된다. 예를 들어, 이러한 파일 시스템에서 디스크에 데이터를 저장할 때 파일 시스템(KBDBFS)은 데이터를 DBMS(KBDB)에 입력하고, DBMS(KBDB)는 Ext2를 통해 데이터를 디스크에 저장하므로, 파일 시스템(KBDBFS)은 실제 디스크의 레이아웃(layout)에는 관여할 수 없다. 따라서, 이러한 파일 시스템에 따르면 환경에 최적화된 알고리즘이 설계되더라도 이를 반영하여 디스크의 블록을 할당할 수 없는 문제가 있다. 또한, 일반적으로 파일의 크기가 큰 멀티미디어 환경에서는 DBMS가 생성하는 로그(log)의 크기가 커지므로 파일 시스템의 성능이 저하되는 문제도 발생한다.

본 발명은　파일 시스템의 메타 데이터는 DBMS를 이용하여 관리하고, 파일 데이터는 DBMS를 통하지 않고 직접 디스크로부터/디스크에 입출력하는 방법을 제공하는 데 그 목적이 있다.

이러한 목적을 달성하기 위해 본 발명은,　파일 시스템에서 데이터를 관리하는 방법에 있어서, (a) 애플리케이션으로부터 데이터 쓰기 요청이 수신됨에 따라 상기 파일 시스템의 메타데이터를 관리하는 소정의 데이터베이스관리시스템(DataBase Management System)을 통해 디스크에 존재하는 빈 공간을 검색하는 단계; (b) 상기 검색 결과를 참조하여 상기 데이터를 상기 데이터베이스관리시스템을 통하지 않고 상기 디스크의 빈 공간에 쓰는 단계; 및 (c) 상기 메타 데이터 중 상기 데이터가 써짐에 따라 변경된 부분을 상기 데이터베이스관리시스템을 통해 업데이트하는 단계를 포함하는 것을 특징으로 한다.

여기서, 상기 (a)단계 내지 상기 (c)단계는 상기 데이터베이스관리시스템에 의해 하나의 트랜잭션(transaction)으로서 관리되는 것이 바람직하다.

또한, 상기 파일 시스템은 사용자 레벨(User-Level)에서 동작하는 것이 바람 직하다.

또한, 상기 데이터가 저장되는 디스크는 상기 메타데이터가 저장된 디스크와 별개인 것이 바람직하다.

상기 (c)단계는, 상기 메타데이터 중에서, 빈 공간에 관한 정보를 포함하는 데이터베이스 테이블, 이미 사용 중인 공간에 관한 정보를 포함하는 데이터베이스 테이블 및 아이노드(i-node)에 관한 정보를 포함하는 데이터베이스 테이블 중 적어도 하나를 업데이트할 것을 상기 데이터베이스관리시스템에 요청하는 단계를 포함할 수 있다.

또한, 본 발명은 상기 데이터 관리 방법을 컴퓨터에서 실행시키기 위한 컴퓨터로 읽을 수 있는 기록 매체를 제공한다.

이하에서 첨부된 도면을 참조하여, 본 발명의 바람직한 실시예를 상세히 설명한다.

도 2는 본 발명에 따른 파일 시스템에서 데이터를 디스크에 저장하는 과정을 나타낸 순서도이다.

단계 210에서 본 발명에 따른 파일 시스템은 사용자의 애플리케이션으로부터 파일 데이터를 디스크에 쓸(write) 것을 요청받는다. 이를 위하여 본 발명에 따른 파일 시스템은 시스템 콜에 대응되는 사용자 레벨의 API(Application Programming Interface)를 애플리케이션 계층에 제공하여야 한다.

단계 220에서 본 발명에 따른 파일 시스템은 메타 데이터를 관리하는 DBMS에게 트랜잭션의 시작을 요청한다. 따라서, 단계 220 이후에 수행되는 메타 데이터에 대한 동작들은 하나의 트랜잭션으로 간주되어 보호된다.

단계 230에서는 애플리케이션이 요청한 파일 데이터를 쓰기하기 위하여 디스크의 빈 공간을 검색한다. 이 때, 디스크의 빈 공간은 DBMS를 통해 디스크의 빈 공간에 관한 정보를 포함하는 데이터베이스 테이블을 참조하여 검색한다. DBMS에서 관리하는 데이터베이스 스키마(schema)에 관한 상세한 설명은 도 3을 참조하여 후술한다.

단계 240에서는 파일 데이터를 디스크의 빈 공간에 쓴다. 상황에 따라 단계 230에서 검색된 빈 블록은 매우 많을 수 있는데, 그 블록들 중 어느 블록에 요청된 파일 데이터를 저장할 것인가는 사용자에 의해 정의된 디스크 할당 알고리즘에 의해 결정할 수 있다. 왜냐하면, 본 발명에 따른 파일 시스템에서 메타 데이터는 ext2와 같은 기존의(conventional) 파일 시스템 또는 DBMS에 의해 관리되지만, 디스크에 파일 데이터를 읽거나 쓰는 것은 DBMS 또는 타 파일 시스템을 통하지 않고 본 발명에 따른 파일 시스템이 직접 수행하기 때문이다(raw I/O). 다시 말하면, 본 발명에 다른 파일 시스템은 DBMS가 제공하는 API를 통해 파일 시스템의 메타 데이터를 처리하므로 메타 데이터에 관한 디스크 레이아웃에는 관여하지 않지만, 파일 데이터와 관련하여서는 직접 디스크 레이아웃을 제어하므로 멀티미디어 환경에 따라 최적화된 디스크 할당 알고리즘을 사용할 수 있는 것이다. 또한, DBMS가 파일 데이터를 관리하지 않아 파일 데이터에 관한 로그를 작성하지 않으므로 파일의 크기가 커지더라도 파일 시스템의 성능 저하가 일어나지 않는다.

단계 250에서는 DBMS에게 단계 240에서 디스크에 파일 데이터가 써짐에 따라 변경되어야 하는 메타데이터를 업데이트하도록 요청한다. 예를 들면, 아이노드, 디스크의 빈 공간에 관한 정보, 디스크의 사용중인 공간에 관한 정보 등에 관련된 데이터베이스 테이블들이 업데이트될 것이다.

단계 260에서는 DBMS에게 트랜잭션의 종료를 요청한다. 따라서, DBMS는 단계 230 내지 단계 250에서 수행되는 동작들을 하나의 트랜잭션으로 간주하게 되므로 파일 시스템의 메타 데이터 일관성이 확보된다. 예를 들어 단계 250에서 사용중인 공간에 관한 정보를 포함하는 데이터베이스 테이블을 업데이트하였고 디스크의 빈 공간에 관한 정보를 포함한 데이터베이스 테이블을 업데이트하기 전, 정전으로 인해 전원이 끊긴 경우 DBMS는 사용중인 공간에 관한 정보를 포함하는 데이터베이스 테이블의 업데이트를 없었던 것으로 처리하고, 이에 따라 관련 데이터를 메타 데이터에 반영하지 않는다.

또한, 단계 250이 단계 240이 수행 완료된 경우에만 수행되도록 하면, 즉 파일 데이터의 쓰기가 완료되어야 단계 250으로 넘어가도록 하면 결국 단계 240도 단계 220과 단계 260의 사이에 놓이게 되어 데이터의 일관성도 확보할 수 있다. 그러나, 파일 시스템 성능의 향상을 위해 단계 240의 완료 여부와 관계 없이 단계 250이 수행되도록 할 수도 있을 것이다.

한편, 파일 시스템의 성능 향상을 위해서는 메타 데이터가 저장되는 디스크와 파일 데이터가 저장되는 디스크를 별개로 하는 것이 바람직할 것이다.

도 3은 본 발명의 일실시예에 따른 파일 시스템의 메타 데이터를 저장하는 데이터베이스의 종류를 나타낸 표이다.

슈퍼블록 데이터베이스(super.db)는 파일 시스템의 상태(status)에 관한 정보와 아이노드 비트맵을 저장한다. 전체 파일 시스템의 정보는 하나의 기록(record)에 저장될 수 있고, 아이노드 비트맵 역시 몇 개의 기록들만을 필요로 하므로, 이 데이터베이스는 기록번호(RECNO) 기반의 데이터 구조를 가지며 2차적인 인덱스는 필요로 하지 않을 것이다.

디렉토리 데이터베이스(directory.db)는 디렉토리 및 파일 이름을 아이노드 번호에 매핑시킨다.

아이노드 데이터베이스(inode.db)는 아이노드 번호를 파일의 크기, 마지막 수정 시간 등 해당 파일의 파일 정보에 매핑시킨다. 새로운 파일이 생성(create)되면 새로운 아이노드 기록이 이 데이터베이스에 추가되며, 파일이 삭제되면 관련 아이노드 기록이 이 데이터베이스로부터 삭제된다.

빈공간 데이터베이스(freespace.db)는 파티션의 빈 공간들을 관리한다. 이 때, 데이터베이스 테이블에서 빈 공간들에 관한 정보는 구간(extent) 형식으로 표현되는 것이 바람직하다. 구간 형식으로 나타내는 것이 비트맵 형식으로 나타내는 것보다 정보의 크기를 줄일 수 있기 때문이다. 구간 형식은 빈 공간이 시작되는 위치를 지정하는 블록번호 및 그 빈 공간의 크기에 해당하는 블록의 개수로 나타낸 수도 있으며, 빈 공간이 시작되는 위치를 바이트오프셋(byte offset)으로 나타내고 그 크기는 바이트 단위로 나타낼 수도 있을 것이다. 본 발명에 따른 파일 시스템은 파일에 데이터를 쓰기 위해 빈공간 데이터베이스를 참조하여 디스크의 빈 공간을 검색한다.

구간 데이터베이스(extents.db)는 파일의 오프셋을 그 파일 데이터를 포함하는 구간의 블록 어드레스에 매핑시킨다.

도 4는 본 발명의 일실시예에 따른 파일 시스템을 나타낸 블록도이다.

도 4에 도시된 바와 같이, 본 발명에 따른 파일 시스템은 Syscall모듈(402), Namei모듈(403), Super모듈(404), Dir모듈(405), Inode모듈(406), File모듈(407), Alloc모듈(408), DBAL모듈(410) 및 OSAL(409)모듈을 포함한다. 또한, 본 실시예에서는 DBMS로 버클리(Berkeley) DB(411)를 사용하고 있으며, 파일 시스템 메타 데이터는 ext3(412)가 디스크에/디스크로부터 입출력하는 것으로 가정하였다.

Syscall모듈(402)은 애플리케이션(401)이 시스템 콜을 할 수 있도록 하는 API를 제공하고, DBMS(411)에게 트랜잭션의 시작과 끝을 요청한다.

Namei모듈(403)은 애플리케이션(401)이 호출한 API함수를 분석하여 업데이트되어야 할 데이터베이스를 결정한다. Super모듈(404)은 DBMS(411)에게 super.db의 검색 및 업데이트를 요청하고 Dir모듈(405)은 dir.db의 검색 및 업데이트를 요청하며, Inode모듈(406)은 inode.db를 이용하여 빈(free) 아이노드들을 관리한다.

Alloc모듈(408)은 DBMS(411)를 통해 디스크의 빈 공간에 관한 정보를 획득하고, 멀티미디어 환경, 또는 기타 다른 환경에 최적화된 디스크 할당 알고리즘을 이용하여 파일 데이터가 쓰여질 블록들을 결정한다.

File모듈(407)은 커널 레벨에서 동작하는 OS모듈(도시하지 않음)을 통해 디스크로의/디스크로부터의 파일 데이터를 입출력하는데, 예를 들면 블록 디바이스 파일에 데이터를 쓰거나 블록 디바이스 파일로부터 데이터를 읽는 방식을 사용하여 파일 데이터 입출력을 수행할 수 있다.

DBAL(DB Abstract Layer)모듈(410)은 Syscall(402)와 DBMS(411)과의 호환을 위한 인터페이스이며, OSAL(OS Abstract Layer)는 OS마다 다를 수 있는 블록 디바이스 파일의 처리를 가능하게 하는 인터페이스이다.

한편, 도 4에 도시된 바와 같이 본 발명에 따른 파일 시스템은 사용자 레벨에서 동작하므로 파일 시스템의 소스 코드가 OS에 의존하지 않는다. 따라서, 커널 레벨에서 동작하는 파일 시스템에 비해 본 발명에 의한 파일 시스템은 다른 OS들로 포트(port)하기 쉽고, 또한 유지 및 보수(maintenance)가 용이하다.

도 5는 도 4에 도시된 파일 시스템에서 파일을 생성(create)하는 과정을 나타낸 흐름도이다. 본 실시예에서는 DBAL모듈 및 OSAL모듈은 사용되지 않는 것으로 가정한다.

단계 501에서 애플리케이션은 Syscall모듈에게 파일 이름을 제공하며 파일 생성을 요청하고, 단계 502에서 Syscall모듈은 DBMS에게 트랜잭션을 시작할 것을 요청한다. 단계 503에서 DBMS는 트랜잭션을 시작한다.

단계 504에서 Syscall모듈은 Namei모듈에게 파일 생성을 요청하고, 단계 505에서 Namei모듈은 Super모듈에게 새로운 파일에 할당할 아이노드를 요청한다. Namei모듈로부터 아이노드를 요청받은 Super모듈은 단계 506에서 DBMS에게 super.db의 검색 및 수정을 요청한다. 이러한 요청을 받은 DBMS는 아이노드 비트맵을 참조하여 빈 아이노드를 새로운 파일에 할당하고, super.db를 업데이트한다(도시되지 않음).

단계 507에서 Namei모듈은 Dir모듈에게 디렉토리에 새로운 파일을 등록할 것을 요청하고, 이에 단계 508에서 Dir모듈은 DBMS에게 dir.db의 검색 및 수정을 요청한다. 이러한 요청을 수신한 DBMS는 새로운 파일의 이름과 그에 해당하는 아이노드를 매핑하여 dir.db에 저장한다(도시되지 않음).

단계 509에서 Namei모듈은 Inode모듈에게 새로운 아이노드에 대한 초기화를 요청하고, 단계 510에서 Inode모듈은 DBMS에게 inode.db에 새로운 아이노드에 관한 정보를 등록할 것을 요청한다. 이러한 요청을 수신한 DBMS는 새로운 파일에 해당하는 아이노드에 새로운 파일과 관련된 정보를 저장한다(도시되지 않음).

단계 510의 수행이 완료되면, 단계 511에서 Namei모듈은 Syscall모듈에게 파일 생성이 완료되었음을 통지하고, 단계 512에서 Syscall모듈은 DBMS에게 트랜잭션을 종료할 것을 요청한다. 단계 513에서 DBMS는 단계 503에서 시작된 트랜잭션을 종료한다.

도 6는 도 4에 도시된 파일 시스템에서 파일에 데이터를 쓰는(write) 과정을 나타낸 흐름도이다. 본 실시예에서는 DBAL모듈 및 OSAL모듈은 사용되지 않는 것으로 가정한다.

단계 601에서 애플리케이션은 Syscall모듈에게 파일에 데이터를 쓰도록 요청한다. 이 때, 파일 이름과 데이터, 데이터의 크기 및 파일 내의 오프셋 정보가 전달된다. 단계 602에서 Syscall모듈은 DBMS에게 트랜잭션을 시작하도록 요청하고, DBMS는 단계 603에서 트랜잭션을 시작한다.

단계 604에서 Syscall모듈은 File모듈에게 쓰기 동작을 요청하고, 단계 605 에서 File모듈은 Alloc모듈에게 파티션의 빈 블록에 대한 정보를 요청한다. 이러한 요청을 수신한 Alloc모듈은 단계 606에서 DBMS에게 freespace.db의 검색 및 수정을 요청한다(606). 이 요청을 수신한 DBMS는 freespace.db를 검색하여 빈 블록들을 찾아내고, 단계 607에서 빈 블록에 대한 정보를 Alloc모듈에게 전달한다.

단계 608에서 Alloc모듈은 파티션의 빈 블록들 중 데이터가 쓰여질 블록들에 대한 정보를 File모듈에게 전달한다. 이 때 전달되는 블록들에 대한 정보는 단계 607에서 DBMS가 전달한 빈 블록들에 관한 정보와 다를 수 있다. 즉, 단계 607에서 DBMS는 파티션의 모든 빈 블록들을 알려주지만, Alloc모듈은 소정의 디스크 할당 알고리즘을 이용하여 데이터가 쓰여질 블록들을 결정한 후, File모듈에게 전달하는 것이다. 따라서 사용자는 자유롭게 디스크 할당 알고리즘을 설계하여 Alloc모듈 내에 구현함으로써, 기존의 파일 시스템에 의한 고정된 디스크 할당 방식에서 벗어나 멀티미디어 환경에 최적화된 파일 시스템을 만들 수 있다.

단계 609에서 File모듈은 커널 모드에서 동작하는 OS모듈에게 파티션 이름, 파티션 내에서의 오프셋 정보, 데이터 및 데이터의 크기를 전달하며 쓰기 요청을 하고(raw input), 단계 610에서 OS모듈은 수신한 정보에 기초하여 디스크에 데이터를 쓴다.

단계 611에서 OS모듈은 File모듈에게 쓰기가 완료되었음을 통지하고, 단계 612에서 File모듈은 Inode모듈에게 쓰기가 완료되었음을 통지한다. 단계 613에서 Inode모듈은 DBMS에게 해당 파일에 발생한 변경 사항을 반영하여 inode.db를 업데이트하도록 요청한다. 이에 따라 DBMS는 해당 파일의 최종 변경 시각, 파일 크기 등에 대한 정보를 변경할 것이다(도시하지 않음). 또한, 단계 614에서 File모듈은 DBMS에게 extents.db를 수정하도록 요청한다. 이 요청을 수신한 DBMS는 새로 데이터가 쓰여진 블록에 관한 정보를 반영하여 extents.db를 업데이트한다(도시하지 않음).

단계 615에서 File모듈은 Syscall모듈에게 쓰기가 완료되었음을 통지하고, 단계 616에서 Syscall모듈은 DBMS에게 트랜잭션의 종료를 요청한다. 단계 615에서, DBMS는 단계 603에서 시작된 트랜잭션을 종료한다.

도 7은 도 4에 도시된 파일 시스템에서 데이터를 읽는(write) 과정을 나타낸 흐름도이다. 본 실시예에서는 DBAL모듈 및 OSAL모듈은 사용되지 않는 것으로 가정한다.

단계 701에서 애플리케이션은 Syscall모듈에게 파일 이름, 파일 내의 오프셋 정보 및 데이터의 크기를 알려주며 해당 데이터를 읽을 것을 요청한다. 단계 702에서 Syscall모듈은 File모듈에게 해당 데이터를 읽도록 요청하고, 단계 703에서 File모듈은 Inode모듈에게 관련 블록에 대한 정보를 요청한다.

이러한 요청을 수신한 Inode모듈은 단계 704에서 DBMS에게 extents.db의 검색을 요청하며, DBMS는 extents.db를 검색하여 해당 데이터가 위치한 블록에 관한 정보를 추출한 후, 단계 705에서 추출한 정보를 Inode모듈에게 전달한다. 단계 706에서 Inode모듈은 블록 정보를 File모듈에게 전달하고, 단계 707에서 File모듈은 OS모듈에게 파티션 이름, 파티션 내에서의 오프셋 정보 및 데이터의 크기를 알려주며 해당 데이터를 읽도록 요청한다(raw output). 단계 708에서 OS모듈은 디스크에 서 해당 데이터를 읽고, 단계 709에서 읽어온 데이터를 File모듈에게 전달한다. 단계 710에서 File모듈은 Syscall모듈에게 데이터를 전달하고, 단계 711에서 Syscall모듈은 애플리케이션에게 데이터를 전달함으로써 읽기 과정이 완료된다.

한편, 상술한 본 발명의 실시예들은 컴퓨터에서 실행될 수 있는 프로그램으로 작성가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다.

상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, 롬, 플로피 디스크, 하드디스크 등), 광학적 판독 매체(예를 들면, 시디롬, 디브이디 등) 및 캐리어 웨이브(예를 들면, 인터넷을 통한 전송)와 같은 저장매체를 포함한다.

이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

본 발명에 따른 파일 시스템은, DBMS가 제공하는 API를 통해 파일 시스템의 메타 데이터를 처리하므로 안정적으로 트랜잭션을 보장할 수 있고, 메타 데이터에 관한 디스크 레이아웃에는 관여하지 않지만, 파일 데이터와 관련하여서는 직접 디스크 레이아웃을 제어하므로 멀티미디어 환경에 따라 최적화된 디스크 할당 알고리즘을 설계하여 사용할 수 있다.

또한, 본 발명에 따른 파일 시스템은 DBMS가 메타 데이터만을 관리할 뿐, 파일 데이터를 관리하지 않아 파일 데이터에 관한 로그를 작성하지 않으므로 파일의 크기가 커지더라도 파일 시스템의 성능 저하가 일어나지 않는다.

또한, 본 발명에 따른 파일 시스템은 커널 레벨이 아닌 사용자 레벨에서 동작하므로 파일 시스템의 소스 코드가 OS에 의존하지 않아 다른 OS들로 포트(port)하기 쉽고, 유지 및 보수(maintenance)가 용이하다.

또한, 본 발명에 따른 파일 시스템은 메타 데이터와 파일 데이터가 서로 다른 별개의 디스크에 저장되므로 디스크에 파일 데이터를 입출력할 때 기존의 파일 시스템에 비해 효율적이다.

Claims

파일 시스템이 데이터를 관리하는 방법에 있어서,

(a) 애플리케이션으로부터 데이터 쓰기 요청이 수신됨에 따라 상기 파일 시스템의 메타데이터를 관리하는 데이터베이스관리시스템(DataBase Management System)을 통해 디스크에 존재하는 빈 공간을 검색하는 단계;

(b) 상기 검색 결과를 참조하여 상기 데이터를 상기 데이터베이스관리시스템을 통하지 않고 상기 디스크의 빈 공간에 쓰는 단계; 및

(c) 상기 메타 데이터 중 상기 데이터가 써짐에 따라 변경된 부분을 상기 데이터베이스관리시스템을 통해 업데이트하는 단계를 포함하는 것을 특징으로 하는 방법.
제 1항에 있어서,

상기 (a)단계 내지 상기 (c)단계는 상기 데이터베이스관리시스템에 의해 하나의 트랜잭션(transaction)으로서 관리되는 것을 특징으로 하는 방법.
제 1항에 있어서,

상기 파일 시스템은 사용자 레벨(User-Level)에서 동작하는 것을 특징으로 하는 방법.
제 1항에 있어서,

상기 데이터가 저장되는 디스크는 상기 메타데이터가 저장된 디스크와 별개인 것을 특징으로 하는 방법.
제 1항에 있어서,

상기 (c)단계는 상기 메타데이터 중에서, 빈 공간에 관한 정보를 포함하는 데이터베이스 테이블, 이미 사용 중인 공간에 관한 정보를 포함하는 데이터베이스 테이블 및 아이노드(i-node)에 관한 정보를 포함하는 데이터베이스 테이블 중 적어도 하나를 업데이트할 것을 상기 데이터베이스관리시스템에 요청하는 단계를 포함하는 것을 특징으로 하는 방법.
제 1항에 있어서,

상기 메타데이터는 상기 디스크의 빈 공간에 관한 정보를 구간(extent) 형식으로 나타내는 것을 특징으로 하는 방법.
제 6항에 있어서,

상기 구간 형식은 상기 빈 공간이 시작되는 위치를 나타내는 블록번호 및 상기 빈 공간의 크기에 해당하는 블록의 개수로 표현되는 것을 특징으로 하는 방법.
제 6항에 있어서,

상기 구간 형식은 상기 빈 공간이 시작되는 위치를 바이트오프셋(byte offset)으로 나타내고, 상기 빈 공간의 크기를 바이트 단위로 나타내는 것을 특징으로 하는 방법.
제 1항에 있어서,

(d) 임의의 애플리케이션으로부터 상기 데이터의 읽기가 요청됨에 따라 상기 데이터베이스관리시스템을 통해 상기 데이터와 관련된 메타데이터를 획득하는 단계;

(e) 상기 획득한 메타데이터에 의해 특정되는 블록(들)의 데이터를 상기 데이터베이스관리시스템을 통하지 않고 상기 디스크로부터 읽는 단계; 및

(f) 상기 읽은 데이터를 상기 임의의 애플리케이션에게 전달하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제 1항 내지 제 9항 중 어느 한 항에 의한 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체.