Disk Scheduling 2




Request Queue
다음 그림과 같이 디스크에 대한 I/O Request가 들어오면 이를 저장하는 Queue.


Request Queue가 존재하는 위치
Device Driver와 Device 사이에 존재.

  • I/O scheduler
    Request Queue의 내용을 reorder(순서 변경) 하는 것. Device driver의 한 부분이다.

Request Queue의 순서를 잘 정했을 때 나타나는 성능 비교


Scheduling Policies

  • Shortest seek time first (SSTF)
    디스크 arm의 이동(movement)가 작은 순서로 처리하는 것. arm으로 부터 먼 실린더는 계속해서 기다리는 Starvation 문제를 발생시킨다.

실제 사용하는 스케쥴링 방법

  • Scan
    엘레베이터 알고리즘. arm을 한 방향으로 움직여 처리하는 방식. 양쪽 끝의 실린더는 한 번밖에 처리 기회가 주어지지 않는다는 문제점이 있다.
  • Circular scan
    한 방향으로 끝까지 이동했다가 다시 처음으로 돌아오는 방법. Scan방식의 문제점 해결.
다양한 스케쥴링 기법을 사용했을 때의 성능 비교
Scan, Circular scan 방식이 제일 합리적이라고 볼 수 있다.


현대 File System의 중요 이슈
스마트폰에 사용되는 Flash drive는 Disk drive와 달리 seek 기능이나 rotation 기능이 없기 때문에 더 복잡하고 다양한 정책 및 기법이 사용되고 있다.















'운영체제' 카테고리의 다른 글

22.2. Disk Scheduling 2  (0) 2018.07.14
22.1. Disk Scheduling 1  (0) 2018.07.13
21. File System Organization  (0) 2018.07.12
20. Files and Directories  (0) 2018.07.12
19. Device Drivers  (0) 2018.07.11
18. I/O Hardware  (0) 2018.07.09

Disk scheduling




Evolution of UNIX File Systems
UNIX는 과거에 많이 쓰였지만 아래와 같이 많은 변종이 생겼기 때문에(기업마다, 기관마다 버전이 너무 달랐다.) 오늘날에는 잘 쓰이지 않는다.



System V file system (s5fs)
UNIX의 표준이 되는 버전. 초창기 버전이라 시행착오가 많았다.

  • boot area
    컴퓨터 부팅 시 실행되는 프로그램인 Boot Loader가 저장되어 있는 공간. 부팅용으로 사용되지 않는다면 해당 공간은 비어있는 상태가 되겠다.

  • superblock
    File System에 대한 모든 메타데이타(전체 블록의 개수, Inode의 개수, Free block의 개수 등등...).

  • inode list
    파일이 생성되면 inode의 일부를 꺼내어 할당하여 사용.

  • data blocks
    나머지 필요한 것들을 전부 저장.

  • System V File System의 성능 상의 문제 1
    파일의 inode와 data block 간의 물리적인 거리가 멀기 때문에 파일에 접근 시 과도한 seek operation이 발생(디스크의 arm이 멀리 움직여야함).

  • System V File System의 성능 상의 문제 2
    Data block의 할당/해제를 반복할수록 Free block이 산재하게 되어 Sequential Block을 읽을 때 과도한 Seek Operation이 발생.

  • System V File System의 안정성의 문제
    Superblock이 한 곳에만 저장되어 있기 때문에 손상될 경우 파일 시스템을 사용할 수 없음. 즉 신뢰성(Reliability)이 떨어짐.

Berkely fast file system (FFS)
버클리 대학에서 개선한 버전. 성능 저하의 문제를 많이 개선. UNIX의 가장 대표적인 버전(UFS-UNIX File System).

  • cylinder group
    가능하면 인접한, 논리적(Logical)으로 서로 연관 있는(Relationoal) 실린더들 끼리 묶는 것. 예를 들면 같은 디렉토리 안에 존재하는 Inode와 컨텐츠들을 동일한 실린더에 넣는다. 새로운 디렉토리를 만들면 새로운 실린더 그룹을 할당한다.

  • FFS superblock
    FFS에선 s5fs와 달리 슈퍼블록이 한 개가 아닌 그룹별로 만든다. 따라서 신뢰성(Reliability)이 보장된다.

  • Blocks and fragments
    Fragment라는 것은 결국 sector를 말한다. 디스크 공간이 fragment 단위로 할당되고 fragment 여러개를 묶어 블록의 크기를 크게 잡는다.

  • Cylinder group이 파일을 묶을 때 파일의 크기가 너무 큰 경우(48KB 이상 : 48KB 까지는 빠른 직접 접근이 가능하기 때문) 파일의 블록을 쪼개서 인접한 실린더 그룹으로 보낸다. 따라서 파일의 블록들이 Random하게 흩어져 seek time이 증가하는 부작용을 방지할 수 있다.

  • Rotational Delay 해결
    실제 디스크 드라이브가 섹터로부터 데이터를 읽는데 걸리는 시간(Rotation Delay)이 2라고 하는 것은 디스크가 회전하면서 '두 섹터를 건너 뛰는 동안의 시간' 이다. 따라서 0번 블록 다음의 1번 블록을 바로 저장하는 것이 아니라 두 칸을 띄어서 1번 블록을 저장 시키는 것이 바람직 하겠다.

  • 더 긴 파일의 이름을 가능하게 하고 이 때부터 Symbolic links(이전 단원 참고)가 가능해졌다. 여러 유저가 상업적인 시스템에서 사용할 수 있도록 Disk quota라는 것도 사용하였다.

  • FFS의 한계


    데이터의 블록들이 흩어져 존재하여 발생하는 sequential reads의 문제, 시대가 흐름에 따라 파일의 크기가 증가하면서 crash recovery가 느리다는 문제를 해결 못함.

  • crash recovery를 해야하는 이유
    예를 들어 파일이 디렉토리로 부터 제거 될 떄 다음과 같이 1->2->3의 과정의 작업이 진행되어야 하는데 순서가 꼬이는 경우 데이터 동기화에 문제가 발생할 수도 있다. 따라서 해당 문제(crash)가 발생했을 때 이를 해결해야 한다.


  • 명령어 fsck가 동작하는 과정(시간이 오래 걸린다-> LFS가 등장하게 된 이유)
    fsck는 file system check를 말함.


    lost + found directory
    File system을 Recovery 하는 중간에 발견된 정체불명의 파일이나 연결되지 않은 디렉토리들을 이곳으로 보낸다.

Sun's network file system (NFS)
소켓 프로그래밍 등이 등장하면서 네트워크 파일 시스템이 등장.


Sun's virtual file system (VFS)
파일 시스템이 너무  많아져서 유저 인터페이스를 단일화 하기위한 SW layer.


Log-structured file system (LFS)
디스크의 볼륨 사이즈가 커지고 회복(Recovery)의 오버헤드가 너무 큰 문제가 되어 나온 파일 시스템. 요즘 많이 사용하는 추세이다. 기존의 파일 시스템에서는 rewrite를 하기 위해서는 복잡하고 전체적인 작업이 필요했지만 LFS에서는 Log를 통해 기존의 내용에 새로운 내용만 덧붙이는(append) 방식을 사용한다. 어느 시점에 Log파일이 많아지면 Log의 내용을 수행하는데 시간이 길어지기 때문에 이를 정규화 하는 과정도 필요하다. 시스템이 갑자기 꺼져서 재부팅 되는 경우 Log에 남아있는 마지막 내용을 기준으로 파일시스템을 재구축(reconstruct)한다.


  • Log에 남겨야할 내용

    Garbage collection이 필요한 이유
    데이터의 내용을 수정(Modify)하는 과정에서 invalidate된 데이터 블록들을 수집(collect)해야 한다.




'운영체제' 카테고리의 다른 글

22.2. Disk Scheduling 2  (0) 2018.07.14
22.1. Disk Scheduling 1  (0) 2018.07.13
21. File System Organization  (0) 2018.07.12
20. Files and Directories  (0) 2018.07.12
19. Device Drivers  (0) 2018.07.11
18. I/O Hardware  (0) 2018.07.09

Big Picture on File System



File System

OS 커널의 서브시스템.

  1. Logical resource name을 Physical address로 변환시켜준다.

  2. 사용자 데이터를 저장장치로부터 읽어오거나 저장 장치에 기록하는 역할.
File을 보는 다양한 관점
각 그림은 User, Kernel , Device Driver, Device 입장에서 보는 파일의 모습 나타냄.



  • User 관점에서의 주요 File Access 패턴 두 가지

    -Sequential Access

    File Pointer(fp)를 한 칸씩 움직이면서 파일의 내용을 읽는 방법.

     -Random Access 
    File Pointer(fp)를 임의로 이동하면서 파일의 내용을 읽는 방법.

  • Kernel 관점에서의 File
    Inumber를 통해서 File을 지정한다. File은 Block 단위의 저장 장소에 저장되어 있으므로 Block의 단위로 파일을 보게 된다.
  • Device Driver 관점에서의 File
    자신이 관리하는 디바이스 전체(Volume) 단위로 파일을 보게 된다.

    -Volume (Logical Drive)

    단일 File System으로 관리되는 저장 장치 상의 영역.
  • Device 관점에서의 FIle
    3차원적인 Disk의 접근을 위해 physical block을 cylinder, head, sector number로 변환하기 위한 관점.
File System in Kernel

User Space의 사용자들은 Kernel Space로 부터 파일서비스를 제공받기 위해 create, read, write, ioctrl의 System call 호출을 사용한다.


  • VFS Layer
    다양한 특성의 파일 시스템들(Individual Filesystems)을 유저에게 통합적인 형식으로 나타내기 위해 존재한다.
  • Buffer Cache(Page Cache)
    최근 접근한 File의 Data Block 내용을 Main Memory에 저장해 두는 공간. 디스크로부터 한번 읽어온 파일의 내용에 다시 접근할 때, 빠르게 읽어올 수 있게 한다.

File Structures


Access Patterns with File(파일에 접근하는 방식들)
  • Sequential access
    순차적 접근. 예를 들어 컴파일러가 소스 파일을 컴파일 할 때.
  • Random access
    예를 들어 demand paging(Swap device에서 특정 페이지를 읽어올 때)이나 Database에 사용할 때.
  • Keyed access
    예를 들어 학번을 통해 학생의 지난 성적이나 집 주소를 알아오는 방식. OS는 Keyed access는 신경쓰지 않는다(특정 Application에 의존적인 특성이 있기 때문). 대신 Sequential access나 Random access 방식을 처리한다.
디스크의 Fragmentation 문제 해결 방안
과거에는 메모리의 Fragmentation처럼 파일에 저장 공간을 할당하고 반환할 때마다 Fragmentation이 발생했다. 메모리에서는 이를 막기 위해 Page 단위로 메모리를 할당하는 기법을 사용하였는는데, 디스크도 비연속적인 Block 단위로 Allocation을 수행하여 이를 방지할 수 있었다.

Types of file structures(과거, 요즘은 아님)
  • Linked files
    블록 단위로 할당하지만 포인터를 통해 링크될 수 있도록 하는 방식.


    -Linked File 구조에서 파일에 접근하기 위한 방법

    해당 File Descriptor에 기록된 File의 첫 번째 블록의 주소를 통해 File에 접근.

    -Linked File 구조에서 File C의 세 번째 블록을 읽는데 필요한 Disk Access 횟수
    1. File C의 Descriptor를 읽어온다. (File C의 첫 번째 블록의 주소를 알아냄)
    2. File C의 첫 번째 블록을 읽어온다. (File C의 두 번째 블록의 주소를 알아냄)
    3. File C의 두 번째 블록을 읽어온다. (File C의 세 번째 블록의 주소를 알아냄)
    4. File C의 세 번째 블록을 읽어온다.

  • Indexed files
    - 마찬가지로 블록 단위로 디스크 공간을 할당하지만 File Descriptor에 존재하는 인덱스로 채워진 배열을 통해 각각 필요한 공간을 포인터로 가리키게 함.

    - linked file 방식에 비해 Sequential, Random access 하기 편하다. 하지만 File Descriptor는 일정한 크기를 갖기 때문에 그 안에 넣을 수 있는 인덱스의 개수가 제한 된다. 즉, 한 파일의 크기가 인덱스의 개수 만큼 제한이 된다. 그럼에도 불구하고 linked file 방식보다 더 많이 사용된다.

Indexed file 방식이 현대의 OS File System에서 사용되는 방식

1~12번 인덱스는 데이터를 가리키고 13번은 특정 블록을 가르키고 해당 블록은 또 다른 인덱스들을 가지고 있다. 이런식으로 Indexed file이 가지고 있는 문제점을 해결하였다. 하지만 Data seek time이 증가하는 패널티가 있다.

Bit Map을 사용한 디스크의 Free Block 관리
각 Bit가 디스크의 Block이 사용 중인지 아닌 지를 나타내는 Array. HW/SW String Search 기법을 사용해 연속적인 사용 가능한 Block을 쉽게 찾을 수 있다. 예를 들어 6개의 연속적인 사용 가능한 디스크 블록을 111111로 표현한다. 사용할 수 없는 공간(이미 사용중인 공간)은 0으로 표시된다.


Disk Space Management

File이 생성되거나 확장될 때, 어떻게 Disk Sector들을 File에 할당해 줄 것인가를 결정. 파일에 접근하는 속도가 빠르게, 디스크 공간을 효율적으로 사용하는 것.


Extent-based Allocation

Block들을 그룹으로 묶고 각 그룹에 Semantics를 부여함으로써 최적화를 달성하는 정책. 기본적인 블록단위로 할당할 때 Seek time이 증가하는 패널티를 줄이기 위해 더 큰 단위로 할당. 






'운영체제' 카테고리의 다른 글

22.2. Disk Scheduling 2  (0) 2018.07.14
22.1. Disk Scheduling 1  (0) 2018.07.13
21. File System Organization  (0) 2018.07.12
20. Files and Directories  (0) 2018.07.12
19. Device Drivers  (0) 2018.07.11
18. I/O Hardware  (0) 2018.07.09

+ Recent posts