[OS] File Sytem 강의 정리

Baedonguri·2022년 6월 22일
pintos운영체제
0
post-thumbnail

File and File System

File이란?

  • "A named collection of related information"

  • 일반적으로 비휘발성의 보조기억장치에 저장

  • 운영체제는 다양한 저장 장치를 file이라는 동일한 논리적 단위로 볼 수 있게 해 줌

  • Operation
    -create, read, write, reposition (Iseek), delete, open, close 등

File attribute (혹은 파일의 metadata)

  • 파일 자체의 내용이 아니라 파일을 관리하기 위한 각종 정보들
  • 파일 이름, 유형, 저장된 위치, 파일 사이즈 등
  • 접근 권한 (읽기/쓰기/실행), 시간 (생성/변경/사용), 소유자 등

File system

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

Directory and Logical Disk

Directory

  • 파일의 메타데이터 중 일부를 보관하고 있는 일종의 특별한 파일

  • 그 디렉토리에 속한 파일 이름 및 파일 attribute들

  • operation (해당 디렉토리에 적용)
    -> search for a file, create a file, delete a file
    -> list a directory, rename a file, traverse the file system

Partition (=Logical Disk)

  • 하나의 (물리적) 디스크 안에 여러 파티션을 두는게 일반적
    -> 물리적 디스크를 내부적으로 여러개의 논리 디스크로 분리해서 사용

  • 여러 개의 물리적인 디스크를 하나의 파티션으로 구성하기도 함

  • (물리적) 디스크를 파티션으로 구성한 뒤 각각의 파티션에 file system을 깔거나
    swapping(swap area) 등 다른 용도로 사용할 수 있음.

OPEN

  • open은 file의 meta data를 메모리로 올려놓는 연산

논리적인 디스크 안에 file system이 있으면, 그 file system의 meta data도 저장되어 있고
그 file의 내용도 저장되어 있음.

open("/a/b/c")

디스크로부터 파일 c의 메타데이터를 메모리로 가지고 옴

이를 위하여 directory path를 search 수행

1. 루트 디렉토리 "/"를 open하고 그 안에서 파일 "a"의 위치 획득	

2. 파일 "a" open한 후 read하여 그 안에서 파일 "b"의 위치 획득

3. 파일 "b"를 open한 후 read하여 그 안에서 파일 "c"의 위치 획득

4. 파일 "c" open한다.
  • 이 방식은 Directory path의 search에 너무 많은 시간 소요되기 때문에
    Open을 read/write와 별도로 두는 이유이기도 하다.
    -> 한번 open한 파일은 read/write 시 directory search 불필요

Open file table

  • 현재 open 된 파일들의 메타데이터 보관소 (in memory)

  • open된 file을 관리하는 global한 table

  • 디스크의 메타데이터보다 몇 가지 정보가 추가
    -> Open한 프로세스의 수
    -> File offset: 파일 어느 위치 접근 중인지 표시 (별도 테이블 필요)

  • File descriptor (file handle, file control block)

  • Open file table에 대한 위치 정보 (프로세스 별)

open 수행 절차

open 시스템콜이 호출되면 해당 디렉토리에 방문하여 해당 디렉토리의 메타 데이터를
Open file table에 올려두게 되는데, 최종 목적지의 meta data를 가리키는 포인터를
PCB에 위치한 FDT 배열의 인덱스로 사용한다. 이것이 fd

read 수행 절차

결국 이 fd는 "b"를 가리키는 값이 될 것이고, 이 fd를 통해 read system call을 호출하게 된다.
read를 수행하면 "b"의 content를 읽는데, 이것을 바로 유저 프로그램에게 전달하지 않고
운영체제가 자신의 메모리 공간에 넣어둔 뒤, 복사본을 유저 프로그램에게 전달해준다.

복사본을 주는 이유는, 다른 프로세스에서 같은 파일을 요청했을 때, 메모리에 올려둔 것을 주면
굳이 디스크까지 다녀올 필요가 없어지기 때문이다. 이것이 buffer caching.
만약 운영체제가 butter cache에 들고 있지 않다면, 디스크에서 읽어오고
들고 있다면 바로 넘겨준다. (paging 기법과 유사하다)

하지만 같은 파일이지만 프로세스마다 파일의 다른 위치를 읽기을 원할 수 있으므로
각 프로세스마다 필요한 offset 같은 정보를 따로 기억해두고 있어야 한다.

File Protection

file에 대한 접근 권한을 제어하는 방법은 크게 3가지가 있다.

Access control

Matrix에 각각의 사용자가 어떤 읽기/쓰기 권한을 가지고 있는지 표시를 해주고,
이를 확인하는 방식이다.
하지만 이 행렬의 칸을 모두 만들게 되면 낭비일 수 있다.
그래서 이를 linked-list로 구성하는 방법을 생각할 수 있는데

Acess Control List의 경우, 파일을 주체로 권한을 가진 user를 연결 할 수 있고,
Capability List의 경우, 유저를 주체로 권한을 가진 file들을 연결할 수 있다.

Grouping

일반적인 운영체제에서는 이 방식을 통해 파일에 대한 접근 권한을 제한한다.
모든 사용자에 대해 접근 권한을 다루는 것이 아닌, 파일에 대해 3 그룹으로 나눈다.

해당 그룹을 사용하는 동일한 사용자에 대해 연결하는 방식으로,
하나의 파일에 대한 접근 권한을 체크하기 위해 단 9개의 비트만 사용할 수 있다.

Password

모든 file에 password를 두거나, 디렉토리에 password를 거는 방식인데,
접근 권한별로도 password를 둬야하기 때문에 외우기도 어렵고, 관리가 어려울 수 있음.

File System의 Mounting

하나의 물리적인 디스크를 partitioning을 통해 여러개의 논리적인 디스크로 나눌 수 있는데
각 논리 디스크마다 file system을 설치할 수 있다.

mounting은 root 디렉토리 이름에 또 다른 파티션에 있는 file system에 마운팅을 해주면
마운팅을 통해 해당 root 디렉토리에 접근할 수 있게 된다.

Access Methods

파일 접근 방법은 시스템이 제공하는 파일 정보의 접근 방식을 뜻한다.
디스크가 파일에 접근하는 방식은 순차접근과 직접 접근 두 가지 방식이 있다.

순차 접근 (sequential access)

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

직접 접근 (direct access, random access)

  • LP 레코드 판과 같이 접근하도록 함
  • 파일을 구성하는 레코드를 임의의 순서로 접근할 수 있음.

Allocation of File Data in Disk

디스크에 파일을 저장하는 방법은 3가지가 존재한다.
파일의 형태를 생각해보면, 모든 파일은 그 크기가 균일하지 않다. 어떤 파일은 엄청나게 클 수도, 어떤 놈은 겁나 작을 수도 있다. 하지만 모두 동일한 크기의 섹터 단위로 파일을 저장하는데,
즉, 블록 단위로 나누어서 파일을 저장하는 것이다.

Contiguous Allocation

하나의 파일이 디스크 상에 연속적으로 저장되는 방식을 뜻한다.
블록 n개로 구성되는 파일을 디스크 상에서 n개 블록에 연속으로 걸쳐서 저장하는 방식.

한번의 seek/rotation으로 많은 바이트 transfer함으로써 Fast I/O가 가능한 장점이 있으며,
직접 접근이 가능하다.
하지만 이러한 방식은 외부 단편화를 발생시킬 수 있고, 파일을 수정해 크기를 늘리기가(file growth) 어렵다. 그 이유는 파일은 중간에 크기가 변할 수 있는데, 연속 할당이라는 규칙에서는 뒷 블록에 다른 파일이 자리하고 있으면 크기를 늘릴 수 없기 때문이다.

Linked Allocation


빈 위치 아무곳에 넣고 linked 해서 할당하는 방식.
file의 시작 위치와 종료 위치만 디렉토리에 저장해두면 file을 모두 읽을 수 있다.

이 방식을 사용하면 External fragmentation이 발생하는 문제를 해결 할 수 있지만,

직접 접근이 불가능한데, 모든 블록을 순차적으로 읽어야 해당 file을 읽을 수 있는 것이다.
또한 Reliability 문제가 존재하는데, 한 sector가 고장나 pointer가 유실되면 많은 부분을 잃을 수 있으며,
Pointer를 위한 공간이 block의 일부가 되어 공간 효율성을 떨어뜨린다.

이것의 의미는 데이터를 저장하기 위한 공간이 512 bytes/sector인데, 포인터 저장하기 위해 4 bytes/pointer를 사용해야 하므로 공간 효율성이 떨어지는 것이다.

Indexed Allocation

디렉토리는 index block이라는 인덱스 번호만 저장하고 있고,
이 index block에는 해당 파일에 연결된 index들이 저장되어 있는 방식이다.

직접 접근이 가능하다는 장점이 있고, 외부 단편화도 발생하지 않는다.

하지만 Small file의 경우에도 무조건 2개의 block을 가지므로 공간이 낭비될 수 있는 단점이 존재하고, 반대로 겁나게 큰 file의 경우, 하나의 block으로 Index를 저장하기에 부족할 수 있는 경우도 존재한다.

UNIX File System

  1. Boot block 
    컴퓨터 부팅 관련한 총체적인 정보가 들어있는 디스크로, 디스크 가장 앞쪽에 위치해있다.
    UNIX뿐만 아니라 어떤 파일 시스템이던지 Boot block이 가장 맨 앞에 있다. 어떤 파일 시스템을 쓰던 0번 블록에 부팅에 필요한 정보(Bootstrap loader)를 메모리에 올리면 복잡한 로직 없이 부팅을 바로 진행할 수 있기 때문이다.

  2. Super block
    파일 시스템과 관련한 총체적인 정보를 담고 있다. 어디가 비어있는 블록이고 어디가 실제 사용 중인 블록인지에 대한 정보를 담고 있다고 보면 된다.

  3. Inode list
    파일 이름을 제외한 파일의 모든 메타 데이터를 저장하는 영역이다.
    원래 파일 메타데이터는 어디에 저장되어 있을까? 디렉토리 파일 내부에 저장되어 있다.하지만 실제 파일 시스템에서는 파일의 메타데이터를 모두 디렉토리 파일이 갖고 있지 않다. 유닉스 파일 시스템의 경우 디렉토리는 지극히 일부분(파일 이름 등)만 갖고 있고 실제 파일의 메타데이터는 별도 공간에 따로 보관하는데, 여기가 inode list이다.

아래 이미지를 보면 inode list 안에 빨간 블록이 여러 개 들어있는데, 이 하나하나가 inode에 해당한다. inode 하나당 파일 하나가 매핑되는데, 이 inode에는 매핑된 파일의 메타데이터가 들어있다. (이때 주의! 파일의 이름은 디렉토리가 갖고 있다.)
아래 direct block은 파일 내 블록에 직접 접근할 수 있는 블록 위치를 저장하는 영역이다. 이렇게 direct block으로 각 블록 별 위치 정보를 저장하고 있으면 모든 데이터에 직접 접근이 가능해진다는 장점이 있다. 가장 아랫쪽의 single/double/triple indirect 블록은 파일의 크기가 클 경우 inode list 안에 모든 direct 블록을 다 담을 수 없기 때문에 중간에 거쳐갈 수 있는 자료구조를 담는 영역이다.

  1. Data block

    데이터 블록 내에 디렉토리 파일을 하나 열었다고 해보자. 해당 디렉토리 파일 내에는 파일 메타데이터(file 이름과 inode 번호)가 들어있는데,나머지 파일 메타데이터는 inode 번호를 통해 찾아갈 수 있는 inode list에 보관되어 있다.

FAT File System

FAT 파일 시스템은 UNIX 파일 시스템 구조와 비슷해보이지만 두 가지가 다르다.
1) Inode list 대신 FAT가 존재
2) super block 대신 Root directory가 존재

FAT
파일 메타데이터 중 일부를 FAT에 저장한다. 여기서 FAT에 저장하는 일부 데이터는 파일 위치 정보에 해당하며,
나머지 메타데이터는 루트 디렉토리에 저장한다. 따라서 FAT을 확인해보면 데이터 블록에 있는 해당 파일 contents로 곧바로 접근이 가능하다. 이 역시 직접 접근이 가능한 구조에 해당한다.

예를 들어 파일의 네 번째 블록을 본다고 해보자. FAT은 부팅이 시작되고 나면 통째로 메모리에 올라와 있다. 이 파일의 네 번째 블록을 가려면 메모리 내 FAT 테이블 안에서 위치를 계속 확인해 최종 위치까지 갈 수 있다. 여기서 핵심은 디스크 헤드를 움직이는 게 아니라 FAT 테이블을 메모리에 올려놓고 메모리 안에서 왔다갔다해서 찾아내는 방식이라는 점이다.

이와 같은 방식을 적용하면 포인터가 하나 유실되더라도 FAT에 위치 데이터가 보관되어 있으니 문제되지 않는다. 게다가, FAT는 매우 중요한 정보기 때무에 여러 copy를 디스크 내에 저장해두고 있다. 즉, 하나만 있지 않다. 이를 통해 reliability를 개선할 수 있다. 또한, FAT를 통해 직접 접근이 가능하므로 linked allocation 문제 역시 해결한다.

Root Directory
FAT 구조에서는 루트 디렉토리에 위치를 제외한 나머지 파일 메타데이터를 저장하고 있다.

Page Cache and Buffer Cache

page cache

  • VM의 페이징 시스템에서 사용하는 페이지 프레임을 캐싱 관점에서 설명하는 용어
  • memory-mapped I/O를 쓰는 경우 file I/O에서도 page cache 사용

Memory-mapped I/O

  • File 일부를 virtual memory에 매핑
  • 매핑시킨 영역에 대한 메모리 접근 연산은 파일 입출력을 수행하게 한다.

Buffer cache

  • 파일 시스템 통한 I/O 연산은 메모리 특정 영역인 buffer cache 사용
  • 파일 사용의 locality 활용
    - 한번 읽어온 블록에 대한 후속 요청시 버퍼 캐시에서 즉시 전달
  • 모든 프로세스가 공용으로 사용하는 캐시
  • Replacement algorithm 필요(LRU, LFU 사용 가능 → 모든 정보를 운영체제에서 관리하기 때문! page swap에서는 이게 불가능했음)

Unified Buffer Cache

  • 최근 OS에서는 기존 buffer cache가 page cache에 통합됨
profile
Baedonguri
Software Engineer
이전 포스트

[PintOS] Project3 - Stack growth (3)

다음 포스트

[PintOS] Project3 - Memory Mapped Files(4)

0개의 댓글