[운영체제 10주차] - 파일 시스템

Suntory(SY Kim)·2022년 4월 12일
1

OS

목록 보기
10/11
post-thumbnail

반효경 교수님의 운영체제 강의와 Operating System Concepts 10th ed. 를 참고하였습니다.

파일, 파일 시스템

파일

  • A named collection of related information
  • 일반적으로 비휘발성의 보조 기억장치에 저장
  • 운영체제는 다양한 저장 장치를 file이라는 동일한 논리적 단위로 볼 수 있게 해줌
  • 파일의 연산
    • create
    • read
    • write
    • reposition (lseek): 파일의 시작 부분이 아닌 임의 위치를 읽기 위해서 사용
    • delete
    • open: read나 write를 하기 위해서는 먼저 실행되어야 하는 연산
    • close: 모든 작업이 끝나면 하는 연산

파일의 속성(메타데이터)

  • 파일 자체의 내용이 아닌 관리를 위한 각종 정보들
    • 파일 이름
    • 파일 유형
    • 저장된 위치
    • 파일의 크기
    • 접근 권한
    • 시간
    • 소유자 등

파일 시스템

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

디렉토리

디렉토리

  • 디렉토리도 곧 파일이다.
  • 파일의 메타데이터 중 일부를 보관하고 있는 일종의 특별한 파일
  • 그 디렉토리에 속한 파일 이름 및 파일 메타데이터들
  • 연산
    • 파일 탐색, 파일의 리스트, 지우기, 파일 이름 변경 등

파티션(=Logical Disk)

  • 하나의 물리적 디스크 안에 여러 파티션을 두는 게 일반적
  • 여러 개의 물리적인 디스크를 하나의 파티션으로 구성하기도 함
  • 디스크를 파티션으로 구성한 뒤 각각의 파티션에 file system을 깔거나 swapping 등 다른 용도로 사용할 수 있음

Open 연산

  • 파일 시스템에서 파일의 메타데이터를 메모리에 올리는 연산
  • open("/a/b/c/")
    • 디스크로부터 파일 c의 메타데이터를 메모리(system-wide open file table)로 가지고 옴
    • 루트 디렉토리는 알려져있으므로 계층적으로 내려가며 위치를 찾는다.
    • 사용자 프로세스가 시스템 콜을 통해 파일을 open한다.
    • 운영체제는 root의 metadata를 메모리에 올린다.
    • metadata를 통해서 실제 content를 찾는다.
    • content에 들어있는 "a"의 metadata를 메모리에 올린다.(open)
    • 반복하면서 원하는 파일을 찾을 때까지 metadata를 메모리에 올린다.
    • open 연산은 프로세스가 열고있는 파일들이 저장된 배열(per-process file descriptor table)의 인덱스를 file descriptor로 return해준다.
    • read를 하면 file descriptor를 통해 원하는 파일의 내용을 읽도록 명령한다. 그럼 시스템 콜이므로 운영체제가 디스크의 해당 위치를 읽어다가 운영체제 공간에 복사해두고 사용자 프로세스에 전달한다. 만일 똑같은 내용을 다른 프로세스가 요청한다면 버퍼 캐싱을 통해 디스크를 읽어오지 않고 메모리상에 저장된 정보를 바로 응답해준다.
    • 별도로 프로세스 별로 읽고 있는 offset을 나타내는 테이블을 별도로 관리한다.

File Protection

  • 각 파일에 대해 누구에게 어떤 유형의 접근을 허락할 것인가?

  • Access Control 방법

    • Access control Matrix

      • 각 user와 file을 행렬 형태로 권한을 정리해 둔 형태
      • 단, 낭비되는 공간이 많아진다. (특정 사용자만 사용하는 파일이 존재하는 경우)
    • ACL (Access Control List)

      • 각 파일에 대한 사용자의 권한을 연결리스트를 활용하여 불필요한 공간을 줄인 형태
    • Capability

      • 사용자별로 자신이 접근 권한을 가진 파일 및 해당 권한 표시
    • Grouping

      • 전체 user를 owner, group, public의 세 그룹으로 구분
      • 각 파일에 대해 세 그룹의 접근 권한을(rwx)을 3비트씩으로 표시
      • rwxr--r-- 의 형태 (744)
    • Password

      • 파일마다 password를 두는 방법 (디렉토리에도 가능)
      • 모든 접근 권한에 대해 하나의 password: all-or-nothing
      • 접근 권한별 password: 암기, 관리의 문제

File System의 Mounting

  • 특정 디렉토리에 다른 파일 시스템을 마운트하면 루트 디렉토리에 접근이 가능해진다.

Access Methods

  • 순차 접근
    • 카세트 테이프를 사용하는 방식처럼 접근
    • 읽거나 쓰면 offset이 자동적으로 증가
  • 임의 접근
    • LP 레코드 판과 같이 접근하도록 함
    • 파일을 구성하는 레코드를 임의의 순서로 접근할 수 있음

Allocation of File Data in Disk

Contiguous Allocation

  • 임의의 크기의 file을 동일 크기의 block 단위로 저장하고 있다. 메모리 관리 기법 중 페이징과 유사하다.
  • 하나의 파일이 디스크 상에 연속해서 저장되는 기법이다.

단점

  • 파일과 파일 사이의 외부 조각이 발생한다.
  • 파일의 크기가 커지는 데에 제약이 생긴다.
    • 미리 hole을 할당하는 방법 -> 낭비, 여전히 문제

장점

  • Fast I/O -> 연속적으로 할당돼있으므로 찾기 쉽다.
    • realtime file이나 swap area로 사용할 때 많이 사용한다. 공간이 좀 낭비되더라도 속도가 생명이기 때문이다.
  • Direct access 가능 -> 앞에서부터 블록을 일일이 확인하지 않고 길이만 알면 바로 접근이 가능하다.

Linked Allocation

  • 연속적으로 할당하지 않고 각 block을 연결리스트 형태로 연결해둔 형태

장점

  • 외부 조각이 발생하지 않는다.

단점

  • 직접 접근이 불가능하다. -> 탐색 속도가 느려진다.
  • Reliability 문제 -> disk의 bad sector 문제가 발생하면 pointer가 유실되어 뒷부분을 다 놓칠 수 있다.
  • Pointer를 위한 공간이 필요하므로 공간 효율성이 떨어진다.
    • 512 bytes/sector, 4 bytes/pointer 차지

변형

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

Indexed Allocation

  • 각 파일마다 index block이라는 공간에 해당 파일을 구성하는 내용에 해당하는 block을 적어둔다.

장점

  • 외부 조각이 발생하지 않음
  • 직접 접근이 가능하다.

단점

  • Small file의 경우에도 최소한 2개의 블럭이 필요하다.
  • Too large file의 경우 하나의 block으로 모든 block을 표현할 수 없다.
    • linked scheme -> index block을 linked list 형태로 구성
    • multi-level index -> index block의 index를 관리하는 방법

UNIX 파일시스템의 구조


  • 맨 위의 boot block은 모든 파일 시스템이 공통적으로 가지고 있다. 맨 처음 부팅이 될 때 필요한 정보를 실행하기 위해 맨 위에 위치한다.

  • Super block은 파일 시스템에 필요한 총체적인 정보, 어디가 빈 블록이고 차있는 블록인지 등을 관리한다.

  • 실제 파일의 메타데이터는 디렉토리에 전부 저장되지 않고, 일부만 저장된다. 나머지는 Inode list에 각 파일의 메타데이터가 저장된다. inode 하나 당 각 파일의 메타데이터가 저장되어 있다. 파일의 이름만 디렉토리가 저장한다.

  • directory file이 [file 이름, inode 번호] 형태로 자료를 보관한다.

  • 파일의 위치정보는 어떻게 관리할까?

    • indexed allocation을 활용한다. inode는 파일마다 크기가 고정되어 있다. 그렇기 때문에 포인터 개수도 유한하다. 하지만 큰 파일도 inode 크기 내에서 표현이 가능해야 한다. 작은 파일은 direct block를 통해 파일의 위치를 표현한다. 큰 파일은 single indirect, double indirect, triple indirect 등의 multi-level index를 활용한다.
    • 작은 파일은 inode만 open하여 메모리에 올리면 직접 접근이 가능하다.
    • 큰 파일은 추가로 indirect를 접근하면 접근이 가능해진다.

FAT File System

  • Boot block: 부팅과 관련된 정보
  • FAT: 파일의 메타데이터 중 위치정보만을 FAT에 보관한다.
  • 나머지는 메타데이터는 디렉토리가 보관한다.
  • linked allocation 형태의 위치정보를 블록에 담고있는 것이 아니라, FAT에 저장한다.
  • 배열 형태로 각 블록의 다음 블록을 저장하고 있다.

장점

  • 배드섹터가 발생하더라도 FAT에서 pointer를 관리하므로 reliability 해결
  • FAT 테이블만 메모리에 올려두면 디스크의 block에 직접 접근이 가능하다.
  • 공간 효율성 문제 해결

Free-Space Management

Bit map or bit vector

  • 각 data block의 번호에 따라 비트로 사용중/비어있음을 표시
  • bitmap에 필요한 추가적인 공간 필요(1 bit per 1 block)
  • 연속적인 n개의 free block을 찾는데 효과적

Linked list

  • 모든 free block들을 링크로 연결
  • 연속적인 가용공간을 찾는 것은 쉽지 않다.
  • 공간의 낭비가 없다.

Grouping

  • indexed list와 유사
  • 첫번째 free block이 n개의 pointer를 가짐
    • n-1 pointer는 free data block을 가리킴
    • 마지막 pointer가 가리키는 block은 또 다시 n pointer를 가짐

Counting

  • 프로그램들이 종종 여러 개의 연속적인 block을 할당하고 반납한다는 성질에 착안
  • (first free block, # of contiguous free blocks)

Directory Implementation

  • Linear list

    • <File name, file의 metadata>의 list
    • 각 field의 크기는 고정
    • 구현이 간단
    • 디렉토리 내에 파일이 있는지 찾기 위해서는 linear search(O(N)) 필요
  • Hash Table

    • linear list + hashing
    • Hash table은 file name을 이 파일의 linear list의 위치로 바꾸어줌
    • 직접 접근이 가능하므로 search time이 없음
    • 해시 충돌 발생 가능
  • File의 metadata의 보관 위치

    • 디렉토리 내에 직접 보관
    • 디렉토리에는 포인터를 두고 다른 곳에 보관
      • inode, FAT 등
  • Long file name의 지원

    • <file name, file의 metadata>의 list에서 각 entry는 일반적으로 고정 크기
    • file name이 고정 크기의 entry 길이보다 길어지는 경우 entry 마지막 부분에 이름이 뒷부분이 위치한 곳의 포인터를 두는 방법
    • 이름의 나머지 부분은 동일한 directory file의 일부에 존재

VFS and NFS

VFS (Virtual File System)

다양한 파일 시스템이 존재하지만, 사용자 입장에서 동일한 API를 통해 시스템 콜을 보낼 수 있도록 VFS 계층을 두고 있다.

NFS (Netrwork File System)

분산 시스템에서는 다른 컴퓨터의 파일 시스템에 접속할 수 있다. 네트워크를 통해 파일이 공유될 수 있다. NFS가 분산 시스템에서의 대표적인 파일 공유 시스템이다.

Page Cache and Buffer Cache

Page Cache

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

Memory-Mapped I/O

  • File의 일부를 virtual memory에 mapping시킴
  • 메모리에 이미 올라와있으므로 시스템 콜이 필요없음
  • 메모리 상에 데이터를 읽고 쓰는 것처럼 파일에 읽고 쓸 수 있다.
  • 매핑시킨 영역에 대한 메모리 접근 연산은 파일의 입출력을 수행하게 함

Buffer Cache

  • 파일 시스템을 통한 I/O 연산은 메모리의 특정 영역인 buffer cache 사용
  • File 사용의 locality 활용
  • 모든 프로세스가 공용으로 사용
  • Replacement algorithm 필요 (LRU, LFU) -> 무조건 시스템 콜을 통해 일어나므로 운영체제가 LRU를 활용할 수 있다.

Unified Buffer Cache

  • 최근의 OS에서는 기존의 buffer cache가 page cache에 통합됨

Unified Buffer Cache를 사용하지 않으면, memory-mapped I/O를 쓰는 경우에 page cache와 커널 영역의 buffer cache를 두 번 거쳐야 한다.

하지만 Unified Buffer Cache를 사용하면, buffer cache가 곧 page cache이므로 page cache(=buffer cache)에 한번 접근하는 것만으로 I/O 처리가 가능하다.

Memory-mapped I/O를 쓸 때 처음 해당 페이지에 mapping된 파일을 읽으려고 하면 page fault가 발생한다. 그 때 시스템 콜을 통해 file system의 block을 해당 페이지에 올려놓는다. 그렇기 때문에 memory-mapped I/O를 쓰더라도 I/O 작업은 불가피하다.

프로그램의 실행

프로그램을 실행한다는 것은 File system에 저장된 실행파일을 실행하여 프로세스가 되고, 프로세스만의 독자적인 주소 공간이 생성된다. 이 주소공간 중 실행할 부분은 실제 메모리에 올라가고, 나머지는 swap area에 보관된다.

하지만 주소공간 중 code 영역은 이미 실행파일 형태로 read-only 형태로 저장되어있다. 메모리 주소 공간이 만들어질 때 data, stack 영역은 만들어져서 메모리에 올라가고 사용되지 않으면 swap area로 내려간다. 하지만 code 영역은 이미 실행파일에 들어있기 때문에 그냥 page를 삭제해버리고 필요해지면 swap area가 아닌 file system으로부터 이 영역을 불러온다.

이는 메모리에 프로세스를 올리는 loader가 쓰는 memory-mapped I/O의 일종이다. 프로세스의 주소공간 중 code 영역을 실행파일에 mapping시키는 것이다.

Memory-mapped I/O를 통해 데이터 파일을 사용하는 과정

어떤 프로세스가 데이터 파일을 memory-mapped I/O를 통해 사용하고자 할 때, mmap() 시스템 콜을 통해 해당 파일을 자신의 주소공간에 매핑한다. 그럼 실제 메모리 상의 페이지에도 파일에 매핑된 페이지가 존재할 것이다. 이 페이지를 조회하고자 하면 아직 매핑만 된 상태이고 파일이 올라오지 않았으므로 page fault가 발생한다.

이 때는 swap area에서 page를 불러오는 것이 아니라 file system에 가서 파일의 내용을 메모리에 올린다.

Read-Write system call을 통해 읽는 과정

어떤 프로세스가 데이터 파일을 사용하고자 할때, read() 시스템콜을 통해 운영체제가 현재 buffer cache(page cache)에 올라와있지 않은 데이터 파일을 buffer cache(page cache)에 등록한다. 그리고 사용자 프로세스 주소공간에 복사하여 사용할 수 있도록 해준다.

profile
천천히, 하지만 꾸준히 그리고 열심히

0개의 댓글