File System - Ext (7)

이전 글까지 해서 Ext의 참조 모델 별로 어떤 데이터가 있는지 알아 보았다. 

이번 글에서는 이러한 참조 모델 데이터들이 어떻게 혼합되어 파일이 생성되고 삭제 되는지 알아 볼 것이다.

[파일 생성]
이 과정에서는 dir 이라는 디렉토리가 있다고 가정하며, File.txt 파일을 생성한다는 가정 상황을 시나리오로 할 것이다.

1. 일단 파일시스템 1024byte 오프셋에 위치 하는 슈퍼 블록의 참조하여 블록의 크기와 블록 그룹의 블록 개수, 블록 그룹 내의 inode 개수를 파악한다.

 * 참고 : 해당 시나리오에서 블록의 크기는 1024byte, 블록 그룹의 블록 개수는 8192개, 블록 그룹 별 inode의 개수는 2016개라고 하겠다.

2. 슈퍼 블록의 분석이 끝나면 그룹 기술자 테이블을 참조한다. 이 테이블은 각 블록 그룹의 레이아웃을 설명하며 블록 2~3에 위치한다.

[그림 1 - 2번 과정]

3. 파일을 생성 할 디렉토리인 dir을 찾으려면 먼저 루트 디렉토리를 찾아야 한다. 루트 디렉토리는 보통 inode 2를 사용한다. inode 2의 위치는 슈퍼 블록을 참조하여 파악 해 둔 블록 그룹 별 inode 개수를 이용하면 쉽게 위치를 파악 할 수 있고, 해당 시나리오에서는 블록 그룹 0에 위치한다. 블록 그룹 0의 그룹 기술자 테이블을 참조하면 inode 테이블의 위치를 알려주는 엔트리가 있고 그 엔트리를 참조하면 inode 테이블의 위치를 파악 할 수 있다.

  * 참고 : 해당 시나리오에서는 블록 5에서 시작한다고 가정한다.

[그림 2 - 3번 과정]

4. 블록 5에서 inode 테이블을 읽고, 두 번째 엔트리(inode 2)를 분석하면 루트 디렉토리의 디렉토리 엔트리가 어떤 블록에 위치하는지 알 수 있다.

  * 참고 : 이 시나리오에서는 블록 260에 있다고 가정한다.

[그림 3 - 4번 과정]

5. 블록 260의 디렉토리 엔트리를 읽고, 디렉토리 엔트리의 내용을 해석한다. 디렉토리 엔트리의 첫 번째와 두 번째 엔트리는 ".", ".."를 위한 엔트리이고, 각 엔트리 레코드를 참고하여 다음 엔트리의 위치를 파악 한다. 엔트리 위치 파악이 다 되었다면 dir 디렉토리를 검색한다.

 * 참고 : 해당 시나리오에서는 inode 5444를 할당 받았다고 가정한다. 
 * 참고 : 이 때 dir 디렉토리의 접근 시간은 업데이트 된다.

[그림 4 - 5번 과정]

6. 이번에는 dir 디렉토리의 위치를 알아야 한다. dir 디렉토리의 inode를 그룹 별 inode 수로 나누면 어떤 블록 그룹에 위치하는지 알 수 있다. 

 - dir 디렉토리 inode(5444) / 슈퍼 블록에서 알아낸 블록 그룹 별 inode 수(2016) = 2

dir 디렉토리는 계산 결과 블록 그룹 2에 위치한다. 또 블록 그룹 2의 그룹 기술자 테이블을 참조하여 inode 테이블이 어디에 위치하는지 알 수 있다.

 * 참고 : 이 시나리오에서는 블록 그룹 2의 inode 테이블이 17889 블록에서 시작한다고 가정한다.

7. inode 테이블을 읽고 inode 5444의 엔트리를 참조한다. 엔트리를 분석하면 dir 디렉토리의 디렉토리 엔트리가 어떤 블록에 위치하고 있는지 파악 할 수 있다.

 * 참고 : 해당 시나리오에서는 블록 18556에 있다고 가정한다.
 * 참고 : 엔트리는 블록 그룹 0에서부터 계산해보면 알 수 있다.
            - 블록 그룹 0의 inode 테이블 엔트리 : 0~2015
            - 블록 그룹 1의 inode 테이블 엔트리 : 2016~4031
            - 블록 그룹 2의 inode 테이블 엔트리 : 4032~6047  -> 현재 찾으려고 하는 inode 5444에서 시작 엔트리 번호를 빼 주면 해당 inode의 상대적 엔트리 번호가 나온다. 즉 해당 시나리오에서는 1412 번째 엔트리이다.

[그림 6 - 7번 과정]

8. dir 디렉토리의 디렉토리 엔트리를 읽고 디렉토리 엔트리의 목록을 파악한다. 그 후 디렉토리에서 사용되고 있지 않은 공간을 찾는다. 생성 할 파일의 필요 공간을 계산 하면(고정 8byte + 파일 이름 길이(7byte), 4의 배수로 반올림) 총 16바이트가 필요하다. 만약 해당 디렉토리에 다른 파일이 있다면 파일 이름을 비교하여 그 파일들의 이름과 해당 파일의 이름 순서를 고려 해 할당한다.

 * 참고 : 이 때 디렉토리에는 수정 시간과 변경 시간이 업데이트 된다.
 * 참고 : ".."가 dir 디렉토리의 마지막이라고 가정한다.

9. 아직 파일이 완전히 생성 된 것은 아니다. 파일에 할당 할 inode가 있어야 하는데 하드디스크 헤더에 부담을 덜어주기 위해 Ext 파일시스템은 부모와 동일한 그룹 블록에 inode를 할당한다. inode의 할당 상태를 관리하는 inode 비트맵을 찾기 위해 그룹 기술자 테이블을 참조한다. inode 비트맵을 찾아 참조하고 "첫 번째 적용" 알고리즘을 사용하여 비 할당 inode를 검색한다. 그 후 검색이 완료 된 inode를 할당 하기 위해 해당 inode 비트맵 값을 0에서 1로 변경한다

 * 참고 : 해당 시나리오에서는 inode 비트맵은 17880 블록에 존재하며, 비 할당 inode는 inode 5576이 있다고 가정한다.

10. inode 테이블에 inode 5576을 초기화하고 타임 스탬프 값을 현재 시간으로 업데이트 한다. 또 링크 수는 디렉토리 엔트리 링크에 해당하는 1로 설정한다.

[그림 7 - 10번 과정]

11. 이제 파일 내용을 저장하기 위한 블록을 할당하여야 한다. 블록의 할당 상태는 블록 비트맵에서 관리하는데 inode 비트맵을 찾았던 것 처럼 그룹 기술자 테이블을 참조하여 블록 비트맵의 위치를 파악하고 "첫 번째 검색" 알고리즘을 적용하여 비 할당 된 블록을 찾는다. 검색이 완료되면 찾은 블록을 할당 하기 위해 비트맵 값을 0에서 1로 변경한다.

 * 참고 : 이 때 슈퍼블록과 그룹 기술자 테이블에 있는 블록 개수 현황들이 업데이트 된다.
 * 참고 : 해당 시나리오에서는 블록 비트맵은 블록 17881에 위치하고, 할당 할 블록들은 총 5개이며, 20004~20007, 20010 블록이라고 가정한다.

할당이 되면 블록 포인터를 설정해야 하는데 블록 개수가 12개를 넘지 않으므로 직접 포인터로 설정되어 inode에 블록의 주소들이 저장된다.

[그림 8 - 11번 과정]

12. 파일 내용이 할당 된 블록에 저장된다.

 

[파일 삭제]
파일 삭제는 위 과정과 거의 동일하며 후반부 과정이 조금 다를 뿐이다.

위 생성 과정에서 다시 File.txt를 삭제한다고 하였을 때 아래 과정을 거친다.

1. dir 디렉토리의 디렉토리 엔트리를 찾고 그 내용을 분석하여 목록을 파악하는 과정까지는 동일하다.(8번 과정까지이다)

2. 그 후 File.txt를 삭제하게 되면 File.txt 파일 이전에 존재하는 ".." 의 디렉토리 엔트리의 레코드 값이 증가되어 만약 File.txt가 삭제되어 ".."가 마지막 디렉토리 엔트리라면 블록 끝을 가리키게 된다. 

 * 참고 : 해당 시나리오 에서는 블록의 끝을 1500이라고 가정 한다. 
 * 참고 : 이 때 dir 디렉토리의 수정시간과 변경 시간이 업데이트 된다.

 [그림 9 - 2번 과정]

3. inode 테이블의 inode 5576은 파일이 삭제되었다는 것을 표시하기 위해 링크 값을 1에서 0으로 변경한다.

 [그림 10 - 3번 과정]

4. inode 5576의 할당 상태를 비 할당 상태로 변경하기 위해 inode 비트맵의 inode 5576 비트맵을 1에서 0으로 변경한다.

 * 참고 : 이 때 슈퍼블록과 그룹 기술자 테이블에 있는 비 할당 inode 개수 현황이 업데이트 된다.

5. 또 할당 된 파일 내용의 블록을 할당 해제 하기 위해 해당 블록의 블록 비트맵 값을 1에서 0으로 변경하며, 블록 포인터 또한 inode에서 제거한다.

 * 참고 : 이 때 해당 inode의 수정 시간, 변경 시간, 삭제 시간이 업데이트 된다.

[그림 11 - 4, 5번 과정]

위처럼 삭제 된 후 inode나 블록이 재 할당만 되지 않으면 다시 파일을 복구 할 수 있다.