데이터 엔지니어

[OS Chapter 10] File Systems 본문

컴퓨터 과학(Computer science)/운영체제(Operating System)

[OS Chapter 10] File Systems

kingsmo 2020. 11. 28. 14:00

파일과 파일 시스템

File

  • A named collection of related information
  • 일반적으로 비휘발성의 보조기억장치에 저장
  • 다양한 저장장치를 file이라는 동일한 논리적 단위로 봄
  • operation
    • create, read, write, reposition(lseek, 파일의 위치를 생성해주는 연산)
    • open, close 

 

File attribute(= metadata)

  • 파일을 관리하기 위한 각종 정보들
  • 파일 이름, 유형, 위치, 사이즈, 접근 권한, 시간, 소유자 등

File System

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

Directory

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

Partition(= Logical Disk)

  • 하나의 물리적 디스크를 여러 파티션으로 둠
  • file system 또는 swap area 용도로 사용

Open operation

출처: 강의

  • 파일의 메타데이터를 메모리에 올리는 것이다.
  • open도 시스템 콜이다.
  • open("/a/b") 수행 순서
    • root의 metadata를 커널 메모리에 올림
    • root의 content중 a의 metadata를 다시 커널메모리에 올림
    • a의 content중 b의 metadata를 다시 커널메모리에 올림
    • process A의 PCB에서 b파일의 file descriptor를 커널메모리에 metadata와 사용자 메모리 Process A에 전달해준다.
    • b의 content를 접근하여  버퍼캐시로 운영체제가 읽어들이고 그 내용을 copy하여 사용자 process에게 전달

 

주의!

Virtual memory에서 page fault에 대해서만 OS가 접근하였는데,

File Systems에서는 버퍼캐시가 커널메모리 내부에 있기 때문에 항상 OS접근을 한다.

그래서 Clock 알고리즘이 아닌 LRU LFU등의 알고리즘이 사용 가능하다.

 

open file table은 시스템 전체에 하나만 존재하고

PCB의 file descriptor table은 process당 하나씩 존재한다.


File Protection

: 각 파일에 대해  누구에게 어떤 접근을 허락할 것인가.

 

Access Control Matrix

 

  • matrix같은경우는 sparse matrix가 될 수가 있다.
  • ACL(access control list)는 파일별로 누구에게 어떤 접근 권한이 있는지 표시
  • Capability 사용자별로 자신이 접근 권한을 가진 파일 및 해당 권한 표시

Grouping

  • 전체 user를 owner / group / public 세 그룹으로 구분
  • UNIX는 rwx 3비트씩 총 9비트를 사용
  • 일반적인 방법

Password

  • 파일마다 password를 두는 방법
  • 모든 접근 권한에 대해 하나의 password
  • 접근 권한별 password

File System의 Mounting 

: 다른 파티션에 있는 디스크를 접근하기 위해서 마운트를 하는 것이다.

출처: https://kkslinuxinfo.wordpress.com/2015/12/08/mounting-file-system/

Access Methods

순차 접근(sequential access)

  • 카세트 테이프를 사용하는 방식
  • 읽거나 쓰면 offset은 자동적으로 증가

직접 접근(direct access, random access)

  • 임의의 순서대로 접근 가능함.

 


Allocation of File Data in Disk

: 파일을 디스크에 저장하는 방법 3가지

1. Contiguous Allocation 연속할당

출처: https://www.geeksforgeeks.org/file-allocation-methods/

장점

  • 빠른 I/O
    • 한번의 seek/rotation으로 많은 바이트 transfer가능
    • Realtime file용으로 process의 swapping용으로 사용(속도 효율성이 더 중요함)
  • Direct access(=random access) 가능

단점

  • 외부조각(External fragmentation)
  • File Grow의 제약이 있음. 14~16을 6개의 block으로 늘리면 불가능하다.
    • 미리 빈 공간을 어느정도 확보 => 이걸 크게 했을시 grow는 가능하나 내부조각(Internal fragmentation)이 발생

 

 

2. Linked Allocation

: 각 블록마다 다음 블록으로 링크가 걸려있다.

출처: https://www.geeksforgeeks.org/file-allocation-methods/

장점

  • 외부 조각이 발생하지 않음

단점

  • Direct access가 불가
  • Reliability 문제: 중간 sector가 고장나면 pointer가 유실되어 연달아 유실됨
  • Pointer를 위한 공간이 block의 일부가 되어 공간 효율성을 떨어뜨림 
    • 512 bytes/sector, 4 bytes/pointer
    • 512 바이트 안에 4 바이트씩 차지

=> 변형하여 포인터를 별도의 위치에 보관하여 reliability와 공간효율성 문제 해결 =>  File-allocation table(FAT) 파일 시스템

 

 

3. Indexed Allocation

: 블록 하나에 각 파일의 위치를 적어놓음

 

장점

  • Direct access 가능
  • External fragmentation 발생 X

단점

  • 파일이 너무 작은경우도 블록이 적어도 2개는 필요하다.
  • 굉장히 큰 파일의 경우 하나의 블록으로 index를 저장하기 부족
    • linked scheme, multi-level index등으로 해결은 가능하나 index만큼의 공간낭비

실제 파일 시스템

UNIX 파일 시스템

출처: 강의

UNIX 파일 시스템은 4부분으로 나뉨

  • Boot block - 부팅에 필요한 정보
  • Super block - 파일 시스템에 관한 총체적인 정보(어디가 빈 블록이고 실제 사용중인 블록인지 등의 정보)
  • Inode list
    • 파일 하나당 Inode가 할당 됨. Inode 내에는 파일에 대한 메타데이터가 있다.
    • 실제로는 디렉토리가 파일의 메타데이터를 가지고 있지만, 일부의 메타데이터만 가지고 있다.
      • 디렉토리는 파일 이름과 inode번호를 가지고 있다.
    • 작은 파일같은경우는 direct blocks 정보만 가지고도 파일의 위치를 표현 가능하다.
    • 큰 파일의 경우는 single double triple indirect로 파일의 위치를 담고있을 수 있다.
  • Data block - 파일의 실제 내용을 보관

 

FAT file system

출처: 강의

 

4가지로 나뉨 하지만 안에 정보들이 다름.

  • Boot block
  • FAT
    • data block의 개수만큼 각 블록의 다음위치에 대한 정보를 담고 있다.
    • 여기서는 directory가 file이름과 파일의 메타데이터 정보와 파일의 시작블록 번호를 담고 있다.
    • 직접접근이 가능함. 어떻게 가능하냐?
      • FAT은 테이블이라 메모리에 올라가 있음.
      • 실제 파일을 까봐서 다음접근으로 가는것이 아니라 바로 접근이 가능하다.
    • linked allocation에서 reliability 문제를 해결하기 위해 2copy이상을 두고 있음.
  • Root directory
  • Datablock

Free-Space Management

: 비어있는 정보를 어떻게 관리하느냐?

 

Bit map(= bit vector)

출처: https://www.slideshare.net/eranuratirahtohir/chapter-3-32885905

  • 각 블럭을 bit map으로 만들어 0이면 free 1이면 쓰고 있음
  • 부가적인 공간을 필요로 함.
  • 연속적인 n개의 free block을 찾는데 효과적

Linked list

출처: https://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/12_FileSystemImplementation.html

  • 비어있는 공간들을 연결
  • 연속적인 가용공간을 찾는 것은 쉽지 않다.
  • 공간의 낭비가 없다.

 

Grouping

출처: https://slideplayer.com/slide/5094153/

  • linked list의 변형
  • 각 블록은 n개의 free block 포인터를 가지고 있다. 
  • n-1 번째 포인터는 다음 free block 인덱스 포인터를 가지고 있다.
  • 연속적인 공간을 찾기 힘듬

Counting

출처:  https://slideplayer.com/slide/5094153/

  • Grouping에서 변형
  • 빈 블록의 위치와 몇개가 있는지에 대한 정보를 가지고 있음.
  • 여러 개의 연속적은 block을  할당하고 반납

Directiory Implementation

Linear list

  • <file name, file의 메타 데이터> 의 리스트
  • 구현이 간단
  • 디렉토리 내에 파일이 있는지 찾기 위해서는 linear search가 필요(time-consuming)

Hash Table

  • linear list + hashing
  • hash function F
    • 1 <= F(file name) <= n의 메타데이터 사용
    • 파일 이름이 아닌 linear list 위치를 찾아줌
  • Collision 발생 가능

File의 메타데이터는 inode나 FAT에 저장됨

file name이 entry보다 길 경우 다음 파일 이름의 포인터를 두어 해결


VFS and NFS

출처: 강의

 

VFS(Virtual File System)

  • 서로 다른 다양한 file system에 대해 동일한 API로 접근 가능하게 해주는 OS의 layer

NFS(Network File System)

  • 분산 시스템에서는 네트워크를 통해 파일이 공유 될 수 있음
  • 서버와 클라이언트 둘 다  NFS 인터페이스를 갖고 있어야 함

Page cache and Buffer Cache

 

출처: https://jhi93.github.io/category/os/2019-12-28-operatingsystem-10-3/

Page cache

  • Virtual memory의 paging system에서 caching 사용하는 용어
  • Memory-Mapped I/O를 쓰는 경우 file I/O에서도 page cache 사용

Memory-Mapped I/O

  • file의 일부를 virtual memory에 매핑 시킴
  • 매핑시킨 영역에 대한 메모리 접근 연산은 파일의 입출력을 수행

Buffer cache

  • 파일시스템을 통한 I/O 연산은 메모리의 특정 영역인 buffer cache 사용
  • FIle 에 대한 locality 활용 가능 -> Replacement algorithm 필요(LRU, LFU 등)
  • 모든 프로세스가 공용으로 사용

두개를 결합한 Unified Buffer Cache

: 버퍼캐시를 페이지캐시로 관리하는 것임

출처: 강의

  • 기존에는 Memory-mapped I/O같은 경우 버퍼캐시에서 페이지캐시로 항상 복제해야되는 문제가 있었음
  • unified되고나서는 한단계가 사라짐.

  • 파일I/O는 두가지가 존재함 - read/write 시스템 콜과 memory mapped I/O
  • code부분은 swap area에 존재하지 않고 file system에 실행파일로서 존재함
  • 데이터 파일도 파일 시스템 안에 존재함
  • 시스템 콜은 physical을 logical memory로 copy해주는 과정이 있음
  • memory mapped I/O는 physical memory에서 mapping하여 사용하기 때문에 consistency 문제가 발생할 수 있음
Comments