위 영상을 참고하여 정리한 내용입니다.
파일이 뭐야?
•
컴퓨터에서 의미가 있는 정보를 담은 논리적인 단위
•
크게 실행 파일과 데이터 파일로 나눌 수 있음
◦
실행 파일: 운영체제가 메모리로 가져와 CPU를 이용하여 작업하는 파일 (Ex. Windows - exe, Unix - 없음)
◦
데이터 파일: 실행 파일이 작업하는 데 필요한 데이터를 따로 모아놓은 파일 (Ex. mp3, png, …)
파일 시스템이 왜 필요해?
•
파일을 하나 사용하는데, 하드 디스크의 빈 공간 / 저장된 위치 / 삭제 여부 등 사용자들이 알고 있어야 되는 정보가 너무 많다는 불편함이 있다 ⇒ 파일 시스템 등장!!!
•
파일 시스템: 파일들을 효율적으로 관리하고, 쉽게 사용할 수 있도록 하는 시스템
◦
Windows: NTFS(New Technology File System)
◦
macOS: APFS(Apple File System)
◦
Linux: EXT(Extended File System)
Linux 파일 시스템(EXT)은 어떤 기능이 있어?
크게 4가지 기능(할당, 접근, 보호, 일관성)이 있다.
파일의 할당
새로 생성할 파일을 디스크에 할당하는 방법
•
블록: 하드 디스크와 데이터를 주고받을 때 사용되는 논리적인 단위(보통 4KB)
•
디스크에 어떤 내용을 저장?
◦
메타데이터: 파일 길이, 마지막으로 수정한 시간, 접근 권한 등
▪
inode(index node): 파일의 메타데이터를 저장하는 자료구조
•
저장하는 정보: UID(파일의 소유자 ID), GID(파일의 그룹 ID), 파일의 접근 권한(read/write/execute) 등
▪
inode 블록: 이 inode를 저장하고 있는 블록
◦
데이터: 파일이 실제로 갖고 있는 내용
▪
데이터 블록: 데이터를 저장하는 블록
•
실제 디스크에서 메타데이터/데이터는 어떻게 저장이 될까?
◦
EXT는 디스크를 크기가 같은 여러 개의 블록 그룹(Block group)으로 나눔
◦
한 개의 블록 그룹에는 다음과 같이 나뉘게 됨:
▪
inode Table: inode들이 저장되는 공간
▪
Data blocks: 실제 파일의 데이터가 저장되는 공간
•
inode와 Data block을 저장할 때, 빈 공간이 어디에 있는지 어떻게 알까?
◦
Data block Bitmap: 데이터 블록들의 사용 여부를 비트 단위로 관리하는 구조
▪
파일 내용을 저장할 때: Data block Bitmap에서 0인 비트를 찾아서 새로운 블록을 할당
▪
파일을 지우면: 해당 블록을 다시 0으로 만들어 재사용 가능하도록 함
◦
inode Bitmap: 모든 inode들의 사용 여부를 비트 단위로 관리하는 구조
▪
새 파일을 만들 때: inode bitmap에서 0인 부분을 찾아 해당 inode를 할당
▪
파일을 지울 때: 해당 indoe에 대응하는 비트를 0으로 변경해서 “비어 있음”으로 표시
파일의 접근
사용자가 원하는 파일을 디스크에서 접근하는 방법
•
디렉터리 == 파일
◦
디렉토리는 Windows에서의 폴더와 비슷한 개념임
◦
디렉터리도 inode가 존재하고 inode가 가리키는 데이터 블록이 있음
•
링크(Link): 서로 다른 디렉터리에서 같은 파일을 접근하는 방법
◦
Hard Link: 동일한 파일 시스템 내에서만 작동하며 원본 파일과 동일한 inode를 가지며 실제 파일 내용을 공유함
◦
Symbolic Link: 다른 파일이나 디렉터리를 가리켜 원본 파일을 따로 복사하지 않고 참조하는 방식. 윈도우의 바로가기와 비슷한 개념
파일의 보호
파일의 접근 권한을 관리하는 방법
•
Access Control List (ACL)
◦
누가 어떤 연산을 할 수 있는지 리스트 형식으로 관리
•
접근 권한 비트
◦
파일의 소유자, 공유하는 그룹, 기타 사용자들의 접근 권한을 고정적인 9비트로 나타냄
◦
디렉터리의 read, write, execute
▪
read: 디렉터리 내의 파일 리스트 접근 권한
▪
write: 디렉터리 내의 파일 생성, 삭제, 이름 변경 권한
▪
execute: 디렉터리 접속(cd) 또는 디렉터리 내의 파일 접근 권한
파일의 일관성
파일의 내용이 손상되지 않도록 해주는 방법
•
파일을 생성하다가 디스크 전원이 꺼지게 된다면…?
1.
inode를 새로 할당했지만, Data block을 기록하지 못하고 전원이 꺼진 경우
•
inode가 가리키고 있는 데이터 블록에 쓰레기값이 저장되어 있음
2.
Data block Bitmap을 기록했지만, inode에 해당 데이터 블록의 포인터를 저장하지 못한 경우
•
아무 파일도 이 데이터 블록을 사용하고 있지 않지만, 계속 이 데이터 블록을 할당하고 있는 상태가 됨
•
이를 해결하기 위해 Linux는 2가지 기능 제공
1.
fsck(File System Checker)
•
파일에 불일치되는 정보가 있는지 확인해주는 검사기
•
문제를 탐지했을 때, 복구가 가능하다면 복구도 해주는 기능 포함
•
문제점:
1.
모든 디렉터리 구조를 스캔해야 되기에 상당히 느림
2.
파일의 일관성이 깨져있는 것을 탐지해도 복구가 불가능한 경우가 많음
2.
저널링(Journaling)
•
inode나 비트맵의 수정이 있으면, 그 내용을 로그로 남김
◦
로그: 파일 시스탬 내 별도의 영역 또는 별도의 저장장치에 기록
•
동작 방식:
1.
파일의 연산을 수행할 때, inode나 Bitmap의 수정이 있으면 그 내용을 로그로 남김
2.
이 로그는 파일 시스템 내의 별도 영역에 남길 수도 있고 별도의 저장장치에 남길 수 있음(여기서는 별도 영역으로 남기는 경우로 설명)
3.
파일 연산을 할 때, 디스크의 변경사항을 바로 쓰지 않고 로그들을 Journal 영역에 먼저 기록함
4.
하나의 파일 연산에 기록되는 로그의 집합을 트랜잭션 이라고 부르는데
•
하나의 트랜잭션이 모두 기록되면, commit 되었다고 부르고
•
실제 inode와 Bitmap에 반영하게 됨
•
장점:
◦
로그를 작성하는 중 크래시가 발생하는 경우
: 실제 파일에 반영된 것이 아니기 때문에 일관성이 깨지지 않음
◦
실제 파일에 반영하는 중 크래시가 발생하는 경우
: Journal에 기록된 로그를 기반으로 다시 반경하면 됨