복학 전 운영체제와 파이썬을 미리 공부해 가면 좋을 것 같다는 친구들의 말에
혼자 도전하면 당연히 안 하겠지 싶어 지원한 혼공단 덕분에
의지박약인 제가 ( 항상 간당하게 끝내긴 했지만 ) 믿기지 않지만 개강 전에 책 한 권을 다 보는 일이 있네요..
정해진 공부 양을 제가 계획한 시간 내에 끝내게 되고 (약간 J 같달까요)
늦어도 포기하지 않는 마음을 갖게 되어
개강해도 덜 끝낸 과제를 내지 않을 거란 확신은 생겼습니다 .. 감사해요 혼공단 🥹
다음 혼공단도 (지각 파티겠지만) 다른 공부를 위해 또 지원하게될 것 같습니다 감사했어요 🫶
Ch 14 가상 메모리
14 - 1 연속 메모리 할당
- 연속 메모리 할당 : 프로세스에 연속적인 메모리 공간을 할당
스와핑
- 현재 사용되지 않는 프로세스들을 보조기억장치의 일부 영역으로 쫓아내고
그렇게 생긴 빈 공간에 새 프로세스 적재
- 스왑 영역 : 이때 프로세스들이 쫓겨나는 보조기억장치의 일부 영역
- 스왑 아웃 : 현재 실행되지 않는 프로세스가 메모리에서 스왑 영역으로 옮겨지는 것
- 스왑 인 : 반대로 스왑 영역에 있던 프로세스가 다시 메모리로 옮겨오는 것
이점 ) 프로세스들이 요구하는 메모리 공간 크기 > 실제 메모리 크기 → 프로세스 동시실행⭕
메모리 할당
- 프로세스는 메모리의 빈 공간에 할당되어야 한다 .. 빈 공간이 여러 개 있다면?
최초 적합
최적 적합
최악 적합
이 존재함.
최초 적합 ( first - fit )
- 운영체제가 메모리 내의 빈 공간을 순서대로 검색하다 적재할 수 있는 공간을 발견하면 그 공간에 프로세스를 배치하는 방식
- 검색 최소화, 빠른 할당
최적 적합 ( best fit )
- 운영 체제가 빈 공간을 모두 검색해 본 뒤,
적재 가능한 가장 작은 공간에 할당
최악 적합 ( worst - fit )
- 운영체제가 빈 공간을 모두 검색해본 뒤,
적재 가능한 가장 큰 공간에 할당
외부 단편화
- 사실, 프로세스를 연속적으로 메모리에 할당하는 방식은 메모리를 효율적으로 사용하는 방법이 아님.
↪️ 외부 단편화 (external fragmentation)이라는 문제가 발생하기 때문
- 프로세스를 할당하기 어려울 만큼 작은 메모리 공간들로 인해 메모리가 낭비되는 현상
외부 단편화 해결 (1) : 메모리 압축 ( compaction )
: 여기저기 흩어져 있는 빈 공간들을 하나로 모으는 방식. 프로세스를 적당히 재배치시켜
흩어져 있는 작은 빈 공간들을 하나의 큰 빈 공간으로 만드는 방법
+) 외부 단편화 해결 -2 : 가상 메모리 기법, 페이징
14 - 2 페이징을 통한 가상 메모리 관리
+) 연속 메모리 할당의 두 가지 문제점
→ 외부 단편화 / 물리 메모리보다 큰 프로세스 실행 불가
가상 메모리
- 실행하고자 하는 프로그램을 일부만 메모리에 적재하여 실제 물리 메모리 크기보다 더 큰 프로세스를 실행할 수 있게 하는 기술
- 페이징, 세그멘테이션
페이징이란
외부 단편화가 발생했던 근본적인 문제?
→ 각기 다른 크기의 프로세스가 메모리에 연속적으로 할당되었기 때문임.
→ 페이징으로 외부 단편화를 해결할 수 있음
페이징 (paging)
- 프로세스의 논리 주소 공간을 페이지 (page)라는 일정 단위로 자르고,
메모리의 물리 주소 공간을 프레임 (frame)이라는 페이지와 동일한 일정한 단위로 자른 뒤
페이지를 프레임에 할당하는 가상 메모리 관리 기법
➕페이징에서의 스와핑
- 프로세스 단위의 스왑 인, 스왑 아웃이 아닌 페이지 단위의 스왑 인 (페이지 인),
스왑 아웃 (페이지 아웃)
- 메모리에 적재될 필요가 없는 페이지들은 보조기억장치로 스왑 아웃
- 실행에 필요한 페이지들은 메모리로 스왑 인
→ 프로세스를 실행하기 위해 모든 페이지가 적재될 필요 없다
달리 말해, 물리 메모리보다 큰 프로세스도 실행될 수 있다.
문제점🚫 )
프로세스를 이루는 페이지가 어느 프레임에 적재되어 있는지 CPU가 일일이 알기란 어렵다
프로세스가 메모리에 불연속적으로 배치되어 있다면 CPU 입장에서 이를 순차적으로 실행할 수가 없다. CPU 입장에서 ‘다음에 실행할 명령어 위치’를 찾기가 어려움.
페이지 테이블
- (실제 메모리 내의 주소인) 물리 주소에 불연속적으로 배치되더라도
(CPU가 바라보는 주소인) 논리 주소에는 연속적으로 배치되도록 하는 방법
- 페이지 번호와 프레임 번호를 짝지어 주는 일종의 이정표
→ 물리적으로는 분산되어 저장되어 있더라도 CPU 입장에서 바라본 논리 주소는 연속적으로 보임
→ CPU는 그저 논리 주소를 순차적으로 실행하면 될 뿐
+) 내부 단편화
- 페이지 크기가 10KB, 프로세스 크기 108KB?
2KB : 내부 단편화
하나의 페이지 크기보다 작은 크기로 발생
PTBR
- 프로세스마다 페이지 테이블이 있고, 각 페이지 테이블은 CPU 내의 프로세스
테이블 베이스 레지스터 (PTBR)가 가리킨다.
→ 페이지 테이블이 메모리에 있다면?? : 메모리 접근 시간 두 배로!
(페이지 테이블 참조하기 위해 한 번 / 페이지 참조하기 위해 한 번 )
TLB
: CPU 곁에 페이지 테이블의 캐시 메모리
페이지 테이블의 일부를 가져와 저장
- CPU가 접근하려는 논리 주소가 TLB에 있다면?TLB 히트 (메모리 접근 한 번)
- CPU가 접근하려는 논리 주소가 TLB에 없다면? TLB 미스 (메모리 접근 두 번)
페이징에서의 주소 변환
→ 특정 주소에 접근하고자 한다면 어떤 정보가 필요할까??
: (2가지 정보 필요) 어떤 페이지 • 프레임에 접근하고 싶은지 / 접근하려는 주소가 그 페이지
혹은 프레임으로부터 얼마나 떨어져 있는지
페이징 시스템에서의 논리 주소
→ 페이지 번호 (page number)와 변위 (offset)
<페이지 번호, 변위>로 이루어진 논리 주소는 페이지 테이블을 통해
<프레임 번호, 변위>로 변환된다.
(위의 두 변위는 같나? 페이지와 프레임의 크기가 같기 때문에 변위도 같음)
페이지 테이블 엔트리
페이지 테이블의 각각의 행
: 페이지 테이블 엔트리 (PTE)
현재까지 설명한 PTE
: 페이지 번호, 프레임 번호
이외에 담기는 정보는??
유효 비트 : 해당 페이지가 메모리에 적재되어 있는지 여부를 알려주는 비트
현재 해당 페이지에 접근 가능한지 여부
유효 비트 1 : 페이지가 메모리에 적재되어 있다.
유효 비트 0 : 페이지가 메모리에 적재되어 있지 않다.
→ 유효 비트가 0인 페이지에 접근하려고 하면??
→ 페이지 폴트 (page fault)라는 인터럽트 발생 (페이지가 메모리에 적재되어 있지 않으면 페이지 폴트가 발생함)
CPU가 페이지 폴트를 처리하는 과정은
하드웨어 인터럽트를 처리하는 과정과 유사함.
보호 비트
페이지 보호 기능을 위해 존재하는 비트
페이지에 접근할 권한을 제한하여 페이지를 보호하는 비트이다.
참조 비트
CPU가 이 페이지에 접근한 적이 있는지 여부
수정 비트 ( = dirty bit)
CPU가 이 페이지에 데이터를 쓴 적이 있는지 여부
➕수정 비트의 존재 이유??⤵️
수정 비트는 페이지가 메모리에서 사라질 때 보조기억장치에 쓰기 작업을 해야하는지,
할 필요가 없는지를 판단하기 위해 존재한다.
→ 수정된 페이지는 스왑 아웃될 때 보조기억장치에도 쓰기 작업을 거쳐야 한다.
→ 비트 1: 변경된 적 있는 / 0 : 변경된 적 없는 (한 번도 접근 x / 읽기만 했던 페이지)
14 - 3 페이지 교체와 프레임 할당
요구 페이징
: 처음부터 모든 페이지를 적재하지 않고 필요한 페이지만을 메모리에 적재하는 기법
: 요구되는 페이지만 적재하는 기법
+) 순수 요구 페이징
: 아무런 페이지도 메모리에 적재하지 않은 채 무작정 실행부터 하는 페이징 기법
( 프로세스의 첫 명령어를 실행하는 순간부터 페이지 폴트가 계속 발생하게 되고, 실행에 필요한 페이지가 어느 정도 적재된 이후부터 페이지 폴트 발생 빈도가 떨어짐)
→ 이러한 요구 페이징 시스템이 안정적으로 작동하려면 해결해야 할 문제?
→ 페이지 교체 / 프레임 할당 ⤵️
페이지 교체 알고리즘
- 요구 페이징 기법으로 페이지들을 적재하다 보면 언젠가 메모리가 가득 차게 된다
당장 실행에 필요한 페이지를 적재하려면 적재된 페이지를 보조기억장치로 내보내야 함
이때, 어떤 페이지를 내보낼까? 이를 결정하는 방법(알고리즘)이 페이지 교체 알고리즘
→ 무엇이 좋은 페이지 교체 알고리즘일까?
→ 페이지 폴트가 적은 알고리즘!
( 페이지 폴트가 발생하면 보조기억장치에 접근해야 해서 성능 저하 )
→ 그럼 페이지 폴트의 횟수를 알 수 있어야 하는데 어떻게 알 수 있을까??
→ 페이지 참조열 (page reference string)
( CPU가 참조하는 페이지들 중 연속된 페이지를 생략한 페이지열 )
EX) CPU가 아래와 같은 순서로 페이지에 접근했다 가정➕
2 2 2 3 5 5 5 3 3 7
여기서 연속된 페이지를 생략한 페이지열, 다시 말해 아래 숫자열이 페이지 참조열이다.
2 3 5 3 7
1) FIFO 페이지 교체 알고리즘
: 가장 단순한 방식 / 메모리에 가장 먼저 올라온 페이지부터 내쫓는 방식 / 오래 머물렀음 나가
ex) 프로세스가 사용할 수 있는 프레임이 세 개 있다고 가정하고 페이지 참조열이 아래 같음
2 3 1 3 5 2 3 4 2 3
FIFO 페이지 교체 알고리즘은 아래와 같이 진행되어 총 네 번의 페이지 폴트 발생함.
( 적재된 페이지를 교체하기 위해 발생한 페이지 폴트만을 페이지 폴트로 간주. )
- 프로그램 실행 초기에 잠깐 실행될 페이지 (도 존재/ 이는 내쫓기 가능)
- 프로그램 실행 내내 사용될 페이지 ⬅️먼저 적재되었다고 내쫓아선 안됨.
+) FIFO 페이지 교체 알고리즘 – 보완책! ➕
: 2차 기회 (second - chance) 페이지 교체 알고리즘
- 참조 비트 1 : CPU가 한 번 참조한 적이 있는 페이지 (바로 내쫓지 않고 참조 비트를 0으로 만든 뒤 현재 시간을 적재 시간으로 설정함) ( 한 번 더 기회를 주기)
- 참조 비트 0: CPU가 참조한 적이 없는 페이지 ( 내쫓기 )
2) 최적 페이지 교체 알고리즘
- CPU에 의해 참조되는 횟수를 고려하는 페이지 교체 알고리즘
- 메모리에 오래 남아야 할 페이지는 자주 사용될 페이지
- 메모리에 없어도 될 페이지는 오랫동안 사용되지 않을 페이지
→ 앞으로의 사용 빈도가 가장 낮은 페이지를 교체하는 알고리즘
ex) 프로세스가 사용할 수 있는 프레임이 세 개 있고, 페이지 참조열 아래.
2 3 1 3 5 2 3 4 2 3
최적 페이지 교체 알고리즘은 아래 그림과 같이 총 두 번의 페이지 폴트가 발생함.
FIFO 알고리즘에 비하면 페이지 폴트 빈도가 훨씬 낮아짐.
→ 가장 낮은 페이지 폴트율을 보장하는 페이지 교체 알고리즘
→ BUT!실제 구현이 어려움
- ‘앞으로 오랫동안 사용되지 않을 페이지? 어떻게 예측하지?’ → 다른 페이지 교체 알고리즘 성능을 평가하기 위한 하한선으로 간주.
3) LRU(Least - Recently - Used) 페이지 교체 알고리즘
- 최적 페이지 교체 알고리즘 : 가장 오래 사용되지 않을 페이지 교체
- LRU 페이지 교체 알고리즘 : 가장 오래 사용되지 않은 페이지 교체
( ‘최근에 사용되지 않은 페이지는 앞으로도 사용되지 않지 않을까?’ )
+) 기타 페이지 교체 알고리즘
스래싱과 프레임 할당
- 페이지 폴트가 자주 발생하는 이유
: 나쁜 페이지 교체 알고리즘을 사용해서 / 프로세스가 사용할 수 있는 프레임 자체가 적어서
→ CPU는 페이지 폴트가 자주 발생하게 됨. 실행의 맥이 끊김 → CPU의 이용률도 떨어짐. 페이지 교체에 너무 많은 시간을 쏟으면 성능에도 악영향 미침
스래싱
: 프로세스가 실행되는 시간보다 페이징에 더 많은 시간을 소요하여 성능 (CPU 이용률)이 저해되는 문제
- 동시 실행되는 프로세스의 수를 늘린다고 CPU 이용률이 높아지는 것이 아니다
(비례함이 아님을 나타냄)
멀티프로그래밍의 정도
: 메모리에 동시에 실행되는 프로세스의 수
→ 각 프로세스가 필요로 하는 최소한의 프레임 수가 보장되지 않았기 때문
→ 각 프로세스가 필요로 하는 최소한의 프레임 수를 파악하고
프로세스들에게 적절한 프레임을 할당해주어야 한다. ⤵️ (프레임 할당 방식 )
1) 균등 할당 (equal allocation)
- 가장 단순한 할당 방식 / 모든 프로세스들에게 균등하게 프레임을 할당하는 방식
2) 비례 할당 ( proportional allocation )
- 프로세스의 크기를 고려하자 / 프로세스 크기에 비례하여 프레임 할당
- 크기가 큰 프로세스인데 막상 실행해 보니 많은 프레임을 필요로 하지 않으면? / 크기가 작은 프로세스인데 막상 많은 프레임을 필요로 하면?
→ 결국 프로세스가 필요로 하는 프레임 수는 실행해 봐야 안다.
+) 균등, 비례 할당 방식은 프로세스의 실행 과정을 고려하지 않고 단순히 프로세스의 크기와 물리 메모리의 크기만을 고려한 방식이라는 점에서 정적 할당 방식이다.
프로세스를 실행하는 과정에서 배분할 프레임을 결정하는 방식 ⤵️
1) 작업 집합 모델
- 프로세스가 실행하는 과정에서 배분할 프레임 결정
- 스레싱이 발생하는 이유는 빈번한 페이지 교체 때문
→ 그렇다면 CPU가 특정 시간 동안 주로 참조한 페이지 개수만큼만 프레임을 할당하면 된다.
- ‘프로세스가 일정 기간 동안 참조한 페이지 집합’을 기억하여 빈번한 페이지 교체를 방지
→ 작업 집합이란 “실행 중인 프로세스가 일정 시간 동안 참조한 페이지의 집합”
2) 페이지 폴트 빈도
- 프로세스가 실행하는 과정에서 배분할 프레임 결정
- 두 개의 가정에서 생겨난 아이디어
1. 페이지 폴트율이 너무 높으면 그 프로세스는 너무 적은 프레임을 갖고 있다.
2. 페이지 폴트율이 너무 낮으면 그 프로세스가 너무 많은 프레임을 갖고 있다.
- 페이지 폴트율에 상한선과 하한선을 정하고, 그 내부 범위 안에서만 프레임을 할당하는 방식
+) 작업 집합 모델, 페이지 폴트 빈도는 프로세스의 실행을 보고 할당할 프레임 수를 결정한다는 점에서 동적 할당 방식이다.
CH 15 파일 시스템
15 -1 파일과 디렉터리
파일 시스템 (file system)
: 파일과 디렉터리를 관리하는 운영체제 내의 프로그램 / 파일과 디렉터리를 다루어 주는 프로그램
- 보조기억장치의 데이터 덩어리, 파일과 디렉터
파일
- 보조기억장치에 저장된 관련 정보의 집합
- 의미 있고 관련 있는 정보를 모은 논리적 단위
파일을 이루는 정보 : 파일을 실행하기 위한 정보 + 부가 정보 ( = 속성, 메타 데이터 )
파일의 속성 ⤵️
파일 연산을 위한 시스템 호출 ⤵️
파일 생성 / 파일 삭제 / 파일 열기 / 파일 닫기 / 파일 읽기 / 파일 쓰기 / 등 …
디렉터리
- 윈도우에서는 폴더 (floder)
↪️ 옛날 운영체제에는 하나의 디렉터리만 존재했음. 모든 파일이 하나의 디렉터리 아래에 있었음 .
여러 계층으로 파일 및 폴더를 관리하는 트리 구조 디렉터리
최상위 디렉터리 (루트 디렉터리, / ) , 서브 디렉터리
경로
- 디렉터리를 이용해 파일/디렉터리의 위치, 나아가 이름까지 특정 지을 수 있는 정보
- 절대 경로 / 상대 경로
+) 같은 디렉터리에는 동일한 이름의 파일이 존재할 수 없지만, 서로 다른 디렉터리에는 동일한 이름의 파일이 존재할 수 있음.
1) 절대 경로
: 루트 디렉터리에서 자기 자신까지 이르는 고유한 경로
e.g.) /home/minchul/a.shu
2) 상대 경로
: 현재 디렉터리에서 자기 자신까지 이르는 경로
e.g.) 현재 디렉터리 경로가 /home 일 경우 guest/d.jpg
디렉터리 연산을 위한 시스템 호출 ⤵️
: 디렉터리 생성 / 디렉터리 삭제 / 디렉터리 열기 / 디렉터리 닫기 / 디렉터리 읽기 / 등 …
디렉터리 엔트리
→ 많은 운영체제에서는 디렉터리를 그저 ‘특별한 형태의 파일’로 간주한다.
즉, 디렉터리는 그저 ‘포함된 정보가 조금 특별한 파일’
→ 파일의 내부에는 파일과 관련된 정보들이 있다면,
디렉터리의 내부에는 해당 디렉터리에 담겨 있는 대상과 관련된 정보들이 담겨 있다.
( 이 정보는 보통 테이블(표) 형태로 구성 )
⬆️각 엔트리 (행)에 담기는 정보
- 디렉터리에 포함된 대상의 이름
- 그 대상이 보조기억장치 내에 저장된 위치(를 유추할 수 있는 정보)
위와 같이 디렉터리 엔트리에 파일 속성을 명시하는 경우도 있음
15 - 2 파일 시스템
파티셔닝과 포매팅
→ 이제 막 공장에서 생산되어 한 번도 사용된 적 없는 새 하드 디스크 / SSD ?
→ 파티셔닝, 포매팅하기 전까지는 사용할 수 없다.
파티셔닝
: 저장 장치의 논리적인 영역을 구획하는 작업
( 하드 디스크나 SSD처럼 용량이 큰 저장 장치를 하나 이상의 논리적인 단위로 구획하는 거)
+) 파티셔닝 작업을 통해 나누어진 영역 하나하나를 파티션파티션이라고 한다.
포매팅
: 파일 시스템을 설정/어떤 방식으로 파일을 관리할지 결정, 새로운 데이터를 쓸 준비하는 작업
+) 저수준 포매팅 ( 저장 장치를 생성할 당시 공장에서 수행되는 물리적인 포매팅 ) / 논리적 포매팅 ( 파일 시스템을 생성하는 포매팅 / 여기서 설명은 논리적 포매팅임 )
ex ) USB 포매팅
→ 포매팅할 때 파일 시스템이 결정된다는 것을 알 수 있음
→ 파일 시스템에는 여러 종류가 있고, 파티션마다 다른 파일 시스템을 설정할 수 있음
→ 포매팅까지 완료하여 파일 시스템을 설정했다면 이제 파일과 디렉터리 생성이 가능해짐
파일 할당 방법
- 포매팅까지 끝난 하드 디스크에 파일을 저장하기
- 운영체제는 파일/디렉터리를 블록 단위로 읽고 쓴다
→ 즉, 하나의 파일이 보조기억장치에 저장될 때에는 여러 블록에 걸쳐 저장된다.
이 블록에 사용하는 파일을 할당해야 한다. 크기가 작은 파일은 적은 수의 블록에 걸쳐 저장될 것이고, 크기가 큰 파일은 여러 블록에 걸쳐 저장됨
파일을 보조기억장치에 할당하는 두 가지 방법 : 연속 할당, 불연속 할당 ⤵️
연속 할당 : 이름 그대로 보조기억장치 내 연속적인 블록에 파일 할당
→ 연속된 파일에 접근하기 위해 파일의 첫 번째 블록 주소와 블록 단위의 길이만 알면 됨
→ 디렉터리 엔트리 : 파일 이름 & 첫 번째 블록 주소 & 블록 단위 길이 명시
부작용 !! : 구현이 단순하지만 외부 단편화를 야기할 수 있음 ⤵️
파일 D와 F 삭제 (잔여 블록 11개, 블록 7개 이상 사용하는 파일 할당 X ) ⤵️
불연속 할당 – 연결 할당
- 각 블록의 일부에 다음 블록의 주소를 저장하여 각 블록이 다음 블록을 가리키는 형태로 할당
- 파일을 이루는 데이터 블록을 연결 리스트로 관리
- 불연속 할당의 일종 : 파일이 여러 블록에 흩어져 저장되어도 무방
→ 디렉터리 엔트리 : 파일 이름 & 첫 번째 블록 주소 & 블록 단위의 길이
+) 디렉터리 엔트리에
첫 번째 블록 주소와
마지막 블록 주소를
기록할 수도 있다.
단점 !!
1) 반드시 첫 번째 블록부터 하나씩 읽어 들여야 한다. ( 임의 접근 속도가 매우 느리다 )
2) 오류 발생 시 해당 블록 이후 블록은 접근이 어렵다.
불연속 할당 – 색인 할당
- 파일의 모든 블록 주소를 색인 블록이라는 하나의 블록에 모아 관리하는 방식
- 파일 내 임의의 위치에 접근하기 용이
→ 디렉터리 엔트리 : 파일 이름 & 색인 블록 주소
파일 시스템 살펴보기
FAT 파일 시스템
- 연결 할당(불연속) 기반 파일 시스템 / 연결 할당의 단점(첫 번째부터~/오류발생 시~)을 보완
- 각 블록에 포함된 다음 블록 주소를 한데 모아 테이블 (FAT; file alloation table)로 관리
+) 더 이상 다음 블록이 없으면 특별한 표시자를 표기한다
( 옆의 그림에서는 -1로 표기했다 )
빈 공간은 아직 할당되지 않았음을 의미한다.
→ FAT를 활용하는 파일 시스템 : FAT 파일 시스템
+) FAT가 메모리에 캐시 될 경우 느린 임의 접근 속도 개선 가능함
→ 디렉터리 엔트리 (파일 속성과 관련한 다양한 정보들이 있다)
+) 속성 (file attribute) 항목은 해당 파일이 읽기 전용 파일인지, 숨김 파일인지, 시스템 파일인지, 일반 파일, 디렉터리인지 식별하기 위한 항목이다.
유닉스 파일 시스템
- 색인 할당 기반 파일 시스템
- 색인 블록 == i - node
→ 파일 속성 정보와 15개의 블록 주소 저장 가능
유닉스 파일 시스템에는 파일마다 i-node 존재
i-node마다 번호가 부여되어 있음
i-node들은 파티션 내 특정 영역에 모여 있음⬇️
i-node를 사용하는 파일 시스템
➕
ex) 15개 이상을 차지하는 파일은 어떻게 해결??
1. 블록 주소 중 12개에는
직접 블록 주소 저장
(직접 블록 : 파일 데이터가 저장된 블록)
2. 1번으로 충분하지 않다면
13번째 주소에 단일 간접 블록 주소 저장
(단일 간접 블록 :
파일 데이터를 저장한 블록 주소가 저장된 블록)
3.
2번으로 충분하지 않다면 14번째 주소에 이중 간접 블록 주소 저장
(이중 간접 블록 : 단일 간접 블록들의 주소를 저장하는 블록 )
4.
3번으로 충분하지 않다면
15번째 주소에 삼중 간접 블록 주소 저장
(삼중 간접 블록 : 이중 간접 블록들의 주소를 저장하는 블록)
→ (유닉스 파일 시스템의) 디렉터리 엔트리 : i-node가 파일 시스템의 핵심!
(파일의 모든 것을 다 담고 있다 해도 과언 아님! )
(1) : 최초 적합
(2) : 최악 적합
(3) : 최적 적합
'혼공컴운' 카테고리의 다른 글
| [혼공컴운] 11기 회고 (0) | 2024.02.20 |
|---|---|
| [혼공컴운] Ch 12~13 __ 혼공학습단 11기 5주차 (1) | 2024.02.08 |
| [혼콩컴운] Ch 09 ~ 11 __ 혼공학습단 11기 4주차 (2) | 2024.01.31 |
| [혼공컴운] Ch 06 ~ 08 _ 혼공학습단 11기 3주차 (2) | 2024.01.21 |
| Chapter 04-2 레지스터 (2) | 2024.01.14 |
