본문으로 건너뛰기

운영체제 File System

Directory 구현​

Directory Entry​

Fat 파일시스템​

파일명 - 파일속성(메타데이터)

UNIX 파일시스템​

파일명 - #inode #inode 주소 → inode(메타데이터)

파일명 할당​

: 파일명의 크기가 클수도 작을수도 있다
⇒ 효율성을 위해 entry를 가변적으로, 4byte 단위로 추가할당하며 파일명을 구성

File 공유​

: link 개념 사용 in indexed FS

entry에서 동일한 #inode를 공유 == Hard Link​

특징(문제점_)

  • 삭제를 보장하기 힘들다(보안)
  • Directory를 공유하는 경우 조회할 때 무한루프에 빠질 수 있다

⇒ Symbolic Link


Symbolic Link == Soft Link​

: Link File 타입의 파일을 만든다. 이 파일의 데이터는 target file의 경로

파일 Access 방식
⇒ 바로가기(Link File's name) → Link File's #inode → Link File's inode → Link File's data #block & get 파일데이터(target file 경로) → Target File's #block → Target File's 파일데이터

특징

  • 원본 삭제시 파일 삭제보장(보안)
  • 파일에 접근할 때 속도 측면에서 비효율

Log-Structed File System(LFS)​

: Disk seek time을 줄여서 write 연산의 효율을 높이기 위한 File System
: Data 위치 가변적

vs Data 위치 불변(update in place)​

  • Aging == Fragmentation 발생
  • Random Access(불변) → 접근시 Disk head의 seek time이 비교적 큼

Disk를 sequential하게 보기​

: 파일 수정시 not in place, but sequential 위치에
파일 자체 정보가 수정됨 → inode, 상위 directory 정보 또한 수정됨
⇒ segment{ Data / inode / directory } 단위가 새로써진다.

→ 접근효율성을 위해서 Data는 buffering 되었다가 한 번에 Writing Point부터 써짐


inode 정보 위치 가변​

: 파일 접근시 어려움 ⇒ i-map 사용
inode가 디스크에 퍼져있으므로 inode를 가리키는 주소가 필요하다.
recent inode 주소를 가리키는 inode-map


Cleaning​

: Update in place X, make New one → 기존의 정보는 의미없는 garbage
⇒ cleaner: Obsolete blocks 반납, Live block copy & 새로쓰기
→ Live block이 많을수록 copy 오버헤드 수반