1. 파일의 할당
- 새로 생성할 파일을 디스크에 할당하는 방법
- 블록 : 하드 디스크와 데이터를 주고받을 때 사용되는 논리적인 단위
(일반적으로 4KB)
<파일을 생성할 때 저장되어야 하는 데이터>
(1) 메타데이터 : 파일 길이, 마지막으로 수정한 시간, 접근 권한, ...
--> inode라는 자료구조로 저장
--> inode를 저장하는 블록을 inode블록이라함
(2) 데이터 : 파일이 실제로 가지고 있는 내용
--> 데이터 블록
ext구조
- ext는 디스크의 크기가 같은 여러개의 블록 그룹으로 나누고 블록 그룹은 아래와 같이 나뉨
Inode Table
여러개의 inode 블록으로 구성되고 하나의 inode블록에는 여러개의 inode로 나뉨
- inode의 구조
-하나의 inode는 file의 metadata와 해당 파일이 저장되어 있는 데이터 블록의 주소를 저장하고 있음
1)file metadata
2)direct blocks
3)single indirect blocks
파일의 데이터를 저장하고 있는 블록들을 가리키고 있게 따로 데이터 블록에 할당해두고 이를 가리키게 구현되어있음
4)double indirect blocks
single indirect blocks와 마찬가지
5)triple indirect blocks
single indirect blocks와 마찬가지
--> 왼쪽 네모 안에 있는 data는 data block에 위치함
--> direct block들은 파일의 데이터를 저장하고 있는 data block을 직접 가리킴
하나의 inode에는 12개의 direct blocks, 각각 1개의 single,double,triple indirect blocks로 이루어짐
-->
이유 : 큰용량의 파일도 사용가능하게 하기 위해서 이런 구조로 되어있음
블록 사이즈는 4KB, 파일 포인터는 32비트라고 가정
ex) 15개의 direct block이 있을 경우
-> 15 * 4KB = 60KB
원래방식)
(12 + 1K + 1M + 1G) * 4KB ≈ 4TB
--> 32비트 파일 포인터가 가리킬 수 있는 4GB보다 훨씬 크다.<Inode와 data block을 저장할 때 빈공간은 어떻게 알까?>
Data blocks Bitmap과 Inode Bitmap이 그 내용을 관리함
Inode Bitmap ::
--> Inode Table의 0번째 inode의 bit는 1이므로 현재 사용중
--> Inode Table의 1번째 inode의 bit는 0이므로 현재 사용X
2. 파일의 접근
디렉터리 == 파일로 관리됨
--> 디렉터리도 inode가 존재하고 inode가 가리키는 데이터 블록이 존재
디렉토리가 table처럼 저장됨
디렉토리는 파일이므로 디렉토리가 다른 디렉토리를 가리킬 수도 있음
이 디렉토리 구조를 참고하여 파일의 inode를 찾게됨
linux는 파일과 디렉토리를 연결할 수 있는 또 다른 방법 제공
--> 링크(Link) :: 서로 다른 디렉토리에서 같은 파일을 접근하는 방법
하드링크 : 원본 파일의 inode를 그대로 참고하게 됨 원본과 하드링크파일은 따로 구분이 불가능
심볼릭 링크 : 새로운 inode 할당 데이터 블록에는 원본 파일 경로를 저장
원본 파일이 삭제되어도 삭제되었는지 모름
3. 파일의 보호
Access Control List(ACL)
누가 어떤 연산을 할 수 있는지 리스트 형식으로 관리
접근 방법을 정교하게 사용할 수 있는 장점이 있지만 list가 가변적이기 때문에 고정적인 크기를 받는 inode안에 저장하기는 힘들다는 단점
접근 권한 비트
파일의 소유자, 공유하는 그룹, 기타 사용자들의 접근 권한을 고정적인 9비트로 나타냄
각각 소유자, 그룹, 기타의 접근권한을 나타냄
디렉터리의 read,write,execute
read : 디렉터리 내의 파일의 리스트 접근 권한
write : 디렉터리 내 파일의 생성, 삭제, 이름 변경 권한
execute : 디렉터리 접속(cd) 또는 디렉터리 내의 파일 접근 권한
4. 파일의 일관성
파일을 생성하다가 디스크 전원이 꺼지게 된다해도 이 파일 시스템은 문제 없이 사용할 수 있도록 보장해줌
ex) inode를 새로 할당했지만 data block을 기록하지 못하고 전원이 꺼지게 되는 경우
--> inode가 가리키고 있는 data block에 쓰레기값을 저장해 보안에 문제가 됨
--> 아무 파일도 이 데이터 블록을 사용하고 있지 않지만 계속 이 데이터 블록을 할당하고 있어서 문제가됨
이를 해결하기 위해
fsck(File System Checker)
파일에 불일치되는 정보가 있는지 확인해주는 검사기
문제점
1. 모든 디렉터리 구조를 스캔해야되기 때문에 상당히 느리다.
2. 파일의 일관성이 깨져있는 것을 탐지해도 복구가 불가능한 경우가 많다
--> 이러한 문제점 해결한 것이
저널링(Journaling)
inode나 비트맵의 수정이 있으면 그 내용을 로그로 남긴다.
로그 : 파일 시스템 내 별도의 영역 또는 별도의 저장장치에 기록
<동작 방식>
파일을 연산할 때 디스크에 변경사항을 바로 쓰지않고 로그들을 Journal영역에 미리 기록
트랜잭션 : 하나의 파일연산에 기록되는 로그의 집합
모두 기록되면 commit되었다고함
실제 inode와 bitmap에 이를 반영하게 됨
--> 장점
로그를 작성하는 중에 크래시가 발생하는 경우
- 실제 파일에 반영된 것이 아니기 때문에 일관성이 깨지지 않음
실제 파일에 반영하는 중에 크래시가 발생하는 경우
- 저널에 기록된 로그를 기반으로 다시 반영하면 된다
