• 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
리눅스 - Ext4 File System  (0) 2016.02.01
리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (6) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28

+ Recent posts