윈도우는 C: , D: , F: 과같이 ‘ : ’(콜론)으로 파일시스템을 나누는데, 리눅스의 경우 (pathname determines FS type) pathname으로 파일시스템을 결정한다. 리눅스의 경우 mount를 통해 다른 파일시스템간의 연결?을 하는데 파일시스템 별로 각자의 superblock, inode list, Data block이 존재하는데, 이때 inode의 0번 즉 root 디렉토리를 root 파일시스템 bootblock을 통해 부팅을 시켜줄 파일시스템의 디렉토리 한곳에 mount를 한다. 그러면 다른 파일시스템이 mounting으로 연결된 디렉토리밑으로는 root 파일시스템과 다른 파일시스템을 가지게 된다. 그래서 pathname 으로 파일시스템을 결정한다고 하는것이다.
리눅스는 수많은 파일시스템이 호환가능하다. 그러면 파일시스템 별로 read, write하는 방식도 다를텐데 우리는 read(), write() 시스템콜만 쓴다. 리눅스에서 Standard Interface를 구현해둔것인데 이것이 VFS : virtual file system이다. 각각의 파일시스템에 호환되는 read, write, open 등 구현이 되어있지만, 그 위에 VFS가 있어서 유저는 read만써도 VFS에서 파일시스템에 맞는 read를 호출해준다.
이러한 opration 말고도 Data Structure(Task struct)또한 표준규격으로 만들어두고 각각의 파일시스템에 대응한다.
파일을 open 할때, 보통의 파일이 root디렉토리에 있는것이 아닌 수많은 디렉토리를 들어가야 내가 원하는 파일이 있다. /Users/gyyu/Library/Keyboard/en-dynamic.lm 이경우 사실 디렉토리조차도 파일이기 때문에 disk에서 io를 해야한다. /Users, /Users/gyyu, /Users/gyyu/….
그러면 내가 open한 파일은 하나이지만 그 파일까지 도달하려면 수 많은 inode들을 가지고 있게되는데, 이 inode들을 그냥 폐기를 하냐는 또 다른말이다. 내가 파일을 open하기 위해 수십개의 디렉토리들의 inode들을 꺼내오는 비용이 아깝기도 하고, 사실 유저가 작업을 하면 작업공간(디렉토리)가 한곳에서 크게 벗어나지를 않는다.
그래서 이들을 저장하는 struct를 만들었다.(struct dentry)
하지만 open한 파일의 모든 inode들을 저장하면 쌓이다보면 언젠가 메모리가 부족해지기 때문에 dentry를 저장하는 갯수를 제한한다.
그러면 이러한 dentry가 어디에 위치하냐하면 task_struct에서 fd를 저장하고 fd는 file table의 offset을 가리키고 이 file table의 offset이 dentry cache의 denty struct를 가리키고, dentry struct가 inode를 가리킨다.
순서 : fd → file → dentry → inode
디스크에 저장되어 있는 파일이 아니다.
/proc 에 있는 file은 커널함수이지 파일이 아니다.