[PintOS Project 4 - File System] File System 이론 공부

File 

• 일반적으로 비휘발성의 보조기억장치에 저장
• 운영체제는 다양한 저장 장치를 file이라는 동일한 논리적 단위로 볼 수 있게 해준다. 
• Operation(연산)
  • create, read, write, reposition (lseek), delete, open, close 등

File attribute (혹은 파일의 metadata)

• 파일 자체의 내용이 아니라 파일을 관리하기 위한 각종 정보들
  • 파일 이름, 유형, 저장된 위치, 파일 사이즈
  • 접근 권한 (읽기/쓰기/실행), 시간 (생성/변경/사용), 소유자 등

File system

• 운영체제에서 파일을 관리하는 부분
• 파일 및 파일의 메타데이터, 디렉토리 정보 등을 관리
• 파일의 저장 방법 결정
• 파일 보호 등

Directory

• directory도 일종의 파일이다. 
  • 파일의 메타데이터 중 일부를 보관하고 있는 일종의 특별한 파일
• 그 디렉토리에 속한 파일 이름 및 파일 attribute 등
• operation
  • search for a file, create a file, delete a file
  • list a directory, rename a file, traverse the file system

Partition(=Logical Disk)

• 하나의 (물리적)디스크 안에 여러 파티션을 두는게 일반적
• 파티션으로 구성한 뒤 각각의 파티션에 file system을 깔거나 swapping 등 다른 용도로 사용할 수 있음 (포맷팅)
• 운영체제 입장에서 보는 디스크는 논리적 디스크다. 

open()

• 해당 File의 메타데이터가 메모리로 올라오는 것

• open("/a/b")
  
  1. root metadata를 물리 메모리에 올린다 → root에서 a의 metadata를 물리메모리에 올린다 → a 디렉토리의 b의 metadat를 물리 메모리에 올린다. 
  2. PCB에 b의 fd 저장
  3. fd에 PCB에 저장된 b의 fd값을 반환
• read(fd)
  • open해놓은 b의 fd에서 파일의 내용을 커널 메모리 영역에 올린다. → copy해서 사용자 메모리 영역에 올린다.
  • 커널 메모리에 올려진 파일의 내용을 저장해놓았다가 쓴다 = 버퍼 캐싱
  • 여러 프로세스가 b파일을 read 같이 접근하고 있을 때 프로세스마다 b의 read하고 있는 offset이 다를 수 있기 때문에 각 프로세스의 file의 offset을 따로 관리하는 테이블을 두는게 일반적이다.

 

 

 

파일 접근 방식

• 순차 접근 : 읽거나 쓰면 offset은 자동적으로 증가(순서대로)
• 직접 접근 : 파일을 구성하는 레코드를 임의 순서로 접근할 수 있다(순서 상관없이 건너뛰기)

 

 

 

Contiguous Allocation (연속 할당)

 

• 장점 : 접근 시간이 빠르다.(fast I/O), 직접 접근 가능
  • SWAPPING 용으로 사용
• 단점 : 외부 단편화

Linked Allocation

• 장점 : 외부 단편화 발생하지 않는다.
• 단점
  • 직접 접근 불가, 중간 위치를 보려면 앞에 위치부터 요소들을 다 접근해야함
  • Reliability 문제 : 중간에 잘못된 sector가 있으면 그 이후 접근 불가
  • pointer(4bytes)를 위한 공간 낭비
• 변형 : FTA (File-allocation table)
  • 포인터를 별도의 위치에 보관하여 reliability와 공간효율성 문제 해결

 

Indexed Allocation

• 장점 : 외부단편화 발생하지 않고 직접 접근 가능
• 단점 
  • small file의 경우 공간 낭비 (파일마다 index를 위한 공간이 필요), 실제로 작은 파일들이 많다
  • 엄청 큰 파일 같은 경우에는 하나의 block(512bytes)로 index 저장하기에 부족
    • 큰 파일일 때 해결 방안 : index가 또 다른 index를 가리키게 한다.

 

UNIX 파일시스템의 구조(Indexed Allocation을 응해서 사용)

• Boot block  : 부팅에 필요한 정보(bootstrap loader)
  • 어느 파일 시스템이든 boot block은 맨 앞에, 컨벤션
• Superblock : 파일 시스템에 관한 총체적인 정보를 담고 있다.
  • 어느 곳이 비어있는지, 사용중인지 확지
  • 어디까지 Inode list인지 어디까지 data block 인지 관리해주는 정보
• Inode : 파일 이름을 제외한 파일의 모든 메타 데이터를 저장한다.
  • 파일 하나당 inode가 하나씩 할당된다. 
  • inode구조
    • 파일이 커질수록 single indirect-> double -> triple 까지 사용할 수 있다.  
    • direct blocks : 바로 파일의 실제 정보가 담겨 있는 주소로 이동
    • single indirect : 다음 index inode → 실제 파일
    • doubole indirect : 다음 index inode → 다음 index inode → 실제 파
• Data block : 파일의 실제 내용을 보관한다. 
  • 파일의 모든 메타 데이터는 Inode에 있는데 유일하게 file의 이름은 디렉토리(directiory)가 가지고 있다. 파일의 이름과 inode 번호가 directory file에 있는 거임

 

 

FAT File System(Linked Allocation 응용)

• UNIX파일 시스템 구조에서는 Inode가 메타정보를 가지고 있었다면 FAT 파일 시스템 구조에서는 디렉토리(directory)가 해당 file의 메타정보를 가지고 있다. 
• FAT : 데이터의 위치를 담고 있는 테이블
  • data block에 있는 데이터 개수 = FAT 배열의 크기
  • directory → file의 내용 안에 다음 주소가 담겨져 있다. 
  • FAT 배열 안에 해당 주소로 가면 다음 블럭이 어디인지 가리킴
  • Linked 단점 모두 개선
    • 직접 접근이 가능(FAT 배열로 따로 뺐기 때문에 가능)
    • FAT을 디스크에 사본을 두 개이상 저장 해놓아서 중간 데이터 유실 정보의 문제를 방어한다.

FAT File System 구조

• Boot block : 파일 시스템을 초기화하고,  파일 시스템의 기본 정보를 포함한다. FAT 파일 시스템의 크기, 테이블의 위치, 섹터 크기, 클러스터 크기 등 메타데이터가 들어 있다. 
• FAT 영역 : 파일이 사용하고 있는 클러스터들의 연결 정보 저장, FAT는 1개 이상의 복사본이 존재할 수 있다. 
• Root Directory : 루트 디렉토리 정보를 저장, FAT12, FAT16에서는 고정된 크기의 루트 디렉토리 영역이 존재해 파일 및 하위 디렉터리들이 기록된다. 또한 파일이나 디렉터리에 대한 메타데이터를 확인할 수 있다. FAT32에서는 루트 디렉터리가 데이터 블록 영역에 저장되어 크기가 고정되지 않고 유동적으로 관리 될 수 있다. 
• Data Block : 실제 데이터가 저장되는 공간, FAT 테이블의 클러스터 정보를 통해 데이터 블록에 저장된 파일 내용을 추적한다.

 

Free-Space Management (디스크의 빈 공간 관리법)

Bit map or bit vector

• 0과 1로 비어있는지 아닌지 확인
• Super block에서 관

Linked, grouping, counting

 

디렉토리(Directory) 구현

• Linear list : 구현이 간단하지만 연산에 대한 시간이 오래걸린다. (특정 파일을 찾을 때 list를 모두 순회)
• hash table : 해쉬 사용하면 O(1) 접근 속도 but 충돌 발생 가능

• 긴 이름의 파일을 지원 (위에 사진 오른쪽 하단 참고)

VFS and NFS

Virtual File System (VFS)

• 서로 다른 다양한 file system에 대해 동일한 시스템 콜 인터페이스 (API)를 통해 접근할 수 있게 해주는 OS의 layer

Network File System(NFS)

• 분산 시스템에서는 네트워크를 통해 파일이 공유될 수 있음
• NFS는 분산 환경에서의 대표적인 파일 공유 방법이다. 

Client 사용자가 VFS와 NFS를 통해 서버의 disk의 접근을 하는 경우 사용 (같은 약속을 가지고 사용해야함)

 

 

페이지 캐시 & 버퍼 캐시

• VM시스템 관점에서의 캐시 : Page 캐시
• 파일시스템 관점에서의 캐시 : Buffer 캐시
• Unified buffer cache : 리눅스에서 사용되고 있음
  • 리눅스에서는 커널영역의 버퍼캐시가 따로 있는게 아니라 페이지 캐시들이 프로세스의 주소공간을 담는 용도로 쓰이지만 일부 페이지 캐시는 파일 시스템 버퍼 캐시 용도로 같이 통합되서 사용된다.

 

물리적 메모리(physical memory)

• User pool
  • page(4KB)단위로 필요한 데이터가 올라오고 내려가고 관리
  • 페이지 캐시
    • LRU, LFU 사용할 수 없었음(운영체제가 알 수가 없음) : 메모리에 올리는 작업은 운영체제의 개입의 도움이 필요한데 이미 메모리에 올라온 페이지를 접근하는 일은 사용자 프로그램이 직접 접근하지 운영체제의 개입을 통해 접근하는게 아니기 때문에 LRU, LFU의 정확한 정보를 알 수가 없음. 알아봤자 Swap in/out할 때...
    • 대신에 Swap in할 때 하드웨어가 allocated bit를 1을 올려주는 점을 이용해 clock 알고리즘을 사용
• Kernel Pool
  • 버퍼 캐시 : 파일의 내용을 읽어온 내용을 버리지 않고 보관하여 사용자 메모리 영역에서 요청하면 copy해간다.
    • 파일의 입출력을 빠르게 하기 위함
    • 버퍼 캐시에 내용을 사용하려면 운영체제의 개입이 있기 때문에 마지막 시점을 정확히 알고 있기 때문에 LRU와 LFU 알고리즘을 사용할 수 있다.
  • 블럭 하나당 512bytes로 구성되어 있다. 최근에는 버퍼 캐시에서도 페이지 크기인 4KB단위로 관리

DISK

• File System 영역 : file들이 저장되어 있는 영역
• Swap 영역 
  • 속도의 효율성을 위해 페이지 단위로 관리

 

프로그램의 실행

• code영역 같은 경우 파일 시스템에 read_only 형태로 저장되어 있음, stack영역과 data 영역 같은 경우에는 swap area로 이동하지만 code영역은 swap area로 가는 것이 아니라 그냥 없애 버리고 나중에 필요할 때 disk의 file system에 직접 접근한다. code영역이 없을 때 페이지 폴트 발생 시 swap영역을 뒤지는게 아니라 file system 영역의 실행파일에서 찾는다.

 

 

 

memory mapped : 일관성 문제 발생할 수 있음 

 

 

read, write 시스템 콜 요청시 

사용자는 copy해서 사용

 

 

 

 

출처 : http://www.kocw.net/home/search/kemView.do?kemId=1226304