운영체제#12

LeeMir, 03 May 2021

4강 - File Systems(이어서)

File Operations / Directory Operations
  • Create / Read / Write / Delete / Open / Close / Append / Seek / Get Attributes / Set Attributes / Rename
  • Create / Readdir / Delete / Opendir / Closedir / Rename / Link / Unlink
Directory(Folder)
  • Directory는 UNIX, Folder는 Windows 용어
  • 일반 Data File과 같음
    • 갖고 있는 정보가 Table 형태로 다른 File이나 Subdirectory의 정보를 갖고 있을 뿐
  • File 이름을 다른 정보(속성)와 매핑
  • 계층적 구조(트리 구조)를 지님
File Name and Path Name
  • File 이름은 다른 Directory에 있다면 같아도 되지만, 같은 Directory에 있으면 같으면 안됨
    • File System마다 File 이름을 정하는 규칙이 다 다름
      • MacOS와 UNIX의 경우 확장자를 .으로 구분하지 않음
  • 절대 주소(Absolute Path)
    • Root Directory부터 표기하는 주소
  • 상대 주소(Relative Path)
    • 현재 Working Directory부터 표기
    • ..이 상위의, .이 현재의 Directory를 나타냄
File System 설계
  • File System Layout
    • File System은 Sector 여러 개를 모은 Block이라는 단위를 사용함
    • 하드디스크의 첫번째 레코드에는 MBR(Master Boot Record)이, 두번째 레코드에는 Partition Table이 있음
      • MBR은 Disk의 Parition 중 Boot Partition을 찾아서 Boot Code를 Main Memory에 올림
      • Partition Table에는 각 Partition의 시작 주소와 Size가 담겨있음
  • File Allocation Methods
    • Contiguous allocation
      • 가장 간단한 방법
      • File을 연속적인 Block들에 할당하는 방법
      • 입출력 효율이 매우 좋음
      • 빈 Block들이 있어도 연속적이지 않으면 할당하지 못함
        • 공간 효율이 떨어지기 때문에 수정이 불가능한 CD-ROM 같은 저장장치에서 사용
    • Chained allocation: non-contiguous allocation
      • 각 Data Block에 다음 Data Block의 번호를 같이 저장함
        • File Data에 Meta Data를 같이 저장하는 것은 굉장히 좋지 않은 방법임
        • File Data에 Error 발생 시 Meta Data도 읽을 수 없어져 다음에 연결된 Block들을 모두 읽을 수 없음
      • 중간에 있는 번호의 Block을 읽고 싶어도 처음부터 읽어나가야 함
      • 만약, 다음 Block 번호를 저장하는 별도의 File Allocation Table을 사용하면 효율을 높일 수 있음
        • File Allocation Table
          • Root Dir Block는 항상 6번에 있음
          • Root를 포함한 각 Directory Block에는 File의 이름과 첫번째 주소, Size, 속성 등 File의 모든 정보가 저장되어 있음
        • 대용량 File System의 경우 FAT Chain을 쫓는 것만도 벅차서 MS사에서는 이 방법을 사용하지 않음
    • Indexed allocation: non-contiguous allocation
      • File의 Data Block 사이에 Index Block이 존재
      • Index Block에는 File 내 Data Block들의 Block 번호가 모두 저장되어 있음
      • UNIX File System에서는 Index Block을 i-node라고 부름
        • UNIX 설계자가 i-node 0번과 1번은 비워놓음, 2번 i-node에 Root Directory의 정보가 저장되어 있음
        • 각 Directory에서는 File의 이름과 i-node block의 번호가 저장되어 있음
        • i-node block에는 File의 이름을 제외한 모든 정보들과 Data Block들의 위치가 저장되어 있음
          • i-node의 address field도 최대 13개로 제한이 있기 때문에 큰 File을 다 담을 수 없음
          • 앞에 10개는 직접 주소 지정을 하고, 뒤의 3개는 큰 File을 대비해 Single / Double / Triple Indirect 방식을 사용함
            • Data Block이 Index Block의 역할을 하게 함
        • 현재 Directory라는 개념이 있어, 현재 Directory의 i-node를 기록해놓았다가 어떤 명령이 수행되면 그 i-node부터 읽어서 Data Block으로 넘어감
Implementing Directories
  • Directory에서 File 이름의 크기를 가변적으로 사용하려면 어떻게 해야할까?
    • 이름의 크기를 저장하는 공간을 만들어 어디까지 File 이름인지 명시하게 함
    • 다만 4 byte 단위기 때문에 가변적이어도 빈 공간이 남을 수는 있음
      • 이를 방지하고자 Heap 영역에 모든 이름을 모아놓는 방법을 고안했으나, 쓰이지는 않음
Shared Files

  • UNIX에서는 서로 다른 여러 Directory에서 같은 자식을 가져서 같은 i-node를 가리킬 수 있음

    • 이를 Shared File이라고 부름

  • Shared File에서는 i-node에 이 File의 Owner와 이 File을 가리키는 상위 Directory 개수(link 개수)를 기록해놓음

    • 부작용이 매우 많음
      • Owner가 이 File을 지우기 위해 unlink한다고 해도 다른 Directory에서 가리키고 있었다면 지워지지 않음
      • Directory 구조에 Loop가 생김
        • 백업을 수행할 때 같은 File에 대해 여러 번 수행될 수 있음

  • 부작용을 예방하기 위해, Symbolic Link File이 권장되고 있음

    • 바로가기 파일이라고도 부름

    • Data로 원본 File의 Path가 적혀있음

    • 원본 File과는 전혀 별개인 File

Log-structed File System(LFS)
  • 하드 디스크에 Write할 때 효율성에 영향을 많이 주는 부분이 Seek Time
  • 효율을 높이고자 하드 디스크의 헤더를 File 위치로 이동하게 하지 말고 무조건 현재 헤더의 위치에서 순차적으로 기록 시작함
  • 기록할 때에는 새로운 File Data 뿐만 아니라 i-node, 필요에 따라 Super Block까지 같이 기록함
    • 이러면 i-node의 위치를 알기 힘든 문제점이 있음
    • 따라서 i-node map을 기록하고, 주기적으로 이를 update 해주는 방법을 사용
  • Cleaning(Garbage Collection)
    • 기존의 내용을 새로 쓸 경우 LFS에서는 덮어 쓰는 것이 아니라 순차적으로 기록을 할 뿐임
    • 따라서 기존의 내용은 쓸모 없어짐
    • 쓸모 없어진 기존의 내용 사이사이에 있는 새로 쓰이지 않은 valid한 Data Block의 경우에는 아직 쓸모 있는 상태
    • 따라서 쓸모 없는 내용을 한쪽으로 몰아서 Garbage Collection을 진행해 하나의 큰 빈 공간을 만들어 나중에 재활용하게 함
  • LFS는 쓰기 절차만 생각하면 효율적일 수 있겠으나, 읽기 절차나 Cleaning하는 절차까지 모두 따지면 그렇게 효율적이지는 않음
  • SSD와 같은 Flash Memory는 저장장치의 특성상 굉장히 큰 단위로 Garbage Collection을 하기 때문에 LFS와 적합함
Journaling File System
  • 전기가 나가는 등의 이유로 컴퓨터가 갑자기 꺼지고 재부팅을 하면, File System 검사를 진행함
    • File System 일관성이 깨져있기 때문
      • File 하나를 변경하면 i-node뿐 아니라 부모 Block 등 다수의 Block들을 변경해야하는데, 사고로 인해 이 중 하나라도 변경되어있지 않으면 일관성이 깨짐
    • 따라서 부팅할 때 검사를 진행하고, 일관성을 완벽히 맞춘 이후에 File System을 동작함
    • 시간이 굉장히 오래 걸림
  • Journaling
    • File System을 변경하기 전에 Log Area에 Log를 남기고, 작업을 마친 후에 이 Log를 지우는 방식
    • 만약 전기가 나가거나 하는 등의 이유로 재부팅을 할 경우, 전체 File System을 검사할 필요 없이 Log Area를 읽어서 하던 작업을 마저 하든지, 없던 일로 하든지 해서 빠른 복구가 가능함