File System - UFS (5)

이번 글에서는 파일 이름 참조 모델과 파일 복구, 일관성 검사에 대해서 다루어 볼 것이다.

[디렉토리 엔트리]
UFS의 디렉토리 엔트리는 Ext 파일시스템과 동일하게 파일이름, inode 주소, 유형 값을 포함한다. 디렉토리 엔트리의 길이는 파일 이름 길이가 255개 문자인 파일 이름 길이를 참조하여 결정된다. 이름은 ASCII 형식으로 저장되는데 Ext 파일의 이름은 NULL로 끝나지 않는 반면 UFS 파일이름은 NULL로 끝난다.
디렉토리 엔트리의 위치는 디렉토리에 할당 된 블록이다. 파일과 디렉토리의 구분은 모드 필드로 할 수 있다.
UFS도 Ext 파일시스템과 동일하게 각 엔트리의 레코드 값이 다음 엔트리 시작을 가리키고 있으며 마지막 디렉토리 엔트리의 레코드 값은 블록 마지막을 가리키고 있다. 파일이 삭제된다면 삭제 파일 앞의 디렉토리 엔트리 레코드 값이 삭제 파일 뒤 엔트리의 시작을 가리켜 삭제 파일의 엔트리를 덮어 씌어버린다.
디렉토리 엔트리의 첫 번째와 두 번째는 ".", ".." 이다. 루트 디렉토리는 항상 inode2에 위치한다.
UFS도 Ext 파일시스템과 마찬가지로 하드링크와 소프트링크를 지원하는데 이에 대한 설명은 Ext 파일시스템 부분에서 자세히 설명하였으므로 지면을 절약하기 위하여 여기서는 생략하겠다. 

[분석시 주의 사항]
디렉토리 엔트리에는 히든데이터가 존재 할 수 있다. 마지막 디렉토리 엔트리와 블록 사이의 공간은 사용되고 있지 않은 공간이다. 그렇기 때문에 그 공간에 임의로 데이터를 넣을 수 있다. 하지만 이 공간의 히든 데이터는 오래 존재하지 못할 수도 있다. OS가 파일이나 디렉토리를 생성할 시 디렉토리 엔트리 할당을 위하여 사용되고 있지 않은 공간을 사용하여 디렉토리 엔트리를 생성 할 수 있기 때문이다. 이렇게 되면 히든데이터는 손상을 입거나 지워지고 만다.  

지금까지 알아본 파일시스템의 참조 모델들과 데이터를 이용하여 파일 할당, 삭제 과정을 알아봐야 하나 Ext 파일시스템과 과정이 거의 동일하여 지면을 절약하기 위해 따로 알아보진 않겠다.
다른 점이라고는 파일이나 디렉토리의 내용을 저장하는 곳(블록, 조각)과 그룹 기술자, inode 테이블 등이 있는 곳(실린더 그룹)이 다를 뿐 그 과정이나 개념을 동일하다.

[파일 복구]
UFS에서는 파일 복구가 쉽지 않다. 조각이라는 저장단위 때문에 파일의 내용이 흩어져 있을 수 있기 때문이다. 

[일관성 검사]
일관성 검사는 파일시스템 데이터 구조체에서 유효한 값과 히든 데이터등을 찾으려고 수행하는 검사이다. 검사 대상에는 슈퍼블록, 그룹 기술자, inode 엔트리, 디렉토리 엔트리 등이 해당된다. 
슈퍼블록의 경우 크기가 크지만 모두 사용하지 않고 또 OS자체에서 사용하지 않는 필드들이 있어 이러한 곳에 히든데이터 존재 할 수 있다.
그룹 기술자의 경우도 슈퍼블록과 유사하다.
inode 엔트리의 경우 모든 엔트리를 조사해야 하며, 엔트리가 할다 된 블록과 조각이 할당 블록, 조각인지 확인해 봐야 한다. inode 테이블의 경우 마지막 부분에 사용되고 있지 않은 공간이 있다. 이 공간은 파일이나 디렉토리의 내용을 저장하기 위해 OS가 사용 할 수도 있는 공간이고 히든 데이터가 있을수도 있는 공간이다. 
디렉토리 엔트리의 경우 마지막 디렉토리 엔트리와 블록 마지막 사이에 사용되지 않고 있는 공간이 존재한다. 이 공간은 OS가 사용하고 싶으면 사용 할 수 있는 공간이어서 데이터 유지 기간이 불규칙한점이 있긴 하지만 히든 데이터가 있기에는 문제가 없는 공간이다. 그렇기 때문에 한번쯤은 조사를 해 볼 필요가 있다.