운영체제(10) Storage(File) Management

 

 

1. File

 
<Why we need Files?>
File : 데이터를 영구적으로 저장하고 유지할 수 있는 중요한 개념이다.
Contiguous logical address space, 영구 저장 장치.

 
<File attributes>
Name : 사용자가 읽을 수 있는 형식으로 보관된 정보만 제공된다. 
Type : 다양한 유형을 지원하는 시스템에 필요하다. 
Location : device의 파일 위치에 대한 포인터. 
Size : 현재 파일 크기.
Protection : 읽기, 쓰기, 실행을 수행할 수 있는 사용자를 제어한다. 
Time, data and user identification : 보호, 보안 및 사용 모니터링을 위한 데이터
-> file에 대한 정보는 디스크에 유지되는 디렉토리 구조에 보관된다. 
 
<File types - name, extension>

 
<File Related Shell CMD>
(1) ls -la : 디렉토리(폴더) 내의 파일과 디렉토리를 나열, 숨겨진 파일들까지 다 자세한 정보로 보여줌
(2) cd : 현재 작업 중인 디렉토리를 변경하는 명령어
(3) cat, less, head, tail : 파일 내용을 터미널에 출력, 파일을 터미널에서 페이지 단위로 읽게 함, 
    파일의 처음 몇 줄을 터미널에 출력, 파일의 마지막 몇 줄을 터미널에 출력하는 명령어
(4) rm : 파일이나 디렉토리를 삭제하는 명령어
(5) cp : 파일이나 디렉토리를 복사하는 명령어
(6) mv : 파일이나 디렉토리를 이동하거나, 이름을 변경하는 명령어
(7) ln : 파일이나 디렉토리에 대한 링크를 생성하는 명령어
(8) grep : 파일이나 텍스트 데이터에서 패턴을 검색하는 명령어
(9) touch : 한번에 전체를 컴파일한다. 빈 파일을 생성하거나 파일의 수정 시간을 변경할 때 사용됨
(10) vi : 텍스트 편집기, 파일을 열고 수정하는 명령어
(11) mkdir, rmdir : 디렉토리(폴더)를 생성하는 명령어, 비어 있는 디렉토리를 삭제하는 명령어
(12) chgrp, chown : 파일이나 디렉토리의 소유 그룹을 변경, 소유자를 변경하는 명령어
 
< Access Lists and Groups>
Mode of access : read, write, execute 3가지가 있다.
[ex] 예를 들어, 각각의 접근 권한이 아래 사진과 같을 경우,
       터미널 창에는  chmod 761 game이다. 

 
<Tree-Structured Directories>
공부가 많고,, 힘이 들어요.. 챗 지피티를 참고하자. 

-> 절대 또는 상대 path name을 가진다. 
-> 새로운 File 작성은 현재 디렉토리에서 수행된다.

rm <file-name>	파일 삭제
mkdir <dir-name>	새 하위 디렉토리 작성은 현재 디렉토리에서 수행
mkdir count	위의 mkdir의 예시

 
<File-system Structure>
파일 구조 : 논리 저장 장치, 관련 정보 수집
파일 시스템은 secondary storage(보조 스토리지, 디스크)에 있다. 
-> File control block : 파일에 대한 정보로 구성된 스토리지 구조이다. 
File system은 계층으로 구성되어 있다. 
 
<Access Methods>
[참고] n : relative block number
(1) Sequential Access : 예전에 썼던 방법

(2) Direct Access : 요즘 사용하는 방법

 
 

2. File Management

 
<File Management>
File : 이름이 지정된, 순서대로 정렬된 정보 모음. 
파일 관리자는 다음 방법들로 collention을 관리한다. 
-> 장치에 정보 저장, 블록 저장소를 logical view에 매핑, storage 할당/할당 취소, 파일 디렉토리 제공

 
<Layout of the file system on the physical media>
이거 !!!!!! 좀더 찾아보자....
 
<Record-Oriented Sequential Files>
파일 시스템에서 사용되는 파일 구조 중 하나.
레코드(record) 단위로 데이터를 저장하고, 순차적인 방식으로 액세스된다. 
각 레코드는 고정된 길이를 가지고 있으며, 파일의 시작부터 끝까지 연속적으로 저장되어 있다. 

fileID = open(fileName)
close(fileID)
getRecord(fileID, record)
putRecord(fileID, record)
seek(fileID, position)

 
<Indexed Sequential File>
우리가 직접 기록에 접근하기를 원할 때 사용할 수 있는 방법이다. 
파일에 index를 추가한다. 

fileID = open(fileName)
close(fileID)
getRecord(fileID, index)
index = putRecord(fileID, record)
deleteRecord(fileID, index)

search가 easy.

 
<More Abstract Files>
(1) Inverted files : 파일의 각 데이터에 대한 system index
(2) Databases : 더욱 정교한 인덱싱 메커니즘, DDL와 DML
    -> DDL과 DML은 관계형 데이터베이스에서 사용되는 SQL의 두 가지 범주이다. 

(3) Multimedia storage : record에 근본적으로 다른 유형이 포함됨, 엑세스 방법은 일반적이어야 한다. 
 
 

3. Directory Structure

 
<Directorty structure>
모든 파일들에 대한 정보를 포함하는 node(노드)의 collection
-> 디렉토리 구조와 파일이 모두 디스크에 있다. 
-> 두 구조의 백업은 tape에 보관된다. 
 
<Single-Level directory>
모든 파일이 한 개의 디렉토리 밑에 있는 개념
-> 같은 디렉토리에 모든 파일이 존재하므로 각 파일은 유일한 이름을 가져야 한다.
-> Naming problem(서로 다른 이름 사용해야 됨), Grouping problem(구별이 힘듦)

 
<Two-Level directory>
각 사용자는 자신만의 사용자 파일 디렉토리(UFD)를 가지고 있으며, UFD의 구조는 비슷하다. 
-> 사용자가 접속 시 시스템은 마스터 파일 디렉토리(MFD)를 먼저 탐색한다. 
-> MFD는 사용자 이름이나 계정 번호로 색인되어 있고, 각 항목은 그 사용자의 UFD를 가리킨다. 
-> 같은 이름 사용해도 된다. searching이 효과적이다. 그러나 파일 공유가 불가능하고, 여전히 No grouping.

 
<Tree-Structured Directories>
여러 단계로 확장하는 일반적인 방법의 임의의 높이를 갖는 트리 구조.
-> 가장 일반적인 디렉토리 구조이며, 사용자들이 자신의 subdirectory를 맘껏 만들 수 있게 한다.
-> binary tree일 경우, 파일 탐색이 어렵다. Too deep depth.
    binary tree가 아닐 경우, 탐색할 때 메모리 낭비가 많이 된다. (ex, 10개씩 막 link하며 탐색하는 경우)

 
 

4. File Allocation

 
<Contiguous Allocation>
각 파일은 Disk의 contiguous blocks(연속 블록 집합)을 차지한다.
-> 우리는 시작 위치, 길이만 알면 된다. 
-> random access이다. Allocation은 first fit 혹은 best fit으로 진행한다. 
-> 주기적인 압축이 필요하다. 
-> 단점 : 공간 낭비(동적 스토리지 할당문제), fragmentation(단편화) 문제, 적당한 길이의 블록 찾기 어려움
    파일 확장 불가(파일이 해당 크기를 초과하여 증가할 수 없다.)

 
<Linked Allocation>
각 파일은 디스크 블록의 linked list다.
뻥뻥 띄워서 저장해도 된다~~ 단지 주소만 제대로 link하자. 
-> 블록은 contiguous allocation 때와 다르게, 디스크의 모든 위치에 분산될 수 있다. 
-> 압축이 필요하지 않다. 
-> 단점 : sequential(순차) 및 랜덤 액세스 불량, 에러에 취약하다. 

 
<File Allocation Table(FAT)>
linked allocation 업그레이드 버전, table을 만들고 여기서 link가 발생하는 원리. 
Disk를 파티션으로 분할.
각 파티션에는 FAT가, 디렉토리에는 각 파일에 대한 FAT의 시작 구역 포인터가 있음.  
-> linked allocation보다 오류 발생 가능성이 낮다. 
-> 단점 : FAT가 커지므로 clustering, partitioning이 필요 -> 다른 문제 발생 가능성 있음

 
<Indexed Allocation>
FAT를 파일당 하나의 데이터 구조로 분할. 
(1) i-node 라고 하는 각 파일에 index disk block(인덱스 디스크 블록)을 할당한다.
(2) 디렉토리 항목이 해당 파일의 i-node를 가리키게 된다.  
(3) free list(빈 목록)은 비트 벡터로 유지한다. 
-> 단점 : 하나의 인덱스 파일이 가능한 모든 크기의 파일을 가리켜야 한다. 
    i-node는 고정된 크기이므로, 최대 파일 크기가 존재한다. 

 
<Multilevel Indexed Allocation>
i-node가 [파일을 가리키는 index blocks(인덱스 노드)]를 가리키도록 한다.
-> 2단계 또는 그 이상으로 확장될 수 있는 개념이다. 
-> 단점 : 작은 파일에도 액세스하려면 많은, 간접적인 작업이 필요하다. 

 
<Hybrid Indexed Allocation>
이 전의 두 개념을 결합한다. (작은 파일을 위한 두 개의 직접 포인터, 단일 간접, 하나의 이중 간접...)
p.59 이해하고 넘어가자

 
*파일 할당에 대한 간단한 정리 : https://zzsza.github.io/development/2018/08/02/file-allocation/ 
 
 

5. File : Common concepts

 
<Common concepts>
File들은 i-node로 표시된다.
Directory들은 특수 파일(dentries)이다. 
Device들은 특수 파일에 I/O로 액세스한다. 접근한다. 
 
<Inodes>
inode는 Type, Access rights, Owners, Timestamps, Size, Pointers to data block 등을 저장해둠.

 
<Directories>
tree hierarchy(트리 계층 구조)로 구성되어 있다. 
각각 파일과 디렉토리를 모두 포함할 수 있다. (디렉토리는.. 특수한 유형의 파일일 뿐이야..~~!)
-> 각 dentry는 파일 이름과 inode의 번호를 포함한다. 
-> kernel이 디텍토리 트리를 검색한다. 
-> 경로 이름을 i-node 번호로 변환한다. (?)

참고 : dentry의 의미, 역할

 
<In memory data structures..>
일반적으로, 성능상의 이유로 중요한 데이터 구조가 메모리에 저장된다. 결국 Disk에 다시 기록된다.
(Why?) 수명이 짧은 파일일 수 있다. or 편리성 및 효율성을 위해서일 수 있다. 
(+) 메인 메모리에도 파일 시스템을 올릴 수 있다. 
 
<Dealing with System Crashes>
버그, 교착 상태 또는 전원 장애로 인해 시스템이 충돌하는 경우도 있다. 
-> 파일 시스템은 매우 중요하므로, 파일 시스템을 정상적으로 유지하기 위해 주의해야 한다. 
-> UNIX fsck는 crash가 났을 때 복구해주는 software래요 ..!!
 
 

6. SSD(Solid State Drive)

 
<SSD>

 
<Over-Write in Flash Memory>
읽기와 쓰기에 시간 차이가 존재한다. 또한 erase에 은근 시간을 소모한다.
 -> 이를 해결하기 위해 block 단위로 한꺼번에 쓰고 지운다.

 
<FTL(Remapping algorithm)>

 
 
 
 
 
 
 
 
정리가 잘 되어 있는 사이트 : https://rebro.kr/181