[OS] Chap15. File-System Internals

해당 글은
경희대학교 허선영 교수님의 강의 자료 및 내용을 정리한 글입니다
개인적으로 공부하며 작성된 글이라 잘못된 부분이 있을 수 있습니다!
오류가 있다면 알려주세요

 

 

 

 

File-System Mounting

File system은 process가 접근 가능한 상태로 만들기 위해 Mounted 되어야 한다.

이때 C, D, E, F와 같이 Device의 이름과 함께 File system이 붙은 location을 mount point라고 명명

 

OS를 포함하고 있는 것을 Root partition이라고 하며, 이는 boot time에 자동으로 mount 됩니다

 

mount 되는 시점에는 File system의 consistency가 ㄱㅊ한지, 즉 meta data에 잘못된 부분이 없는지 확인하고

오류를 수정하기도 합니다.

오류가 없다면 mount table에 add하여 접근을 허용함!

 

Unix System 기준

 

 

 

 

 

Virtual File Systems on Unix

Virtual File System은 객체지향적으로, Ploymorphism 즉 상위 개체가 하위 개체의 공통 인터페이스가 된다는 특징을 가집니다.

network 전체에서 File을 고유하게 표현하기 위한 vnode, inode 등의 방법을 제공하기도~

 

Linux에는 대표적으로 4가지 object type이 존재한다

• inode object: File Control Block과 연결되며, 각 file을 표현함
• file object: Open file을 표현하며, read/write point
• superblock object: Entire file system을 표현함
• dentry object: Directory 개별의 entry를 표현함

 

그리고 object에 따른 각 operation들은 추상화되어, 개별적으로 구현하게끔 되어 있습니다 .

 

 

 

 

위의 내용까지는 Disk와 연결된 부분에 대한 내용이었습니다.

네트워크로 연결된 File system은 어떨까요?

Remote File Systems

Network을 통해서 Files을 공유할 수 있게 됨

 

▶File Transfer Protocol (FTP)

와 비슷한 방식으로 공유하여 작동하는 방식이 있다.

접근하고자 하는 server IP로 접근하여, data list를 보고 네트워크를 통해 Client에게 전송하는 것쉼

 

▶Distributed File System (DFS)

Cluster server에서 많이 사용하는 방식이 있음

 

▶Word Wide Web (WWW)

Browser를 활용하며, 검색하면 File의 리스트가 나오고 다운받는 식으로 공유할 수 있다

Anonymous access가 가능하다.

 

 

▶Network File System (NFS)

Local file에 접근하는 것처럼 Remote Network file에 접근하기

폴더로 통째로 가져온다~

 

Network drive를 연결하면, server address를 넣어 mount를 시키는 식으로 Disk를 추가할 수 있음

이는 TCP/UDP Protocol로 연결되는데

VFS interface의 공통의 인터페이스를 통해 접근함!

 

System call을 통해서 file system에 접근하게 되는데, 

해당 call이 network를 통해서 요청하고, 결과를 network를 통해 받아온다

그러나 우리는 그냥 Local folder를 사용하는 것'처럼' 할 수 있기 때문에! Transparent Manner 하다

 

$U$ machine이 $S_1$에 있는 Shared 폴더를 mount하고자 하는 상황

 

 

NFS Mount Protocol

- Initial Logical connection: Server와 client 사이

- Mount Operation에는 mount될 directory의 이름, 요청하는 server의 어떤 폴더를 mount할 지에 대한 정보를 포함

- Mount request는 RPC로 변환되어 Kernel이 요청하게 됨

- Server가 해당 요청을 받음. 설정된 권한(Export List)에 따라서 결정 & 처리하게 됨

- Mount request가 Export List를 만족하는 경우, Server는 File handle을 넘김

  File이나 directory에 접근할 수 있게 하는 식별자

 

이때 mount operation은 Server side에 영향을 미치지 않음! 

폴더는 그대로 있고, User가 이를 Mount해서 쓰는 것이기 때문임

 

 

NFS Protocal

Remote file에 접근하기 위한 여러가지 Operation을 제공함

• searching for a file within a directory
• reading a set of directory entries
• manipulating links and directories
• accessing file attributes
• reading and writing files

Kernel에서는 이에 맞는 RPC를 제공한다

 

Stateless: 각 request는 독립적으로, 이전/이후의 request에 영향을 미치지 않는다. 따라서 필요한 정보를 모두 묶어 보내줘야함

Modified data must be committed to the server's disk: 수정되어 Cache된 데이터가 남아있지 않아야함. 따라서 Cache의 장점이 사라진다.

No Concurrency-Control: 여러 Client가 접근하게 될 경우, 이를 제어하는 mechanisms이 존재하지 않음

 

 

NFS Path-Name Translation

NFS를 경로를 가지고 접근할 때 어떻게 번역할까?

예) /user/local/dir1/file.txt ← 해당 NFS 주소에 접근하는 경우

이를 각 user, local, dir1의 컴포넌트 단위로 나누고,

각 컴포넌트를 순서대로 요청하여 vnode를 받고, 이를 가지고 다시 다음 요청하는 것을 반복한다.

 

해당 방식으로 하위 Directory까지 접근하는 것은 꽤 복잡하므로 성능 상의 이슈가 발생.. Overhead..

따라서 Directory name lookup cache를 통해 바로 접근할 수 있게끔 하기도 한다네요

 

NFS Remote Operations

NFS protocal RPCs는 UNIX system calls과 거의 1:1 대응이 됨! (opening, closing files 등 제외)

 

Performance를 위한 Buffering과 Caching

• File-Blocks cache: Cached인 attribute data가 up to date인지 확인한 뒤, 그렇다면 해당 File block를 사용 가능
• File-attribute cache: File의 meta data를 cache. server에서 update가 발생하면 전송, 캐시가 update된다.

 

Client에서는 Delayed-write를 수행함

Client가 해당 file을 수정하면, 해당 내용을 Server에 바로 반영하는 것이 아니라 buffer에 저장해두고 이후에 Update하는 것이다.

따라서 해당 buffer에 저장된 Delayed-write block을 server에서 comfire할 때까지는 free해서는 안 됨!!

 

 

 

헉 한학기의 운체 끝!