11강 - 3. File System Implementations 2

• 기존 파일의 데이터를 읽고/쓰는 방법 : 2가지 인터페이스가 있다. [Unified Buffer Cache를 이용하지 않는 File I/O]
  • 1. File를 open 하고 read/write system call를 한다.
    • 운영체제가 버퍼개시를 확인한다.
  • 2. Memory Mapped I/O
    • 처음에 시스템 콜을 한다.
      • 운영체제에게 Memory Mapped I/O를 쓰겠다는 mmap 시스템 콜을 한다.
      • 자신의 주소공간중 일부를 파일에다가 맵핑한다.
      • 디스크에 있는 파일을 읽어오는 건 1번 방식과 똑같다.(Buffer cache에 읽어온다)
      • Buffer cache에서 읽어온 것을 page cache로 copy를 함.
      • 사용자 프로그램이 mmap된 영역에다가 메모리 읽고/쓰기 하듯이 요청을 하게 되면 read/write이 된다.
        • 커널의 도움없이 자신의 메모리 영역에서 직접 읽고/쓴다.
        • 만약에 map 해놓고, 메모리로 안 읽어왔다면 page fault가 발생한다.
          • 그러면 page fault 핸들러가 호출되어서 cpu가 운영체제로 넘어간다.
          • 해당 요청한 파일을 메모리 page cache에 가져다 놓는다.
    • Memory Mapped I/O를 사용하는 이유?
      • 이미 메모리에 올라온 내용은 운영체제의 도움을 받지 않고, 자신이 직접 자신의 메모리를 접근하듯이 읽고 쓸 수 있기 때문이다.
• Unified Buffer cache
  • 기존의 Buffer cache처럼 운영체제가 공간을 따로 나누어 두지 않고, 필요에 따라서 Page cache에서 공간을 할당해서 쓴다.
    • 이렇게 하면 경로가 단순해진다.
  • read() , write() system call를 하는 경우
    • 무조건 운영체제에게 시스템 콜을 해야 한다.
    • 해당하는 내용이 디스크 파일 시스템에 있든, buffer cache에 있든 상관없이 운영체제에게 cpu 제어권이 넘어간다.
    • 운영체제는 이미 buffer cache에 있는 내용이면 사용자 프로그램 주소 영역에 copy를 해준다.
      • 메모리에 올라와 있지 않은 내용은 disk file system에서 buffer cache로 읽어와서 사용자 프로그램에게 copy를 해서 전달한다.
  • memory mapped I/O
    • 처음에 운영체제한테 자신의 주소 영역 중 일부를 파일에다가 mapping 하는 단계를 거친다.
      • 이 사용자 프로그램의 주소영역에 page cache가 mapping이 된다.
      • page cache 자체가 사용자 프로세스의 논리적인 주소에 mapping이 되어서 해당 프로세스는 Page cache에다가 직접 읽고 쓸 수 있다.

• 프로그램이 File System에서 실행파일로 저장되어 있다가 이 실행파일을 실행시키면 프로세스가 된다.
  • 프로그램이 프로세스가 되면 독자적인 주소공간(Virtual memory)이 생김
• Address translation : 주소변환은 하드웨어가 해준다.
• 주소변환을 해주는 하드웨어에 의해서 virtual memory에서 필요한 부분은 물리적인 메모리에 적재된다.
• 물리적인 메모리가 공간이 부족할 때면, 메모리에서 빼내어 Swap area에 넣는다.
  • 가상 메모리에서 code 부분은 메모리에 올라간 다음에 쫓겨날 때 swap area로 내려가지 않는다.
    • 왜 code 부분은 내려가지 않는가??
    • code 부분은 read only
      • 이미 File system에 있는 실행 파일 형태로 코드가 저장되어 있다.
      • 그래서 swap 영역에 써줄 필요가 없다.
• memory mapped i/o는 사용자 프로그램이 file의 내용을 읽어와라 할 때도 memory mapped i/o를 쓸 수 있다.
  • 실행파일을 실행시킬때 Loader(로더)라는 소프트웨어가 Virtual memory에 올려놓을 때, memory mapped file를 쓰는 대표적인 방법이 바로 실행파일에 해당하는 code 부분이다.
  • code 부분은 별도의 swap area를 가지고 있지않음. 파일시스템의 파일형태로 존재하는 code가 그대로 해당 프로세스 주소영역에 mapping 된 형태이다.

---

• 파일의 내용을 읽어오라는 명령 : read system call
• 데이터 파일을 접근하기 위해서 memory mapped i/o를 써서 접근할 수 있다.
• read, write system call를 쓰지 않고 memory mapped i/o를 쓸때
  • mmap() : 프로그램이 운영체제에게 데이터 파일 일부를 내 주소공간 일부에다가 mapping 해달라고 system call 한다.

• 운영체제가 해당 데이터 파일의 일부(검은색)를 이 프로그램 주소 공간 일부에다가 mapping을 한다.
• 만약 프로세스 B가 실행되면서 검은색 메모리 위치를 접근했을 때, 해당 내용이 안 올라왔을 때 page fault가 발생
  • page fault가 발생하면 cpu가 os에게 넘어가서 page fault가 발생한 page를 물리적인 메모리에 올려놓을 것이다.
  • 그러면 virtual memory 프로세스 B에 검은색 page가 physical memory에 있는 검은색 page로 mapping이 된다.
    • copy 하는 오버헤드가 없어서 빠르다.
  • 프로세스 B는 해당 데이터 파일의 일부분(검은색 page)을 접근할 때는 os의 도움을 받지 않고, 자신의 주소공간의 일부이기 때문에 physical memory에다가 데이터를 읽거나 쓴다.
  • 나중에 Physical memory에 있는 검은색 page가 쫓겨날 때는 해당 page가 memory mapped file이기 때문에 File에다가 수정된 내용을 써주고 쫓아내야 한다.
  • 또 다른 프로세스 A가 동일한 파일의 동일한 data(page)에 대해서 memory mapped i/o를 호출할 수가 있다.
    • 이 경우에는 physical memory에 있는 검은색 data가 share(공유)가 되는 것이다.

---

• 똑같은 검은색 파일에 대해서 read/write system call를 해서 사용할 때
  • 프로세스A가 운영체제에게 검은색 파일의 특정 내용을 달라고 운영체제에게 요청을 한다. - 시스템 콜
  • 원래 운영체제는 자신의 버퍼 캐시에 해당 내용을 읽어와야 한다
    • 그러나 Unified Buffer cache인 경우에는 physical memory에 있는 검은색 사각형이 page cache이고, 프로세스 B의 주소공간과 mapping 되어있지만 동시에 buffer cache를 겸하고 있다.
    • 만약 read system call를 했는데, 프로세스 A가 요청한 데이터 파일의 내용이 이미 page cache(Buffer cache)에 올라와 있다면 copy 해서 사용자 프로세스 A에게 전달을 해준다. - 아래 이미지에 있는  프로세스A에 있는 검은색 점

프로세스A에 있는 검은색 점

Memory mapped I/O의 장단점

• 장점
  • 이미 메모리에 올라온 파일의 내용을 system call를 사용 안 하고 자신이 cpu를 가지고 있으면서 직접 접근하기 때문에 빠르다.
  • 캐시에 올라온 내용을 자신의 주소공간으로 copy 할 필요가 없다( copy 오버헤드가 없다)
• 단점
  • 다른 프로세스가 share 해서 사용할 때, 일관성(consistancy)이 깨질 수 있다.
    • read / write system call를 쓰는 경우에는 copy 해서 전달하기 때문에 일관성 문제가 생기지 않는다.