운영체제가 저장매체에 파일을 쓰기 위한 자료구조 또는 알고리즘

가볍게 알아두기: 파일 시스템이 만들어진 이유(블록)

• 0과 1의 데이터를 어떻게 저장매체에 저장할까?
  • 비트 단위로 관리하기는 오버헤드가 너무 큼
  • 블록 단위로 관리하기로 함 (보통 4KB)
  • 블록마다 고유 번호를 부여해서, 관리
• 사용자가 각 블록 고유 번호를 관리하기 어려움
  • 추상적(논리적) 객체 필요: 파일
• 사용자는 파일단위로 관리
  • 각 파일에는 블록 단위로 관리
• 저장매체에 효율적으로 파일을 저장하는 방법
  • 가능한 연속적인 공간에 파일을 저장하는 것이 좋음
    ㄴ단점은 외부 단편화.
  • 외부 단편화, 파일 사이즈 변경 문제로 불연속 공간에 파일 저장 기능 지원이 필요해졌다.
    • 블록 체인: 블록을 링크드 리스트로 연결
      ㄴ 끝에 있는 블록을 찾으려면, 맨 처음 블록부터 주소를 따라가야 함 (linkedlist)
    • 인텍스 블록 기법: 각 블록에 대한 위치 정보를 기록해서, 한번에 끝 블록을 찾아갈 수 있도록 함
      

가볍게 알아두기: 다양한 파일 시스템

• Windows: FAT, FAT32, NTFS
  ㄴ 블록 위치를 FAT라는 자료 구조에 기록
• 리눅스(UNIX): ext2, ext3, ext4
  ㄴ 일종의 인덱스 블록 기법인 inode방식 사용

파일 시스템과 시스템 콜

• 동일한 시스템콜을 사용해서 다양한 파일 시스템 지원 가능토록 구현
  • read/write 시스템 콜 호출시, 각 기기 및 파일 시스템에 따라 실질적인 처리를 담당하는 함수 구현
• 파일을 실제 어떻게 저장할지는 다를 수 있음
  • 리눅스의 경우 ext4외 NTFS, FAT32파일 시스템 지원

ㄴ파일을 다루는 기본적인 시스템콜은 정해져있다. 내부 파일 시스템이 달라도 시스템콜 함수는 같아서 동일하게 읽고/쓰기가 되어 다른 파일 시스템과 헷갈려할 일은 없다.

inode 방식 파일 시스템

파일 시스템 기본 구조

• 슈퍼 블록: 파일 시스템 정보 (파일 시스템 전체를 대표하는)
• 아이노드 블록: 파일 상세 정보 (마치 PCB 같은)
• 데이터 블록: 실제 데이터 (1KB~4KB)

슈퍼 블록

: 파일 시스템 정보 및 파티션 정보 포함

inode와 파일

파일: inode고유값과 자료구조에 의해 주요 정보를 관리

• '파일이름:inode'로 파일이름은 inode번호와 매칭
  ㄴ 사용자는 파일 이름만 알고 있지만 각 파일마다 inode번호가 해당되어 있다.
• 파일 시스템에서는 inode를 기반으로 파일 엑세스
  • 마치 prcess가 PCB정보를 기반으로 처리를 하듯:
    프로세스 생성 → Process ID 할당됨 → ID기반으로 PCB정보가 만들어지고 ← PCB정보를 통해 스케쥴링 등 여러작업을 실행
  • 파일생성 → inode번호 생성 → inode블록 생성(상세정보 들어있음) ← inode블록을 기반으로 파일처리함
• inode기반 메타 데이터 저장 (상세정보=메타 데이터)
  

inode 구조와 파일 데이터

• inode기반 메타 데이터
  (파일 권한, 소유자 정보, 파일 사이즈, 생성시간등 시간 관련 정보, 데이터 저장 위치등)

• cat files.txt (files.txt에 들어 있는 내용을 화면에 출력하라는 명령)

1. files.txt라는 해당 inode번호를 찾고
2. inode번호에 맞는 inode블록에 접근
3. 파일에 대한 내용을 출력을 위해 direct blocks에 접근
4. 해당 데이터를 읽어서 화면에 출력

   Direct Blocks: 해당 데이터 블록의 주소를 가지고 있다. 보통 12개 주소공간 소유, 그리고 각각의 주소공간은 실제 데이터 블록의 주소를 가리키고 있다.

• ls -al files.txt (files.txt파일의 상세정보 출력하라는 명령)

  

• inode블록 내의 파일 데이터 관리

• inode구조(Ext2, Ext3)에서 지원할 수 있는 파일의 최대 크기 (디스크 블록을 4KB로 가정)
  : 48KB + 4MB + 4GB + 4TB
  1) 직접 블록 지원 파일 크기는 48KB (4KB 12개)
  : 파일의 크기가 48K 미만이면 별도의 인덱스 블록이 필요없음
  2) 단일 간접 블록 지원 파일 크기는 4MB
  : 인덱스 블록 크기 4KB, 각 포인터는 4byte -> 1024개 포인터 (4KB 1024개)
  3) 이중 간접 블록 지원 파일 크기는 4GB
  4) 삼중 간접 블록 지원 파일 크기는 4TB

디렉토리 엔트리

/ : root directory

리눅스 파일 탐색: 예 -/home/ubuntu/link.txt

• 파일을 검색하기 위해 디렉토리 엔트리(Dentry)라는 구조를 가지고 있다
  • 각 엔트리는 해당 디렉토리 파일/디렉토리 정보를 가지고 있음
• root='/'dentry에서 'home'이라는 이름을 가진 디렉토리의 inode를 찾고, 'home'이라는 inode의 dentry 정보 안에 'ubuntu'를 찾고, 'ubuntu'에서 link.txt파일이름에 해당하는 inode를 얻음

가상 파일 시스템(Virtual File System)

파일시스템1, 2의 상위 파일시스템 인터페이스는 동일하다. 다른 디바이스에도 확장을 한다.

• Network등 다양한 기기도 동일한 파일 시스템 인터페이스를 통해 관리 가능
• 예) read/write 시스템콜 사용하더라도, 각 기기별 내부 시스템콜 read_spec/write_spec코드만 구현해둔다면(운영체제 내부) 어떤 기기든 상위 시스템콜로 동일하게 동작 가능

전통적인 유닉스 시스템에서는 모든 디바이스와 파일 시스템을 가상 파일 시스템을 파일처럼 다룬다.

참고: 리눅스(유닉스) 운영체제와 가상 파일 시스템
모든 것은 파일이라는 철학을 따름

• 모든 인터렉션은 파일을 읽고, 쓰는 것처럼 이루어져있음
• 마우스, 키보드와 같은 모든 디바이스 관련된 기술도 파일과 같이 다루어짐
• 모든 자원에 대한 추상화 인터페이스로 파일 인터페이스를 활용 (마치 차 내부 작동 원리 몰라도 운전할 줄은 아는)

참고: 특수 파일
디바이스 2가지로 나뉘어진다
1. 블록 디바이스(Block Device)
:HDD, CD/DVD와 같이(대용량 데이터가 오고 가기 때문에) 블록 또는 섹터 등 정해진 단위로 데이터 전송, IO송수신 속도가 높음
2. 캐릭터 디바이스(Character Device)
:키보드, 마우스 등 byte단위 데이터 전송, IO 송수신 속도가 낮음