[OS] File System Implementation-2

이 문서는 광운대학교 김태석 교수님의 운영체제 강의를 토대로 작성한 문서입니다.

• Directory Implementation
• Performance and Recovery

---

Directory Implementation

파일 관리만큼 디렉토리 공간 할당과 관리 또한 중요하다.

• Linear List

  디렉토리를 구현하는 가장 쉬운 방법은 파일 이름과 파일에 대한 포인터를 linear list로 관리하는 방법이다.

  (file name, pointer to the file)

  장점 - 구현하기 쉽다. 단순히 pointer를 연결시켜주면 된다.

  단점 - 파일이 많아질때 검색시간이 길어진다. 이를 해결하기 위해 B-tree를 사용한다.

  구현하기 쉬운 장점이 있으나, 파일이 많아질때 파일 검색시간이 길어질 수 있다.

  • 이에 대한 해결책으로 B-Tree로 구현하여 탐색시간을 줄일 수 있다.

• Hash Table

  Hash table을 이용하여 구현할 수도 있는데, 파일 이름을 input으로, 파일에 대한 포인터를 output으로 하여 hash function을 만드는 방법이다.

  list를 만드는것보다 search time이 빠르지만 다른 input에 대해 같은 output이 나와서 collision이 발생할 수 있다.

Performance and Recovery

• Efficiency
  • 파일의 data block과 inode의 영역을 나누어서 디스크에 저장하는데, 둘을 가까운 위치에 저장하면 seek time을 줄일 수 있다.
  • 파일을 last access time 정보를 update해주는데 디스크 I/O가 필요하다. 이는 성능 저하가 발생할 수 있다.
  • file에 대한 pointer의 size를 줄여 더 많은 pointer를 구성할 수 있고 I/O가 줄어 성능이 향상될 수 있다.
• Performance
  • Buffer cache - 자주 사용하는 block들을 main memory의 cache에 저장한다.
    • 파일에
  • Read-ahead - sequential access 파일(동영상, 미디어 파일 등)은 한 파일을 나누어 읽는데, sequential 한것을 알면 미리 읽어오는 방식이다.
• Buffer cache
  • 파일에 접근할 때마다, disk I/O가 필요하고 이것은 overhead를 야기한다.
  • 파일 접근 패턴에서, 자주 접근되는 파일들이 다시 접근될 확률이 높다. (temporal locality)
  • main memory에 buffer cache를 두어 자주 사용되는 block을 저장하여 디스크 접근을 줄일 수 있다.
  • 그러나 main memory에 있으므로 휘발성이다. 따라서 collision이 발생하면 inconsistency가 발생할 수 있다.
    • file data라면 데이터 손실로 끝나지만, directory나 inode라면 치명적인 손실이 발생할 것이다.
  • 이를 해결하기 위한 방법으로 Consistency checker, Synchronous, Journaling 등이있다.
• Journaling
  • directory ‘a’에 file ‘b’를 write한다고 가정하자.
  • 그러면 ‘b’에 대한 file data와 inode뿐 아니라, directory ‘a’의 entry를 수정하고 inode또한 update해주어야한다. → file system을 많이 사용한다.
  • 그때 충돌이 발생한다면, inconsistency가 발생한다.
  • Journaling 방법을 사용하면 관련된 block들을 하나로 묶어 디스크의 Journal이라는 공간에 써둔다.
  • 그 후에 Journal에 있는 block들을 반영하며 inconsistency를 해결한다.
    • Journal에 쓰는도중 충돌이 나면 → 반영을 안함으로써 해결
    • Journal에서 디스크로 반영 도중에 충돌이 나면 → log들을 확인하며 반영할 block만 반영
  • Journal에 쓰고, 디스크에 쓰는 방법은 overhead문제가 있을것 같지만 Journal에 쓸때는 block을 하나로 묶어 한번에 쓰기 때문에 큰 overhead가 들지 않는다.