이 챕터의 이름을 바꿔야한다. FAT로 갈아끼기..정도로
지금까지의 pintos는 Free_bit_map을 이용해서 filesys를 관리했지만 project4에서는 기존의 Free_bit_map을 fat로 전부 바꿔줘야한다.
void
filesys_init (bool format) {
printf("\n---filesys_init---\n");
filesys_disk = disk_get (0, 1);
if (filesys_disk == NULL)
PANIC ("hd0:1 (hdb) not present, file system initialization failed");
inode_init ();
#ifdef EFILESYS
fat_init ();
if (format)
do_format ();
fat_open ();
#else
/* Original FS */
free_map_init ();
if (format)
do_format ();
free_map_open ();
#endif
}이 코드를 보면 왜 project4가 돌아가지 않는지 알 수 있다...
Indexed and Extensible Files
기존 파일 시스템은 파일을 단일 범위로 할당했음. 그것은 외부 단편화에 취약한 구조임.
외부단편화란 n개의 블럭이 free여도 연속되어있는 공간이 아니기 때문에 n개의 연속된 blocks를 할당시키지 못하는 현상
on-disk inode structure를 수정함으로써 이 문제를 해결할 수 있음
You must implement FAT with given skeleton code.
-> skeleton code만 믿으면 안됨
Each inode is stored in one disk sector, limiting the number of block pointers that it can contain.
하나의 디스크 섹터 당 아이노드 하나씩 저장되어있음
a file was stored as a contiguous single chunk over multiple disk sectors. Let's call contiguous chunk as cluster, since a cluster (chunk) can contain one or more contiguous disk sectors.
이전 프로젝트에서 파일은 여러개의 디스크 섹터에 할당된 연속된 하나의 chunk로 관리되어왔다. 그 연속된 chunk를 이제 cluster라고 부르자.
따라서 cluster는 하나 또는 여러개의 연속된 디스크 섹터를 의미한다.
In this point of view, the size of a cluster in the basic file system was equal to the size of a file that stored in the cluster.
이러한 관점에서, 이전의 파일 시스템의 클러스터의 크기는 클러스터에 저장된 파일의 크기와 같았다.
To mitigate external fragmentation, we can shrink the size of cluster (recall the page size in virtual memory). For simplicity, in our skeleton code, we fixed number of sectors in a cluster as
1. When we use smaller clusters like it, a cluster might not enough to store the entire file. In this case, we need multiple clusters for a file, so we need a data structure to index the clusters for a file in the inode.
외부 단편화를 완화시키기 위해서, 우리는 클러스터의 사이즈를 줄일 수 있다.(아마 vm에서 페이지 크기로 줄일 수 있다는 말인듯). 간단히 말해서 우리의 skeleton code에서 우리는 클러스터의 섹터의 수를 1개로 수정할 수 있다. 즉 하나의 클러스터에 하나의 섹터를 할당하게 만들수 있다는 말인듯. 우리가 작은 사이즈의 클러스터를 사용할 때, 클러스터는 전체 파일을 저장하기에 충분하지 않을 수 있다. 이러한 경우에, 우리는 여려개의 클러스터를 사용해서 파일을 저장할 수 있다. 이때에 우리는 그 파일을 저장하기 위한 클러스터를 인덱싱하기 위해 자료구조(linked-list)를 사용해야한다.
One of the easiest way is to use linked-list (a.k.a chain). An inode can contain the sector number of the first block of the file, and the first block may contain the sector number of the second block. This naïve approach, however, is too slow because we have to read every block of the file, even though what we really need was only the last block.
가장 쉬운 방법이 링크드 리스트로 만드는 방법이다. 하나의 아이노드는 파일의 첫번쨰 블럭의 섹터넘버를 저장할 수 있다. 그리고 첫번째 블럭은 두번째 블럭의 섹터넘버를 저장한다. 이것의 단점은 파일의 모든 블럭을 읽어야하니까 느리다는 점이다. 사실 우리는 첫번째랑 마지막 블럭만 필요하다.
To overcome this, FAT (File Allocation Table) puts the connectivity of blocks in a fixed-size File Allocation Table rather than the blocks themselves. Since FAT only contains the connectivity value rather than the actual data, its size is small enough to be cached in DRAM. As a result, we can just read corresponding entries in the table.
이 단점을 해결하기 위해, FAT는 블럭들 자체가 아니라 the connectivity of blocks를 fixed-size FAT에 넣어놓는다. FAT는 실제 데이터가 아니라 the connectivity value를 가지고 있는다. 이 사이즈는 DRAM에 캐시해놓을 수 있을 만큼 작다. 이러한 방법으로 우리는 테이블의 corresponding entries(해당 항목)를 읽을 수 있다.
