File and File System
![](https://velog.velcdn.com/images/fo_rdang/post/f2e707ab-fb93-4705-8358-92e56d7c6e0c/image.png)
File
-
하드디스크에 저장하는 단위
메모리는 주소를 통해서 접근하는 장치임. 파일은 이름을 통해서 접근하는 단위임.
-
관련정보를 이름으로 저장하는 것.
-
파일은 비휘발성의 보조 기억 장치, 하드디스크에 저장된다.
-
데이터를 저장하는 목적으로만 파일을 쓰는게 아님. 운영체제 특히 linux에서는 여러가지 장치들도 관리하기 위해서 파일이라는 이름을 사용해서 관리한다. 다양한 저장장치들 하드디스크1번, 하드디스크 2번 이 있으면, 운영체제는 그런 장치들을 서로 다른 파일로 관리하고 있음. 이런식의 파일을 device special file이라고 부름. 이거는 일반적인 file과는 다름.
-
파일에 대해서 정의되는 연산은??
- 파일 create
- 파일 delete
- 파일 read, wirte
- 파일 reposition (lseek라고도 함(엘시크))
: 파일은 여러개의 바이트로 구성되기 때문에, 어느 위치를 읽고 쓰느냐는 pointer가 있음.
한번 읽고 나면 그 다음 부분을 가리키게 됨.
쭉 읽으면 위치 pointer는 다음으로 가고, 그 위치부터 읽히게 된다.
하지만, 다른 부분부터 읽거나 쓰고 싶을 때, 이런 위치를 수정해주는 것 => reposition
- 파일 open, close
:정의로는 read,wirte 하려면 open 먼저 해야 한다라고 쓰여있음. 다 하면 close 해라.
open의 역할은 그 파일을 디스크에서 메모리로 내용을 올려놓는게 아니라, 파일의 메타데이터를 메모리에 올려놓는것이다.
File System
- 운영체제에서 파일을 관리하는 software
- 파일 시스템은 파일 자체의 내용도 관리하지만, 그 파일의 메타데이터도 같이 저장을 한다.
- 파일 시스템에 파일을 저장할 때 디렉토리를 둬서, 루트 디렉토리부터 계층적으로 저장을 한다.
- 파일 시스템은 파일을 어떻게 저장하고, 관리할지, 보호할지 담당하고 있다.
- 디렉토리는 대부분의 file system에서 제공한다. 디렉토리도 하나의 file임. 디렉토리 파일은 그 파일의 메타데이터는 디렉토리 파일의 이름과 접근권한 등일 것이고, 디렉토리 파일의 내용은 그 디렉토리 밑에 존재하는 파일이 어떤건지, 그 파일들의 메타데이터가 된다.
Directory and Logical Disk
![](https://velog.velcdn.com/images/fo_rdang/post/07077655-f060-4192-8f7b-180d218d7b66/image.png)
Directory
- 하나의 파일임.
- 파일의 내용이 '디렉토리 밑의 파일들이 어떤 파일인지의 정보'를 내용으로 한다.
- 파일의 메타데이터는 해당 디렉토리의 접근권한, 시간 등이 된다.
- 연산: 디렉토리 밑의 파일들이 어떤건지 목록을 보는 것, 그 디렉토리 밑 파일을 찾는것, 파일을 지우는 것등...
Partition
파일시스템이 하드디스크에 저장이 될텐데 우리가 이 디스크라는게 논리적인 디스크, 물리적인 디스크가 있다.
운영체제가 보는 디스크는 논리적인 디스크고, = Partition이다.
- 하드디스크를 하나사서 c드라이브, d드라이브 partition을 나누면, 그 각각이 논리적인 디스크가 됨.
- 경우에 따라서는 물리적인 디스크 여러개를 합쳐서 논리적인 디스크 하나를 구성할 수도 있음.
용도
- 파티션에 파일 시스템 설치할 수 있음.
- 논리디스크를 virtual memory swap area 용도로도 사용 가능
open()
![](https://velog.velcdn.com/images/fo_rdang/post/18d8d511-f9e0-4ca4-b05c-255c8b4820e3/image.png)
- open 연산: 파일의 메타데이터를 메모리로 올려놓는것.
논리적인 디스크 안에 파일 시스템이 있으면,
file metadata
: 파일의 저장위치(file content가 어디 저장되어 있는지에 대한 pointer가 저장되어 있다는 뜻.), 파일의 이름, 유형, 파일 사이즈
file content
가 저장되어 있다.
어쨌거나, 이 file을 open
하게 되면 file metadata가 메모리로 올라오게 된다.
![](https://velog.velcdn.com/images/fo_rdang/post/70ff7c0c-5757-494e-ac5c-59cfed2c8bbb/image.png)
open("/a/b/c")
-디렉토리를 따라가서 c라는 파일의 위치를 찾게되는 것.
![](https://velog.velcdn.com/images/fo_rdang/post/2461f2d8-f988-40c4-aefa-15eb48b6a944/image.png)
![](https://velog.velcdn.com/images/fo_rdang/post/5da8f789-10dc-4ee8-8de0-4dd84dc6ae24/image.png)
- 사용자 프로그램의 시스템 콜 (시스템 콜은 read, write, open...등이 있음.)
![](https://velog.velcdn.com/images/fo_rdang/post/0f1b5bd7-7e52-454d-8b8d-8fd8057d9f38/image.png)
=> open 하게 되면,
=> 시스템콜이니까 cpu 제어권이 운영체제한테 넘어간다.
=> 운영체제 안에는 각 process 별로 관리하기 위한 자료구조가 있고 (PCB
)
=> open 한 파일들이 어떤건지 관리하는 global한 table이 유지되고 있다. (Open file table
)
![](https://velog.velcdn.com/images/fo_rdang/post/60cfdac2-f0e0-4d21-9622-21793463dd73/image.png)
root directory의 metadata는 미리 알려져있기 때문에
운영체제가 root directory의 metadata를 알고 있음.
=> 메모리에 먼저 올린다.
즉, root를 먼저 open 하는 것.
![](https://velog.velcdn.com/images/fo_rdang/post/049ac079-3069-4268-8006-63303e94f6a6/image.png)
- metadata에는 해당 파일의 content 위치가 들어잇음.
- root directory는 그 안에
file들의 metadata
를 가지고 있음.
![](https://velog.velcdn.com/images/fo_rdang/post/39c24203-5e4a-4012-8895-1628829a798b/image.png)
- root 디렉토리 content에 a파일의 metadata가 존재함.
![](https://velog.velcdn.com/images/fo_rdang/post/80274fe9-aa3e-490c-a892-6680916e5d44/image.png)
- 이 a의 metadata를 메모리에 올려놓는다.
![](https://velog.velcdn.com/images/fo_rdang/post/7056d30d-934d-4ce8-b436-db1403320575/image.png)
- 위 과정을 계속 반복하다가,
- b의 metadata를 메모리에 올려놓게 된다.
- open 이라는것은 metadata를 메모리에 올려놓는 것이기 때문에 open이 끝난것.
![](https://velog.velcdn.com/images/fo_rdang/post/f6ebd432-7756-4b6d-a6c4-4c26a06164ae/image.png)
- open이 끝나면, 시스템 콜을 한 것인데 어떤 결과값을 return 하게 된다.
=> 각 process마다, 그 process가 open한 파일들에 대한 metadata pointer들을 가지고 있는 일종의 배열 같은게 정의되어 있다.
지금 open한 b의 metadata 파일의 위치가 여기다.
![](https://velog.velcdn.com/images/fo_rdang/post/ef07ecba-b90c-471b-9648-0c4699d2ae3b/image.png)
그 위치를 가리키는 포인터가 이 배열 어딘가에 만들어지고,
![](https://velog.velcdn.com/images/fo_rdang/post/4f0563f1-902d-47fd-9d97-c7bd3bcdace1/image.png)
그 배열이 해당 배열에서 몇번째 idx인가? => 그것이 b의 fd(file descripter)가 되어서
그 값을 사용자 process한테 return 을 한다.
![](https://velog.velcdn.com/images/fo_rdang/post/6eba9ea5-07c8-45ae-87c5-0ea319f67706/image.png)
- 사용자가 read 요청을 한다면 b 파일의 fd를 이용해 metadata에 접근하게 되고, metadata는 해당 content의 위치를 알게된다.
![](https://velog.velcdn.com/images/fo_rdang/post/50cb6196-d331-42f0-a90f-3f744fe55d5d/image.png)
그 내용을 메모리로 읽어서 프로그램한테 전달하면된다.
이 과정에서
내용을 사용자 프로그램한테 직접 주는게 아니라
운영체제가 자신의 메모리 공간 일부에다가 먼저 읽어놓는다
그 다음에 사용자 프로그램한테 copy 해서 전달한다
만약에 이 프로그램 또는 다른 프로그램이 ,
동일한 파일의 동일한 위치를 요청하면,
read 시스템 콜을 하면,
디스크까지 가는게 아니라,
운영체제가 이미 읽어놓은게 있기 때문에
이걸 바로 전달할 수 있다.
=> buffer caching
우리가 virtual memory system의 paging 기법을 배웠었다.
- 이미 메모리에 올라와잇는 page에 대해서는 운영체제가 중간에 끼어들지 못하고 주소변환을 하드웨어가 해서 바로 접근을 했다.
- pafe fault가 나면 그제서야 운영체제가 cpu를 받아서 운영체제가 swap 영역에서 page를 읽어왔다.
그런데, file에 대한 read/wirte 시스템에서는
- 역시 운영체제가 buffer cache 라는 것을 가지고 있는데,
- 이 파일 시스템의 buffer cache는 요청한 내용이 이 buffer cache안에 있든 없든간에 운영체제한테 cpu가 넘어가게 된다.
- 데이터를 요청했을 때 메모리가 안올라와있을 때 b의 content에서 읽어와서 메모리에 올려놨었다.
- 나중에 이미 메모리에 올려둔 데이터를 누가 요청을 한다면 이것 역시 시스템 콜이기 때문에 cpu제어권이 운영체제한테 넘어간다.
- 운영체제가 판단하는것. 아?이게 나한테 이미 있네? 그러면 그냥 전달 . 요청한게 없으면 디스크에서 읽어와서 buffer cache한테 올려두고, copy 해서 사용자 프로그램한테 전달한다.
=> 이 buffer cache라는 환경에서는 시스템 콜을 통해서 cpu가 운영체제한테 넘어오기 때문에 LRU, LFU 알고리즘을 자연스럽게 사용할 수 있다. 모든 정보를 운영체제가 알고 있기 때문이다. 전시간에 paging system에서 LRU를 못쓰고, clock 알고리즘을 썼던 것과는 대조가 된다.
커널이 유지하는 테이블들에 대해서 여러가지 이름이 주어진다.
![](https://velog.velcdn.com/images/fo_rdang/post/64295167-30c3-43fa-9cc4-7ef1f613b81e/image.png)
이런 file descripter들은 프로세스마다 가지고 있다고 해서 => per-process file descriptor table
![](https://velog.velcdn.com/images/fo_rdang/post/1c14ff1b-9754-40aa-baeb-d333f2633c0b/image.png)
파일을 open 햇으면 프로세스마다 가지고 있는 것이 아니라, open된 파일의 목록들을 system-wide하게 한꺼번에 관리하고 있다. => system-wide open file table
이 테이블 들이, 시스템 안에 open과 관련된 테이블이 글로벌하게 하나 있는게 있고,
프로세스마다 별개로 있는 table이 있다.
지금은, 두개만 보여줬는데
구현에 따라서 이런 table이 3종류가 있을 수도 있고 그렇다
왜냐하면,
메타데이터가 디스크에 있을 때는 아래 정보만이 meta data가 되는데
![](https://velog.velcdn.com/images/fo_rdang/post/f3c10e60-ac8c-4fb8-8a89-5f307eccd8f3/image.png)
이거를 메모리에 올려놓게 되면, 여기에 추가적으로 메타데이터가 필요하게 된다.
현재 이 process가 이 파일의 어느 위치를 접근하고 있다는 offset을 운영체제가 같이 가지고 있어야 한다.
근데 그거는 프로그램들 마다 별도겠죠.
- A라는 프로그램이 요 파일을 OPEN했지만 또 다른 프로그램이 이 파일을 OPEN 할수도 있다. 그러면 b라는 파일의 메타데이터는 한 copy만 올라가 있음.
system-wide하게 하나만 존재하는데, offset은 서로다르다.
- a프로그램이 이 파일을 읽고 있는 위치
- b프로그램이 이 파일을 읽고 있는 위치
는 다르기 때문이다.
=> open file을 두개로 나눠서
- process와 무관하게 하나만 갖고 있는 요것과
- process가 파일을 읽고 있는 위치 offset
이거를 따로 관리하는 table을 두는 것이 일반적이다.
File Protection
파일의 접근 권한에 대해 알아보자.
메모리 접근 권한은?
- read/write만 이야기
- 파일별로 메모리를 따로 가지고 있기 때문임. (결국에는 자기 혼자밖에 못봄)
![](https://velog.velcdn.com/images/fo_rdang/post/84233040-1ac9-47ce-807f-55b01a60385c/image.png)
그러나, 파일은
- 여러 사용자, 여러 프로그램이 같이 사용
- 파일에 대한 접근권한은, 접근권한이 누구한테 있냐? 접근 연산 어떤 것이 가능한가?를 같이 가지고 있어야함.
- 파일 접근권한 제어방법은 3가지 정도가 있음.
Access control Matrix
![](https://velog.velcdn.com/images/fo_rdang/post/6ffa022d-2eb3-42f7-98ea-7bd0a252624d/image.png)
- 행렬임
- 각각의 사용자가 각각의 파일에 대해서 어떤 권한이 있는지 표시
- 낭비가 심함
- ex) user가 어떤 파일에 대해서 자기만 접근권한이 있는데, 다른 수천명의 유저가 해당 파일에 대해 접근 권한이 다 비어있을 것임.
=> linked list
형태로 만드는 것을 생각하게 됨. (2가지 방법)
1) Access control list
: 파일을 주체로 해서 접근 권한이 있는 사용자를 linked list 형태로 묶어두는 방법.
2) Capability
: 사용자별로 자신이 접근 권한을 가진 파일 및 해당 권한 표시
=> 부가적인 overhead가 크다.
Grouping
![](https://velog.velcdn.com/images/fo_rdang/post/49b5e021-c0b4-4e72-a319-66ecb30ada2a/image.png)
- 일반적인 운영체제에서 이 방법을 통해 파일 접근 권한 관리
- 모든 사용자에 대해서 접근 권한을 다루는 것이 아님. => 각각의 파일에 대해서 사용자 그룹을 3가지로 나눈다.
- 그 파일의 소유주에 대해서 접근권한이 read/write/execution 뭐가 있는지 표시하고, 이 사용자와 동일 그룹에 속한 사용자에 대해서 읽기/쓰기/실행권한이 있는지 없는지 표시한다. 파일 하나에 대해서 접근 권한을 나타내기 위해 총 9개의 bit만 있으면 된다.
File System의 Mounting
![](https://velog.velcdn.com/images/fo_rdang/post/e50aa251-3e10-4196-8ebf-c2dd8ebaddd4/image.png)
- 하나의 물리적인 디스크를 partitioning을 통해서 여러개의 논리적인 디스크로 나눌 수가 있다.
- 각가의 논리적인 디스크에는 파일 시스템을 설치해서 사용할 수 있다.
- 루트 파일 시스템이라고 해서, 특정 os에 대해서 파일 시스템 하나가 접근이 가능한데, 만약에 다른 partition에 설치되어 있는 파일 시스템에 접근하고 싶을 때는?? =>
Mounting
연산
Mounting
![](https://velog.velcdn.com/images/fo_rdang/post/86efd5c3-5c1a-460c-bc6c-cb5464577346/image.png)
- 루트 파일 시스템의 특정 디렉토리 이름에다가 또다른 파티션에 있는 파일 시스템을 갖다가 mount를 해주면 그 mount된 디렉토리에 접근하게 되면, 또 다른 파일 시스템의 루트 디렉토리에 접근하는 꼴이 된다.
=> 서로 다른 파일 시스템에 서로 다른 파티션에 존재하는 파일 시스템을 접근할 수 있게 된다는 뜻.
Access Methods
![업로드중..]()
파일을 접근하는 방법에 관한 것