[OS] Lecture 11. File System (5_5) - kibitzing/EnGrow GitHub Wiki
진구
- 디스크 얼로케이션 어떻게 할건지?
- continuous: 접근성 훌륭, 유연성 떨어짐
- linked allocation: 링크드리스트 처럼, 유연하지만 직접접근 비효율적
- indexed allocation: 책의 목차나 인덱스처럼 테이블로 주소 잘 적어둠, 직접접근 효율적, 순차적으로는 비효율이라고 함
- free space 어떻게 관리할지?
- bitmap: 빈 블록 안 빈 블록 일일히 관리
- -> 이걸 그룹으로 묶으면 counting: 쭉 빈 부분을 테이블로 관리
- linked list: 그냥 비효율적..ㅋ
- -> 이걸 그룹으로 묶어서 링크 걸면 grouping
세영
| Method | 방식 | 장점 | 단점 |
|---|---|---|---|
| Continuous allocation | 연속된 블록을 한 파일에 할당 | 순차적인 접근 → 효율적으로 파일 접근 가능 | 공간 확보 어려움, 외부 단편화, 파일이 커지는 것을 고려해야 하므로 크기 결정이 어려움 |
| Linked allocation (Discontinuous allocation) | Linked list로 블록을 연결하는 방법, 디렉토리는 각 파일의 첫 블록에 대한 포인터를 가짐, FAT 사용 → MS-DOS, Windows 등에 사용 | 단순함, 외부 단편화 없음 | 직접 접근에 비해 비효율적, 포인터 저장을 위한 공간 필요, 사용자가 포인터를 건드릴 수 있는 신뢰성 문제 |
| Indexed allocation (Discontinuous allocation) | 파일이 저장된 블록의 정보(포인터)를 인덱스 블록에 모아두는 방법, Unix 등에 사용 | 직접 접근 시 효율적 | 순차 접근 시 비효율적, 파일마다 인덱스 블록을 유지 (공간 낭비, 블록 크기에 따라 파일 최대 크기 제한) |
| Method | 방식 | 장점 | 단점 |
|---|---|---|---|
| Bit vector | 시스템의 모든 블록들에 대한 사용 여부를 비트로 표시 | 간단하고 효율적임 | 전체를 메모리에 보관해야 하므로 대형 시스템에 부적합 |
| Linked list | 빈 블록을 링크드 리스트로 연결 | 비효율적 | |
| Grouping | n개의 블록을 그룹 단위로 묶어서, 그룹 단위로 linked list로 연결 | 연속된 빈 블록을 쉽게 찾을 수 있음 | |
| Counting | 연속된 빈 블록들 중 첫 번째 블록의 주소와 연속된 블록의 수를 테이블로 유지 | Continuous allocation 시스템에 유리 |