[운영체제] 파일 시스템은 어떻게 구현되어 있는가?

File System Implementation

실제 사용 중인 운영체제에선 파일 시스템이 어떻게 구현되어 있을까? 살펴 보도록 하자.

 

 

Continuous allocation

한 파일을 디스크의 연속된 block에 저장

👍🏻 효율적인 파일 접근

👎🏻 새로운 파일을 위한 공간 확보가 어려움, 외부 단편화 문제, 파일 공간 크기 결정이 어려움(파일이 커져야 할 경우는?)

 

Dis-continuous allocation

Linked allocation

파일이 저장된 블록들을 링크드 리스트로 연결

디렉토리는 각 파일에 대한 첫 번째 블록을 가리키는 포인터를 가짐

👍🏻 단순, 외부 단편화 없음

👎🏻 직접 접근에 비효율적, 포인터 공간 필요, 신뢰성(사용자가 포인터를 건들면?)

구현체 ⇒ FAT(File Allocation Table)

• 각 블록의 시작 부분에 다음 블록의 번호를 기록하는 방법
• MS-DOS, Windows 등에 사용됨

 

Indexed Allocation

파일이 저장된 블록의 정보(pointer)를 index block에 모아둠

Unix 등에 사용됨

👍🏻 직접 접근에 효율적

👎🏻 순차 접근엔 비효율적, 공간 오버헤드, 인덱스 블록 크기에 따라 파일의 최대 크기가 제한됨

 

 

Free Space Management

운영체제는 메모리 공간도 관리하는 똑똑이랍니다.

 

Bit Vector

시스템 내 모든 블록들에 대한 사용 여부를 1 bit flag로 표시

5, 8, 16, 20 블록 사용 안 하는 중

👍🏻 simple and efficient

👎🏻 공간 오버헤드 → 대형 시스템(PB 이상)에 부적합

 

Linked List

빈 블록을 링크드리스트로 연결

탐색도, 공간복잡도도 비효율

 

Grouping

N개의 빈 블록을 그룹으로 묶고, 그룹 단위로 링크드리스트로 연결

👍🏻 연속된 빈 블록을 쉽게 찾을 수 있음

 

Counting

그룹핑도 순차 탐색을 해야 하니까 불편하다~

연속된 빈 block들 중 첫 번째 block의 주소와 연속된 block의 수를 table로 유지

👍🏻 continuous allocation에 유리

👎🏻 불연속적인 블록이 많을 때

 

 

리눅스의 파일 시스템

그럼 리눅스에서 사용하고 있는 실제 파일 시스템 구조는 어떨까요?

하지만 너무 복잡하니까 빨간 네모들만 중점으로 봐도 좋습니다!!

• Super Block : 테이블에 대한 정보를 모두 가지고 있음, 자동으로 여러군데 백업됨
• i-node Table : 파일의 고유번호. 

(ls -il) 치면 나오는 번호들

 

Windows는 좀 다르게 생겼음

 

*** Mounting

도커를 쓸 때도 나오는 마운팅이란 무엇일까요?

 

현재 FS에 다른 FS를 붙이는 것을 말합니다. 쉽게 말해 현재 파일(사람)을 다른 파일(산)에 등산시킨다고 생각하면 됩니다.

파일과 파일을 또는 디렉토리와 디스크 등 다양한 마운팅이 가능합니다.

윈도우는 파일시스템만 만들면 바로 사용할 수 있는데, 리눅스는 마운트를 해줘야 하니 웨않뒈를 외치지 않길~~