6-19
Block=4kb로 쪼개져있다
파일이 8kb이면 2개의 Block
파일이 6kb이면 2개의 Block but 2kb가 남는다.
block의 크기가 작으면 낭비되는 공간을 최소화할 수 있다.
block의 크기가 크면 블록접근을 적게 해도 된다. 블록접근도 모두 프로세스의 연산이기 때문에 연산이 줄수록 좋다.
4kb가 제일 적당한 것 같아서 block은 4kb!
블록은 파일시스템의 최소단위
블록그룹
홀수번끼리 성질이 같고 짝수번끼리 성질이 같다.
0번은 홀수번보다 성질이 하나 더 있다.(0번과 홀수번은 비슷)
0번의 Journal Log Area
Super Block, GDT, Inode Table이 중요!
Ext2/3 비슷
파일시스템
1. 파일 찾아가기
2. 삭제된 데이터 복구
슈퍼블록시그니처로 EXT인지 확인 가능
0x400
-슈퍼블록에서 확인해야 할 사항-
-block size
그룹당 블록수=0x8000
그룹당 Inode수=0x1E30
Inode 크기=0x100
블록수가 Inode수보다 많다
이유:
파일은 여러개의 블록
Inode는 각 파일당 하나
Inode에 각각의 파일 정보가 담겨있다.
2번째 블록->0x1000이 GDT
8B번째 블록->8B*0x1000(4kb)=0x8B000->Inode table
1번 Inode 0x100 2번 Inode 0x100.......총 0x1E30개 (Inode는 0이 아닌 1부터 시작)
3321은 3번 블록 그룹의 321번(각 블록에 1000개씩 Inode있다) Indexing 중요!
root의 Inode 번호 중요 2번!
0x8b000->0x100이 root의 Inode(2번이니까)
폴더랑 파일
inode table의 depth랑 블록 번호가 적혀있다.
depth가 0이 아니면 하나의 파일에 inode가 여러개일 수 있다. 떨어져있을 수 있다. 하지만 대게 뭉쳐있다.
inode 블록의 물리 주소->2277000
type 1: 파일 2: 디렉토리
log의 inode 0xB521
그룹당 Inode수 0x1E30
블록그룹: (0xB521-1)/0x1E30=6 : *0x8000(그룹당블록수)*0x1000(4kb)
Inode:0xB521 mod 0x1E30=1
짝수번째 블록그룹이니까 GDT 고려 없이 0x2000만 더하면 된다.
->30002000
->블록번호->0x301e5(*0x1000)=>블록의 물리주소
->recovery_log.txt => 0xB522가 recovery_log.txt의 inode번호
0x3002100(6번째 블록그룹의 2번째 Inode니까 0x30002000+inode크기 1개(0x100)->0x30002100)
0x30002100으로 가면 inode table인데 블록번호가 적혀있다. 0x30c00 -> 따라서 recovery_log.txt의 물리주소는 0x30c00000 파일 사이즈는 inode table에 적혀있다.(0x1BE0)
EXT는 블록으로 블록은 그룹으로 묶여있다.