• Ext4 File System
    : Extended File System
    : Ext2, Ex3 에 이은 리눅스의 최신 파일 시스템

    -> Ex2, Ex3에 비해 최대 지원 파일 크기, 디스크 할당 정책, 저널링, 단편화 해소 등 많은 부분 성능이 향상된 파일 시스템

    - 특징
     ■ 더 큰 파일 시스템과 파일 사이즈
      : 현재 Ext3는 최대 16Tib의 파일시스템 사이즈와 최대 2Tib의 파일 사이즈를 지원
      : Ext4는 48 비트 블록 주소 (48-bit block addressing)를 추가했고, 1EB(2^60)의 최대 파일 시스템 사이즈와 16Tib의 최대 파일 사이즈를 가짐
      -> 4KB x 2^48 = 1EB
      ∴ 왜 64비트가 아니고 48비트?
      : Ext4에 어드레스될 완벽하게 안정적인 48비트가 있기 전에 Ext4가 만들어졌기 때문에 어드레스 비트를 48로 제한할 필요가 있었음.

     ■ 서브 디렉토리 확장성
      : 서브 디렉토리들의 가능한 최대 수는 Ex3에 있는 싱글 디렉토리를 포함하여 32000인데 Ext4는 두배의 값까지 가질 수 있게 되어서 64000의 서브 디렉토리를 허용

     ■ 입출력 성능 향상

      : 익스텐트 (Extent)
      : 다중 블록 할당 (Multiblock allocation)
      : 지연 할당 (Delayed allocation)
     
     ■ 그 외 특징들
      : 저널링 체크섬 - Ext4 체크섬은 블록에 결함이나 붕괴가 있다면 그것을 알 수 있도록 해줌
      : Lager inodes - Ext3은 아이노드 크기를 변경하는 것을 지원 그러나 기본적인 아이노드 크기는 128바이트 -> Ext4는 기본적인 아이노드 크기를 256 바이트로 함
      : Inode reservation - 디렉토리가 만들어질 때 미래에 사용될 몇몇의 아이노드들을 예약하는 것으로 구성



  • Ext4 Partition
    - 파일 시스템 블록 구성
     : 블록 크기 - 1KB ~ 4KB (default 4KB)
     : 파일시스템을 구성하는 정보들은 각 block group에 분산
     : 파일을 저장할 때 특정 부분에 집중적으로 기록하여 하드디스크의 효율을 높이고자 함 (파일 단편화를 줄임)
     : Block group 당 최대 블록의 개수 (블록이 4KB로 가정)
      -> 4KB = 8(bits) x 4096 = 32,768 bits
      -> 32KB X 4KB = 128MB (block group의 최대 크기)
      -> 1024MB / 128MB = 80개 (1GB 일 때 80개의 그룹 생성)

     


      ■ Super Block

       : Super Block이 손상되면 전체 파일 시스템에 대한 정보를 잃기 때문에 Super block과 group descriptor table의 사본은 모든 block group에 저장
       : 각 block group의 첫 번째 block에 위치
       : 해당 파일 시스템 관련 정보 저장 [블록의 크기(1KB, 2KB, 4KB), 총 블록의 개수, 블록 그룹의 개수, Inode의 개수, 그룹 내의 블록/Inode의 개수]
       : $dumpe2fs /dev/sdb1

      ■ Group Descriptor Table
       : Super block 바로 다음 block에 위치
       : 각 Block Group을 관리하는 정보 저장[Block Bitmap의 블록 번호, inode Bitmap의 블록 번호, 첫 번째 inode Table Block의 블록 번호, 그룹 안에 있는 빈 블록 수, 그룹 안에 있는 inode 수, 그룹 안에 있는 빈 디렉토리 수)

      ■ Block bitmap
       : 이 블록에 속한 각 비트는 그룹 내에 있는 각 블록의 사용 상태를 나타냄
       : Block 크기가 4KByte면 4K*8개 블록의 사용 여부 표시
       

      ■ inode
       : inode (index node)
        - 파일에 대한 제어 정보 및 데이터 블록 포인터 저장
        - 모든 파일들과 디렉터리들은 각각 1개의 inode를 할당
       : inode bitmap
        이 블록에 속한 각 비트는 그룹 내에 있는 각 inode의 사용 상태를 나타냄
       : inode table
        - 각각의 i
    node에 대한 정보를 나타내는 inode descriptor로 구성
        - inode table은 Group Descriptor Table에 저장
        - inode 번호를 알면 inode가 속한 Group을 알 수 있음
         -> Block group = (inode - 1) / INODES_PER_GROUP
        
       : inode descriptor
        - Mode, Owner Info, Size, Timestamp
        - Blocks pointers array (파일의 실제 데이터가 저장된 위치)
        

    - 디렉토리 구조


    Blocks vs Pages
     : block는 OS에서 파일을 읽거나 쓰는 가장 작은 데이터의 단위
     : page는 몇몇 OS에서 block 대신 사용된다. page는 기본적으로 virtual block 이며, 4K나 2K로 고정된 크기를 가진다.
     => page는 고정된 크기를 가진 virtual block 
     : 왜 blocks 대신에 pages를 사용할까? - page는 다양한 storage 장치에서 프로세싱을 더 쉽게 만든다. 각각의 디바이스들은 서로 다른 크기의 블록크기를 지원한다. page는 이것을 OS 시스템에서 같은 크기의 page 사이즈로 다룰 수있도록 한다. 이것은 크기가 다른 모든 블록 사이즈들을 계산하고 다루는것 보다 효율적이다. 그래서 페이지는 하드웨어 드라이버와 OS 시스템의 sort of a middleman 역할을 한다.
     =
    > 페이지들이 적절한 블록으로 해석된다.
     : page, blocks 모두 data storage의 기본단위로 사용된다.

  • Ext4 Performance vs Ext3
     

  • Ext2,3 vs Ext4 메커니즘
    - 블록 매핑
     ■ Extent
      - 이전 파일 시스템의 단점
       : Ext3과 같은 유닉스 드라이버의 파일 시스템은 각각의 블록(파일의 데이터에 해당하여 사용되는)들의 트랙을 유지하기 위해 간접 블록 매핑 스키마를 사용
       -> 이것은 큰 파일에 대해서 비효율적이며 특히 큰 파일을 삭제하거나 절단 명령 동안에 비효율적. 왜냐하면 모든 싱글 블록 엔트리에 대한 매핑은 그것이 큰 파일(많은 블록들을 가지고 있는)에 해당할때 거대한 매핑을 필요로 하며 핸들이 느려짐

      - 연속 할당의 변형된 기법
      : 어느 정도의 연속된 공간만 초기에 할당
      : 그 양이 충분히 크지 않을 때. 추후 또 다른 연속된 공간을 익스텐트(extent)라고 부르는 단위로 할당
      : 파일 블록들의 위치는 위치와 블록 수, 다음 익스텐트의 첫 블록을 가리키는 포인터로 기록
      : Ext2,3 Indirect Block vs Ext4 Extent
           

         

     ■ 다중 블록 할당 (Multiblock Allocation)
       - 이전 파일 시스템의 단점
       : 새로운 데이터를 디스크로 쓸 필요가 생길 때, 블록 할당자(Block Allocator)는 데이터가 쓰여질 가용 공간을 결정
       : Ext2,3 블록 할당자는 오직 한번에 한 개의 블록(4KB)만 할당 할 수 있음
       - 만약 시스템이 100MB의 가용공간이 필요하다면 Ext2/3 블록 할당자는 25600번 (100MB = 25600 블록)의 블록 할당 호출을 하게 됨 -> 단일 블록만을 다루기 때문

       - Ext4의 다중 블록 할당
       : Ext4는 매 호출마다 싱글 블럭을 할당하는 대신에 많은 오버헤드를 피하기 위해서 한번의 호출로 많은 블록을 할당할 수 있는 다중 블록 할당자(multi block allocator)를 사용 

     ■ 지연 할당 (Delayed Allocation)
      - 이전 파일 시스템의 할당 정책
      : write() 연산의 경우, 파일 시스템 코드는 심지어 데이터가 디스크에 즉시 쓰여지고 있지 않더라도 이것을 일정한 시간동안 캐시에 유지한 채 즉시 데이터가 위치할 블록으로 할당
      : 이러한 접근은 단점 가짐. 가령 커지는 파일에 지속적으로 write() 연산을 할 때 데이터의 블록으로의 성공적인 write() 할당이 이루어지더라도 그 파일이 계속 커질 것이라는 것은 알지 못하기 때문

      - Ex4의 지연 할당
      : 파일이 캐시에 유지되어 있는 동안에는 그 파일이 실제로 디스크에 쓰여질 때 까지 블록으로의 할당을 지연시킴

     => 시너지 (Synergy)
      : Ext4의 Extent, Multi Allocation, Delayed Allocation은 서로의 특성과 함께 효율적으로 디스크 할당을 수행함
      1. 파일이 디스크에 쓰기를 마쳤을 때 생기는 많은 작업량은 extents로 인접한 블록으로의 할당이 준비
      2. multi block allocation에 의해 많은 작업량에 대한 큰 블록이 할당될 수 있음
      3. 지연된 할당은 위의 두 특성이 효율적으로 작동할 수 있도록 해줌

    - 저널링 [Journaling (Ext3.4)]
     : 시스템이 멈추거나 정전 등으로 꺼지는 경우
      -> 일관성 문제 발생
     : 부팅 시
      - e2fsck (fsck.ext2)를 이용한 일관성 검사
      - 파일 시스템을 마운트하는 시점에 검사 수행
      - 저장장치 내의 모든 inode와 비트맵 검사

     : 모든 저널 로그들은 트랜잭션 단위로 그룹화
     : 각각의 트랜잭션들은 시퀀스 번호를 부여받음
     : 저널 데이터
      - 각 트랜잭션을 관리할 수 있는 정보와 파일 시스템의 변경 내역에 대한 데이터를 가지고 있음
     : e2fsck
      - Commit 된 저널 데이터의 경우 정상 분류하여 해당 데이터들을 파일시스템에 기록
      - Commit 되지 않은 저널의 경우 완료되지 않은 데이터이므로 무시하고 넘어감

     ■ Journaling File System

       : 데이터베이스의 기본적인 특징들을 구현
        - Logging을 이용한 데이터 백업 체계
       : Journal 영역
        - 로그를 기록
        - Commit: 작업이 정상적으로 종료될 경우
        - Rollback: 비정상 종료일 경우 원래의 상태로 복구



  • read(), write() 시스템 콜 루틴


    - read() system call in file system
     

    - read() system call trace (출처 : 수원 삼성소프트웨어멤버십 송인주)
    ∴ 가정
     : 파라미터로 파일 디스크립터, 버퍼, size를 가지는 가장 일반적인 read() 시스템 콜
     : 장치 파일을 통한 읽기가 아닌 파일 시스템을 사용하는 데이터 읽기
     : 읽고자 하는 파일은 이미 open() 되었음
     : O_DIRECT 플래그를 주지 않았기 때문에 페이지 캐시에 접근
     : 페이지 캐시에 read 하고자 하는 페이지가 없음 -> 블록 I/O 요청을 발생시킴
     : 디스크 파일 시스템은 Ext4
     : 디스크는 SCSI Disk Device를 사용
     -> 그러므로 블록 I/O 처리 시 로드되는 디바이스 드라이버는 SCSI 디바이스 드라이버







    - write() system call trace


'Major > Linux' 카테고리의 다른 글

리눅스 - 디바이스 드라이버  (2) 2016.02.15
리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (7) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
  • VFS(Virtual File System)



  • VFS의 역할 및 구조


    - VFS가 지원하는 파일 시스템
      디스크 기반 파일 시스템
      : 로컬 디스크 파티션의 기억 장소 또는 디스크를 흉내내는 몇 가지 다른 장치(USB 플래시 드라이브 같은)를 관리
      : Ext2, Ext3, Ext4, MS-DOS, FAT, NTFS, SYSV 등
      네트워크 파일 시스템
      : 네트워크로 연결된 다른 컴퓨터의 파일 시스템을 쉽게 접근가능하게 함
      : NFS(Network File System), AFS(앤드류 파일 시슽엠) 등
       
     ■ 특수 파일 시스템
      : /proc 파일 시스템, /tmp 파일 시스템 등
      

  • VFS 메커니즘
    - 공통 파일 모델 (Common File Model)

     : VFS의 핵심 개념은 지원하는 모든 파일 시스템을 표현할 수 있는 공통 파일 모델을 도입 하는 것
     : 각각의 특정 파일 시스템을 구현 하려면 반드시 자신의 물리적인 구성을 VFS의 공통 모델로 변환해야 함
     -> 예를 들어 몇몇 비 유닉스 계열의 디스크 기반 파일 시스템은 각 파일의 위치를 저장한 파일 할당 테이블(FAT)를 사용 -> 이런 파일 시스템에서 디렉토리는 파일이 아님
     -> VFS의 공통 파일 모델을 따르도록 하기 위해 실행 중에 디렉토리에 대응 하는 파일을 생성, 이렇게 생성한 파일을 커널 메모리 객체에 만듦
     => 공통 파일 모델을 구현하기 위한 자료구조(object)
       : 슈퍼 블록 객체, 아이노드 객체, 파일 객체, 디엔트리 객체

    - 프로세스와 VFS 객체의 상호작용
     

    - 공통 파일 모델 객체
     ■ 슈퍼 블록 객체
      : 마운트 된 파일 시스템에 대한 정보를 저장, 전체 파일 시스템을 나타냄
     ■ 아이노드 객체
      : 특정 파일에 대한 일반 정보를 저장. 디스크에 저장한 파일 제어 블록 (FCB, 리눅스에서는 아이노드)에 대응, 각 아이노드 객체에는 아이노드 번호가 할당)
     ■ 파일 객체
      : 열린 파일과 프로세스 사이의 상호 작용과 관련한 정보를 저장. 각 프로세스가 열린 파일을 가지는 동안 커널 메모리에만 존재
     ■ 디엔트리 객체
      : 디렉토리 항목(특정 파일 이름과 아이노드)과 이에 대응하는 파일의 연결에 대한 정보를 저장.

    - VFS 디엔트리 캐시

     : 가장 최근에 사용한 디엔트리 객체를 저장하는 디스크 캐시

     ∴ 디스크 캐시?
      : 보통 디스크에 저장하는 정보 중 일부를 램에 저장하여 이후 정보에 접근할때 더 느린 디스크에 접근하지 않고 빨리 처리하도록 하는 소프트웨어 메커니즘
      : 이렇게 함으로써 파일 경로명을 공려명의 마지막 구성요소인 파일 아이노드로 변환하는 속도를 높임

     ∴ 리눅스의 디스크캐시

      : 디엔트리 캐시, 아이노드 캐시, 페이지 캐시

    - VFS의 시스템 콜 처리 루틴
     

     : 애플리케이션이 read() 시스템 콜 호출 -> 커널은 해당하는 sys read() 호출
     : 커널 메모리 안에 있는 파일 객체의 f op 필드에 타겟 파일 시스템의 해당 함수 처리 루틴이 포인터로 존재
     : read() -> sys_read() -> vfs_read() -> (file->f_op) -> MS-DOS read()

      ■ open() 시스템 콜 메커니즘

       : open() 시스템 콜 -> sys_open() 시스템 콜이 성공하면 파일 객체에 대한 포인터 배열인 current->files->fd 의 인덱스를 반환
       : sys_open() 함수의 동작
       ① fd 반환

       ② 파일 객체의 주소 반환

       ③ f_op 필드를 대응하는 아이노드 객체의 i_fop 필드 내용으로 설정 -> 파일 연산을 위한 메소드 설정 종료

       ④ 탐색된 디엔트리 객체와 마운트된 파일 시스템 객체 등으로 파일 객체 할당

       ⑤ 접근 모드 플래그를 매개변수로 경로명 탐색 시작

       ⑥ 빈 파일 디스크립터 번호를 지역 변수에 저장

       ⑦ 프로세스 주소 공간에서 파일 경로명을 읽음

     

    - VFS가 처리하는 시스템 콜
     



'Major > Linux' 카테고리의 다른 글

리눅스 - 디바이스 드라이버  (2) 2016.02.15
리눅스 - Ext4 File System  (0) 2016.02.01
리눅스 - 파일 디스크립터  (7) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28

File Descriptor (파일 디스크립터) [출처: http://dev.plusblog.co.kr/22]


1. 파일 디스크립터

- 시스템으로부터 할당 받은 파일을 대표하는 0이 아닌 정수 값

- 프로세스에서 열린 파일의 목록을 관리하는 테이블의 인덱스



흔히 유닉스 시스템에서 모든 것은 파일이라고 한다. 일반적인 정규파일(Regular File)에서부터 디렉토리(Directory), 소켓(Socket), 파이프(PIPE), 블록 디바이스, 캐릭터 디바이스 등등 모든 객체들은 파일로써 관리된다. 유닉스 시스템에서 프로세스가 이 파일들을 접근할 때에 파일 디스크립터(File Descriptor)라는 개념을 이용한다.


파일 디스크립터는 '0이 아닌 정수', 'Non-negative Integer' 값이다. 즉, 음수가 아닌 0과 양수인 정수 값을 갖는다. (unsigned int 값이라고 보면 된다.) 프로세스가 실행 중에 파일을 Open 하면 커널은 해당 프로세스의 파일 디스크립터 숫자 중에 사용하지 않는 가장 작은 값을 할당해 준다. 그 다음 프로세스가 열려있는 파일에 시스템 콜을 이용해서 접근 할 때, FD 값을 이용해 파일을 지칭 할 수 있다. 


프로그램이 프로세스로 메모리에서 실행을 시작 할 때, 기본적으로 할당되는 파일 디스크립터들이 있다. 바로 표준 입력(Standard Input), 표준 출력(Standard Output), 표준 에러(Standard Error)이다. 이 들에게 각각 0, 1, 2 라는 정수가 할당되며, POSIX 표준에서는 STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO로 참조된다. 이 매크로는 <unistd.h> 헤더 파일에서 찾아 볼 수 있다. 

0이 아닌 정수로 표현되는 파일 디스크립터는 0 ~ OPEN_MAX 까지의 값을 가질 수 있으며, OPEN_MAX 값은 플랫폼에 따라 다르다.






파일 디스크립터는 위 그림을 보면서 개념 정리를 하면 좋다. 파일 디스크립터가 단순히 숫자인 이유는 프로세스가 유지하고 있는 FD 테이블의 인덱스이기 때문이다. FD 3번이라는 의미는 FD 테이블의 3번 항목이 가리키는 파일이라는 의미이다. FD 테이블의 각 항목은 FD 플래그와 파일 테이블로의 포인터를 가지고 있다. 이 포인터를 이용하여 FD 를 통해 시스템의 파일을 참조 할 수 있는 것이다.

프로세스는 이런 FD 테이블과 파일 테이블의 정보를 직접 고칠 수 없으며, 반드시 커널을 통해서 수정을 해야 한다.

파일 디스크립터란 뭔가?! [출처: http://z-man.tistory.com/151]

파일 디스크립터는 파이프, FIFO, 소켓, 터미널, 디바이스, 일반파일 등 종류에 상관없이 모든 열려있는 파일을 참조할때 쓴다.

파일디스크립터 

목적 

POSIX 이름 

stdio 스트림 

 0

 표준 입력

 STDIN_FILENO

 stdin

 1

 표준 출력

 STDOUT_FILENO

 stdout

 2

 표준 에러

 STDERR_FILENO

 stderr

 

표에 있는 3가지 디스크립터는 프로그램이 시작할때 셸의 디스크립터의 복사본을 상속 받고, 셸은 보통 3가지 파일 디스크립터가 언제나 열린채로 동작 한다.

프로그램에서 파일 디스크립터를 참조할때는 번호(0,1,2)를 쓸 수도 있지만 가능하면 "UNISTD.H"에 정의된 POSIX 이름을 쓰는편이 좋다..

 

1
2
3
4
5
6
7
8
fd = open( pathname, flags, mode )
// pathname 이 가리키는 파일을 열고 열린 파일을 이후 호출에서 참조 할 때 쓸 파일 디스크립터를 리턴.
// flags는 파일을 읽기, 쓰기, 둘다를 위해 열지를 지정 한다.
numread = read( fd, buffer, count )
// fd가 가리키는 파일에서 최대 count 바이트를 읽어 buffer에 저장.
numwritten = write( fd, buffer, count )
// 버퍼에서 최대 count 바이트를 fd가 가리키는 열려 있는 파일에 쓴다.
status = close(fd) 모든 i/o 를 마친뒤 fd와 관련 커널 자원을 해제 한다.

fd는 해당 프로세스의 open file 을 관리하는 구조체 배열의 index.

그 구조체의 index 가 가리키는 객체가 dentry 라는 객체이고, 그 dentry 객체는 또다시 해당 파일을 나타내는 inode 객체를 가리키게 됩니다.

커널 구조체중 struct files_struct 보시면 struct file fd_array 라는 배열이 있다.
실제로 open()을 통해 얻는 fd 는 저 구조체의 index 를 나타냅니다.

일반적으로 0, 1, 2 index 는 std-in/std-out/error 와 관련된 fd 로 미리 할당이되고, 보통 open()을 하게 되면 fd 값은 3이 됩니다.

3 번 index 로 test.txt 를 찾는 방법은 
우선 fd_array[3] 이 pointing 하고 있는 file 구조체의 f_dentry 를 얻어오게됩니다. dentry 란 것은 directory entry 를 의미하는데, 리눅스에서 디렉토리에 접근을 빠르게 하기 위한 구조체로 사용하고 있습니다. open() 시스템 콜을 호출하게 되면, test.txt 가 존재하는 위치와 관련되어 dentry 구조체가 만들어집니다.

dentry 구조체는 관련된 inode 구조체를 가리키는 필드를 포함합니다.
따라서 open("test.txt',...) 함수로 호출된 파일은 test.txt 에 대한 dentry 생성, inode 생성(또는 읽음) 후에 해당 프로세스의 open 파일 관리 구조체인 files_struct 의 fd_array 의 비어있는 위치에 test.txt 의 dentry 를 포인팅하고 그 index 인 3을 넘겨주는 것입니다.

이후 사용자가 3번을 가지고 시스템 콜을 수행하게되면, 해당 프로세스의 files_struct 의 fd_array index 를 통해서 관련 inode에 접근할 수 있게 되는 것입니다.

 

파일 디스크립터와 열려 있는 파일의 관계

각 프로세스별로 커널은 open file descriptor table 을 갖고 있다. 테이블의 각 엔트리는 하나의 파일 디스크립터에 대한 동작 제어 플래그, 열린 파일을 가리키는 참조를 담고 있다.

open file description은 현재 파일의 offset, flag, 접근 모드, i/o 관련 설정, 파일의 i-node 객체를 가리키는 레퍼런스를 갖고 있다.

i-node는 파일 종류 (일반파일, 소켓, fifo)와 권한, lock 목록 포인터, 여러 파일 오퍼레이션과 다양한 파일 속성(크기, 타임스탬프등)을 갖고 있다.

만약 같은 open file description을 가리키는 2개의 fd는 offset값을 공유 한다.

'Major > Linux' 카테고리의 다른 글

리눅스 - Ext4 File System  (0) 2016.02.01
리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
리눅스 - 기초  (0) 2016.01.28

+ Recent posts