운영체제 책 보고 정리!
파일 시스템 마운팅
파일 시스템은 프로세스들에 의해 사용되기 전에 마운트 되어야한다. 마운트 되지 않은 파일 시스템에는 접근할 수 없다.
저번 시간에 마운팅에 대해 배웠을 때 고정되어 있는 것인 줄 알았는데, 파일 시스템에 접근할 때마다 동적으로 변경할 수 있는 듯 하다!
즉, 하나의 디렉터리 위치에 여러 개의 파티션을 번갈아가며 마운트 할 수 있다. (마운트 포인트 : 마운트되는 파일 시스템이 부착될 비어있는 디렉터리)
운영체제마다 규칙이 아래처럼 다르다.
- 이미 파일이 할당된 디렉토리에는 새로 마운트 불가능
- 이미 할당된 디렉토리에 새로 마운트를 하면 새 파티션만 사용가능하고, 기존 파티션은 사용 불가능. 새 파티션이 언마운트되면 다시 기존 파티션 사용 가능.
미가공 파티션과 가공 파티션
파티션은 파일 시스템을 포함하는가를 기준으로 두 가지로 분류한다.
미가공 파티션: Raw 파티션이라고도 하며, 파일 시스템이 포함되어있지 않다.가공 파티션: Cooked 파티션이라고도 하며, 파일 시스템을 포함한다.
스왑 공간은 자신의 고유 포맷을 사용하고, 파일 시스템을 사용하지 않아 Raw 파티션에 저장된다. RAID 시스템과 관련된 정보를 저장하는 공간 또한 Raw 파티션에 저장된다.
파티션의 부트 스트랩 로더
파티션에 부팅 가능한 파일 시스템이 포함되어 있다면, 해당 파티션은 부트스트랩 로더를 가지고 있어야한다. 부트 스트랩 로더는 파일 시스템이 적재되기 이전에 실행되며, 파일 시스템의 구조에 대해 어느정도 알고있어야 한다.
부팅 과정은 다음과 같다!!
- 부트 스트랩 로더는 파티션 테이블을 읽어 부팅이 가능한 파티션을 찾는다.
- 해당 파티션의 파일 시스템을 인식한다. 이를 위해 부트 로더는 해당 파일 시스템의 기본 구조와 레이아웃을 알고있어야 한다.
- 부트 스트랩 로더는 파일 시스템 내에서 커널 이미지 파일을 찾는다.
- 커널 이미지를 메모리로 적재한다.
부트 스트랩 로더가 파일 시스템을 이해하지 못하면, 해당 파일 시스템 내에서 커널 이미지를 찾을 수 없으므로 부팅이 불가능해진다. (일부 운영체제에서 일부 파일 시스템만 루트 파일 시스템으로 사용되는 이유)
물론 부트 스트랩 로더가 파일 시스템의 모든 기능을 알 필요는 없다! 커널 이미지를 찾고 적재할 수 있을 정도의 기본적인 기능만 지원하면 된다!!!
가상 파일 시스템
운영체제는 여러 가지의 파일 시스템을 동시에 제공한다. 운영체제는 어떻게 여러 가지 파일 시스템에 접근할 수 있도록 지원하는 걸까?
가장 직관적인 방법은 각 파일 시스템별로 디렉터리를 구분하고, 파일 루틴을 작성하는 것이다. 그러나 UNIX를 포함해 대부분의 운영체제는 객체 지향을 사용하여 각 파일 시스템의 루틴을 추상화하고 인터페이스로 제공하고 있다.
그 인터페이스를 가상 파일 시스템(VFS, Virtual File System) 이라고 한다.
각 파일 시스템의 구현 세부 사항과 기본 시스템 콜을 격리하기 위해 파일 시스템은 아래와 같이 세 가지 계층으로 구성된다.
- 첫 번째 계층은
open(), read(), write(), close()를 호출하고, 파일 디스크립터를 사용하는 파일 시스템 인터페이스다. - 두 번째 계층은 가상 파일 시스템 계층이다.
- 세 번재 계층은 각 파일 시스템의 프로토콜을 구현하는 최하부 계층이다.
가상 파일 시스템 계층에 대해 더 자세히 알아보자!
- NFS는 VFS 인터페이스를 명확하게 정의하여 파일 시스템의 일반적인 연산을 내부 구현 로직과 분리한다.
- 가상 파일 시스템은 네트워크에 속한 모든 파일을 동일한 형태의 파일 객체로 표현할 수 있게 해준다.
vnode라는 파일 표현 구조를 사용하며,vnode는 네트워크상에 있는 모든 파일들을 식별할 수 있도록 해준다. (inode는 한 파일 시스템내에서만 유일하다.)
가상 파일 시스템에는 open(), close(), read(), write(), mmap() 등 다양한 요구사항을 정의하고 있고, 모든 파일 시스템은 각 요구사항들과 대응하는 함수 테이블을 가진다. 함수 테이블 리스트는 각 요구사항에 대한 실제 함수들이 저장된 주소를 관리한다.
원격 파일 시스템
15.6
파일 공유 방법 세 가지
- ftp같은 프로그램을 통해서 기계간에 파일을 직접 전송
- 로컬 기계에서 원격 디렉터리에 접근할 수 있는 분산 파일 시스템(DFS)
- WWW 사용!
클라이언트 서버 모델
파일을 가지고 있는 서버에 클라이언트가 접근 요청을 보내는 모델이다.
- 서버는 클라이언트가 접근 가능한 자원을 공지한다. (보통 파티션이나 디렉터리 레벨에서 명시)
- 서버와 클라이언트가 다대다 관계로 연결
서버는 클라이언트의 신원을 확인해야한다. 네트워크 이름이나 IP주소같은 식별자로 구분할 수도 있지만 해킹의 위험이 있다. 암호화된 키를 통하여 보안인증을 할 수도 있지만 이 역시도 여러 문제가 있기에 보완해야함!
UNIX의 네트워크 파일 시스템(NFS)의 경우 기본적으로 클라이언트 네트워킹 정보를 통해 인증한다.
분산 정보 시스템
클라이언트-서버 서비스를 쉽게 관리하기 위해 분산 정보 시스템(또는 분산 네이밍 서비스)라는 개념이 등장!
위의 클라이언트 서버 모델은 서버가 직접 각 클라이언트가 어떤 파일에 접근이 가능한 지를 알고 있다면, 분산 정보 시스템은 DNS처럼 원격 컴퓨팅을 위해 필요한 정보를 중앙 집중적으로 관리하는 방식을 의미하는 것 같다.
대부분 LDAP(경량 디렉터리 접근 프로토콜, Lightweight Directory Access Protocol)를 사용해서 구현한다고 한다...
LDAP는 네트워크상에서 조직이나 개인, 파일, 디바이스 등을 찾아볼 수 있게 해주는 소프트웨어 프로토콜이라고 한다... TCP/IP위에서 운용되고, LDAP서버는 트리 구조로 이루어져있다는데 자세한 건 https://www.samsungsds.com/kr/insights/ldap.html
어쨌든 LDAP같은 걸 사용해서 중앙 집중적으로 원격 공유에 필요한 데이터를 관리한다...
NFS(네트워크 파일 시스템)
NFS는 원격 파일에 접근하기 위한 소프트웨어 시스템의 구현과 명세를 가진다.
NFS는 파일 시스템들 사이에서 일정 수준의 공유를 투명하게 허용한다???
NFS는 원격에 존재하는 디렉토리를 로컬로 마운트해서 접근할 수 있게 지원한다. (연속 마운트 또한 가능 - 이미 마운트한 것에 또 새로운 파일을 마운트)
NFS는 RPC와 XDR 프로토콜로 구동.
NFS는 마운트에 의해 제공되는 서비스와 실제 원격 파일에 접근하는 서비스를 구분한다. 그리고 각 서비스를 위해 두 가지의 다른 프로토콜이 명세되어 있다. 각각 마운트 프로토콜과 NFS 프로토콜이라고 부른다. 프로토콜들은 RPC 집합으로 명세되어 있다.
마운트 프로토콜
마운트 될 원격 디렉터리의 이름과 이를 저장할 서버 기계의 이름을 가지고 마운트를 수행한다.
마운트 요청은 적절한 RPC로 매핑된다.
서버는 마운트할 수 있는 기계들과 마운트 가능한 파일들을 수출 리스트 라는 것에 저장해두고 있다.
서버는 클라이언트에게 파일을 마운트할 때, 마운트된 파일에 접근할 수 있도록 파일 핸들이라는 키를 제공한다.
파일 핸들은 서버가 저장하고 있는 개별 파일을 구분하기 위한 정보 모음으로, UNIX에서는 파일 시스템 식별자와 해당 파일 시스템내에서 마운트된 파일을 가리키는 inode 번호로 구성되어 있다.
NFS 프로토콜
NFS 프로토콜은 마운트 되고 난 이후에 파일에 접근하기 위한 프로토콜로 아래의 기능들을 제공한다.
- 디렉터리 내에서 파일 검색
- 디렉터리 읽기
- 파일 속성에 접근
- 파일 읽기 및 쓰기
NFS 서비스의 주요 특성은 무상태성이다. (UNIX의 오픈 파일 테이블 같은 것이 존재하지 않음.)
따라서 각 요청들은 파일 식별자와 파일 내부의 offset같은 정보를 제공해야한다. (서버의 고장으로 인해 클라이언트들의 접속 정보가 누락되는 것을 막기 위함. 클라이언트 너네가 알아서 어디부터 읽을지 요청해라)
NFS 프로토콜의 RPC는 동기적으로 작동하므로, 빠른 쓰기 속도를 위해 NFC에 쓰이는 블록들은 비휘발성인 캐시를 갖는 저장장치에 저장한다고 한다?
NFS 프로토콜에서의 동시성 이슈
NFS 쓰기 프로시저 호출은 원자성이 보장된다고 한다. 즉, 같은 파일에 대한 다른 쓰기 호출과 혼합되지 않는다! 그럼에도 불구하고 NFS 쓰기작업에서는 동시성 이슈가 발생할 수 있다 ...
일단 NFS 프로토콜 자체는 병행성 제어를 위한 기법을 제공하지 않는다.
여러 클라이언트가 동시에 같은 파일에 쓰기 연산을 수행할 때, NFS 프로토콜 수준에서는 이를 조정하거나 동기화하는 메커니즘이 없다.
이 때, 클라이언트의 쓰기 시스템 콜은 여러 개의 RPC 쓰기 호출로 분리될 수 있는데 이 때문에 동시성 이슈가 발생한다.
(NFS의 쓰기 또는 읽기 호출이 최대 8KB의 데이터만 처리할 수 있고, UDP 패킷의 크기가 1500 바이트로 제한되어 있기 때문에 큰 데이터를 쓰기 위해서는 여러 개의 RPC 쓰기 호출로 나누어 전송해야 하기 때문에 여러 개의 RPC 호출로 나누어짐.)
때문에 같은 원격 파일에 대해 여러 사용자가 동시에 쓰기 연산을 수행할 때, 데이터가 서로 뒤섞일 수도 있다.
클라이언트 A와 B가 쓰기 연산을 수행할 때,
A-1 적용 -> B-1적용 -> A-2적용 -> B-2 적용 ... 이런식으로 되어서 동시성 이슈가 발생할 수 있다는 듯 ????????............... 몰라!
-> Lock의 필요성
데이터 혼합 문제를 해결하기 위해서는 Lock 관리가 필요하다.
그러나 Lock은 상태 정보를 유지해야 하므로(Stateful), NFS의 무상태(Stateless) 특성과는 맞지 않는다.
따라서 NFS 외부의 별도 서비스를 통해 Lock을 제공해야 한다.
NLM(Network Lock Manager)이라는 걸 사용한다는데........ 몰라!
