과제/LG/2013/황세영 분석자료

황세영

2014-03-31

날짜별로 절로 표기해야 수정하기 좋단다. 이처럼 절로 표기하거라.

• 컴공과세미나자료(zip)
• 리눅스커널READ부분(hwp) / 리눅스커널READ부분(pdf) - PDF로 올려야 읽을 수 있다.
  • 컴공과세미나자료의 '리눅스 커널 구조 분석' 자료에 나온 READ부분 함수를 모두 정리해둔 것
  • 각 함수의 시작 바로 전 괄호는 커널에서의 위치를 나타냄
• vfs_read (소스 테스트)

// Virtual File System
// fs/read_write.c
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos){
   ssize_t ret;
 
   if (!(file->f_mode & FMODE_READ))
      return -EBADF;
   if (!file->f_op || (!file->f_op->read && !file->f_op->aio_read))
      return -EINVAL;
   if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))
      return -EFAULT;
 
   ret = rw_verify_area(READ, file, pos, count);
   if (ret >= 0) {
      count = ret;
      if (file->f_op->read)   // read에 해당하는 'ext4 파일 연산 함수 테이블'의 함수는 do_sync_read
         ret = file->f_op->read(file, buf, count, pos);
      else
         ret = do_sync_read(file, buf, count, pos);
      if (ret > 0) {
         fsnotify_access(file);
         add_rchar(current, ret);
      }
         inc_syscr(current);
      }
      return ret;
}

2014-04-02

• The Virtual Filesystem (가상 파일시스템)
  • =Virtual File Switch, VFS
  • 리눅스는 가상 파일시스템을 사용하여 다양한 디스크 유형을 지원
  • 커널의 서브시스템으로, 표준 유닉스 파일시스템과 관련한 모든 시스템 콜을 처리하는 커널 소프트웨어 계층
  • 모든 파일시스템들은 VFS을 필요로 하며, VFS는 여러 종류의 파일시스템에 대해 공통 인터페이스를 제공
  • 지원하는 모든 파일시스템을 표현할 수 있는 공통 파일 모델 도입
    • 각각에 해당하는 특정 파일시스템을 구현할 때는 반드시 자신의 물리적인 구성을 VFS의 공통 파일 모델로 변환해야 함
  • 예를들어 파일은 커널 메모리에서 file로 자료 구조를 표현함. file 내부에는 f_op라는 함수 포인터가 있고, 그 중 read가 있으며, 파일 시스템의 실제 함수에 대한 포인터에 해당함.
    • 따라서 file->f_op->read(..)와 같은 형태로 모든 파일 시스템에 대한 read 함수를 호출 가능.
  • 위와 같은 공통 파일 모델(file)은 객체 지향적인 방식을 사용했지만, 성능 향상을 위해 객체 지향 언어를 사용하지 않음.
    • 구조체에 변수와 함수 구조체에 대한 포인터를 둠. 일반적으로 함수 구조체에 대한 포인터는 'op'로 표현
    • 함수 구조체는 실제 구현되어 있는 함수로 연결됨.
    • 예를들어 ext4 파일 시스템에서 file->f_op->read(..)는 실제로는 do_sync_read함수를 호출
  • VFS는 독자적으로 저수준 프로시저를 호출하지 않고 파일 연산을 실행할 수 있음. 따라서 필요하다면 특정 파일시스템에 의존하는 '일반' 파일시스템으로 볼 수도 있음
    • 예를들어 프로세스가 열린 파일을 닫으려 할 때는 디스크 파일을 건드리지 않고 VFS에 대응하는 파일 객체를 해제함
• 공통 파일 모델(file)
  • 공통 파일 모델은 수퍼블록 객체, 아이노드 객체, 파일 객체, 디엔트리 객체로 나뉨
  • 수퍼블록 객체 : 마운트시킨 파일시스템 정보를 저장하며 file 구조체에서 필드명은 대부분 's_'로 시작.
  • 아이노드 객체 : 특정 파일에 대한 일반 정보를 저장. 아이노드 번호는 파일시스템 내 각 파일을 유일하게 식별함. file 구조체에서 필드명은 대부분 'i_'로 시작
  • 파일 객체 : 열린 파일과 프로세스 사이의 상호 작용과 관련한 정보를 저장. file 구조체에서 필드명은 대부분 'f_'로 시작
  • 디엔트리 객체 : 디렉토리 항목과 대응하는 파일간 연결에 대한 정보를 저장. file 구조체에서 필드명은 'd_'로 시작
• 리눅스커널READ부분_위치정리(xlsx)
  • 2014-03-31에 올린 '리눅스커널READ부분'에서 함수의 위치만 정리한 액셀 파일
• SYSCALL_DEFINE3_분석(pdf)

2014-04-07

• 140407_커널분석(pdf)
  • vfs_read부터 generic_make_request 까지
    • bio 구조와 requst queue의 구조 및 이들의 동작방법을 자세히 파악하는 것이 중요하다. 꼼꼼히 코드를 읽어보기 바란다.

2014-04-16

• 140416_커널분석(pdf)
  • blk_init_queue부터 __blk_run_queue_uncond 까지
• 이하 bio 구조와 request queue의 구조 및 이들의 동작방법을 파악하는 것이 중요하다고 하셔서 블록 장치의 동작 방식에 대한 정리를 추가합니다.
  • 위의 커널분석은 이 내용을 따로 정리하기 전에 적어둔 것이라 포함되어 있지 않습니다. 다음 번에 올릴 때 이 내용도 추가해 두겠습니다.
• 블록 장치 : 일정 크기(블록) 단위로 접근하는 장치로 대표적인 예로 하드 디스크
  • 블록 장치는 파일 시스템에 의해 간접적으로 접근하게 되어 있으며 VFS에 의해 어떤 파일 시스템이라도 관계없이 같은 방식으로 이용
• 블록IO의 시작 지점은 submit_bio()로, 인자로 READ or WRITE와 bio 구조체를 받음.
  • READ : 디스크에 저장된 데이터를 메모리로 옮김, WRITE : 메모리에 저장된 데이터를 디스크로 옮김
  • bio는 해당 연산에 대한 모든 정보를 포함하는 구조체로써, IO를 수행할 디스크 영역의 정보와 IO를 수행할 메모리 영역의 정보를 포함
  • 현재 bio는 세그먼트를 bio_vec 구조체를 통해 저장
    • 세그먼트는 기본적으로 페이지의 형태로 저장되므로 이에 대한 모든 정보가 포함하며 장치가 한 IO당 여러 세그먼트를 지원할 수 있으므로 이를 벡터(배열) 형태로 저장
    • BIO 구조체 하나가 BIO_VEC 구조체를 배열로 관리하며 여러곳에 흩어진 블록들을 관리하여 IO연산을 수행 (scatter-gather I/O)
    • bio구조체관계(jpg)
      • bio구조체와 bio_vec구조체, 세그먼트의 관계 (출처 : http://blog.naver.com/kkn2988?Redirect=Log&logNo=141641230)
  • struct bio 필드
    • bi_sector : 디스크 상의 연관된 섹터 주소
    • bi_next : request 큐 리스트
    • bi_bdev : 연관된 블록 디바이스
    • bi_flags : 상태, 명령 플래그
    • bi_rw : 하위 비트는 읽기/쓰기, 상위 비트는 우선순위
    • bi_vcnt : bi_io_vec 리스트 길이(개수)
    • bi_idx : bi_io_vec의 현재 인덱스
    • bi_phys_segments : 물리 주소를 병합한 이후의 세그먼트 개수
    • bi_size : 남은 I/O 개수
    • bi_seg_front_size : 합칠 수 있는 첫 세그먼트 크기
    • bi_seg_back_size : 합칠 수 있는 마지막 세그먼트 크기
    • bi_max_vecs : 가능한 bi_io_vec 리스트의 최대 길이
    • bi_comp_cpu : 완료된 CPU
    • bi_cnt : 사용 빈도수
    • bi_io_vec : bi_io_vec 리스트
    • bi_end_io : I/O 완료 함수포인터
    • bi_private : 소유자의 사적인 메소드
    • bi_destructor : 소멸자 메소드
    • bi_inline_vecs[0] : 내부적으로 메모리 할당시 사용되는 bi_io_vec 배열
  • struct bio_vec 필드
    • bv_page : 해당 버퍼가 놓여있는 물리적인 페이지로의 포인터
    • bv_len : 이 버퍼의 바이트 길이
    • bv_offset : 페이지 내에서의 버퍼의 위치(바이트 오프셋)
  • bio는 디스크 상에서 연속된 영역 만을 나타낼 수 있음. 따라서 접근하려는 데이터가 디스크 상에서 여러 부분으로 나뉘어 있다면 각각에 해당되는 bio가 할당되어 submit_bio()함수를 통해 각각 전달됨
• request 구조체는 블록 디바이스의 블록 IO 요청을 정의하며, request_queue는 각각의 블록 IO 요청을 담고 있음
• request_queue(jpg)
  • request_queue와 request 그리고 bio의 관계 (출처 : http://blog.naver.com/kkn2988?Redirect=Log&logNo=141641230)

※

2014-04-26

• OPEN 과정(hwp)
• WRITE 과정(hwp)
• 분석(pptx)

2014-04-26

• 분석(pptx)

2014-05-02

• 디바이스드라이버정리(docx)

2014-05-09

• 디바이스드라이버정리(pdf)

2014-05-12

• 디바이스드라이버정리(pdf)
  • 이미지에 사용 struct를 추가
• SYTest, plantuml test
  • 포함struct리스트(txt)

2014-05-15

• 1차 미팅
  • I/O요청 처리 과정(pptx)
• 2차 미팅
  • I/O요청 처리 과정_2차(pptx)
    • bio_reqeust_requestqueue

2014-05-19

• 140519통합자료(pptx)
• 140519통합자료(축약)(pptx)

2014-05-20

• 140520통합자료_축약, 황세영부분)(pptx)
• 140520통합자료_축약(건우,세영 부분)(pptx)
• 140520통합자료_축약_v2(건우,세영 부분)(pptx)
• 140520통합자료_축약_v3(건우,세영,희영 전체)(pptx)
• 140520통합자료_축약_v4(건우,세영,희영 전체)(pptx)

2014-05-30

• Page Cache LRU 관련
  • PAGE_CACHE_DIAGRAM
  • Page_cache_관련함수(hwp) // Page_cache_관련함수(pdf)
  • 관련사이트(현재와 맞지 않음) : [1][2]

2014-06-12

Write 분석(pptx)

2014-07-14

• Read 과정(docx) / Read 과정(pdf)
• bio 처리 과정(docx) / bio 처리 과정(pdf)
• 페이지 교체 알고리즘(docx) / 페이지 교체 알고리즘(pdf)
• Open 과정(hwp) / Open 과정(pdf)