gzip

압축하기 gzip cvs.pdf
압축풀기 gzip -d cvs.pdf.gz 또는 gunzip cvs.pdf.gz



bzip2

압축하기 bzip2   cvs.pdf
압축풀기 bzip2   -d   cvs.pdf.bz2    또는   bunzip2 cvs.pdf.bz2

 

tar로 묶어서 gzip으로 압축된 파일 풀기

가장 많이 사용되는 형식이다. 이렇게 압축된 파일은 tar.gz 또는 tgz 과 같은 확장자 형식을 지니며 아래와 같이 간편하게 풀 수 있다.

tar  xvfz  test.tar.gz

tar로 묶고 bzip2로 압축된 파일은 tar.bz2 와 같은 확장자 형식을 가지며 다음과 같이하여 푼다.

tar  xvfj   test.tar.bz2

 


출처 : http://ssulsamo.egloos.com/3050850



*압축하기
tar [옵션] [압축 파일 이름] [압축하고자 하는 파일 or 디렉토리]
tar cvf test.tar test

*압축풀기
tar [옵션] [압축 파일 이름]
tar xvf test.tar



*tar.gz
tar는 압축을 하는 툴이 아니다 단지 여러개의 파일을 하나의 파일로 모아주기만 한다.
만약에 압축을 하고 싶으면 옵션에 z를 넣고 파일 이름에 확장자를 tar.gz로 한다. (그냥 tar로 해도 상관은 없다..)
-z옵션은 GNU tar에서만 제공하는 기능이다. (리눅스는 GNU tar를 사용한다)

 - 압축하기
    
tar zcvf test.tar.gz test

 - 압축풀기
    tar zxvf test.tar.gz


'Embedded Lab > linux, x86' 카테고리의 다른 글

[grub 배경화면 변경]  (0) 2013.08.04
[리눅스에서 itoa는 사용 불가]  (0) 2013.04.14
[blktrace 포맷을 disksim 포맷으로]  (0) 2013.04.08
[blktrace 설치법]  (0) 2013.04.08
[blktrace 사용법]  (0) 2013.04.08
Posted by cyj4369
,

- sudo blktrace -d /dev/sda5 -a complete -o - |  blkparse -f "%5T.%9t 0 %8S %9n %3d \n" -i - -o out.txt 로 입력해서 파일로 저장한다

T.t =  I/O들어오는시간, D = Device Number,  S =  Sector Number, n = Sector를 몇개 쓸것인지(record size),  d =Read/Write

① blktrace로 trace를 추출


② trace추출 후 disksim형태로의 변환
    -blktrace에서 I/O들어오는 시간을 ns로 표현하는데
      disksim에서는 ms로 바꿔서 설정해야된다
    - Read = 0, Write = 1로 바꿔준다

윈도우나 리눅스 인스톨은 VirtualBox에서 가상 windows7설치를 실행하는 동안에 blktrace 실행

출처 : http://dmclab.hanyang.ac.kr/tc/younjunsik/entry/20105-10-작업일지

'Embedded Lab > linux, x86' 카테고리의 다른 글

[리눅스에서 itoa는 사용 불가]  (0) 2013.04.14
[gz 또는 bz2 압축하기/풀기]  (0) 2013.04.13
[blktrace 설치법]  (0) 2013.04.08
[blktrace 사용법]  (0) 2013.04.08
[blktrace2]  (0) 2013.04.08
Posted by cyj4369
,

block trace 란 리눅스에서 Disk I/O 가 일어날때,
linux 하위 level 에서 어떻게 Block 단위의 I/O 가 일어났는지 알아낼수 있는 Tool 
DB 접근에서 주로 DB recovery 나 join 시의 DIsk I/O 패턴을 알아내는데 유용하다. 

1. yum install blktrace-1.0.1-3.XX .. 를 인스톨 한다. ( block trace 뜨는 프로그램 )
http://rpm.pbone.net/index.php3/stat/3/srodzaj/1/search/blktrace 


2. seekwatcher 다운로드 ( 생성한 block trace 를 image 로 정리해서 보여줌 ) 
   - 미리 설치할 package : http://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-0.99.1/matplotlib-0.99.1.2.tar.gz/download 
 
   - seekwatcher http://oss.oracle.com/~mason/seekwatcher/seekwatcher-0.12.tar.bz2  

3. seekwatcher 압출을 풀면 seekwatcher 란 실행파일이 생성 됨 이 파일을 /usr/bin 에 복사후 사용

blktrace 실행


1. mkdir /trace 
2. blktrace -d /dev/target_device 
3. cd /trace 에 device_name.blktrace 파일이 생성 된다.

seekwatcher 실행


seekwatcher  -t trace파일 


exception


 

/usr/lib/python2.6/site-packages/matplotlib/rcsetup.py:117: UserWarning: rcParams key "numerix" is obsolete and has no effect;
 please delete it from your matplotlibrc file
  warnings.warn('rcParams key "numerix" is obsolete and has no effect;\n'
   

  cd $HOME
  rm .matplotlib/



[root@ljh8324-skku /]# blktrace -d /dev/sdb1
Invalid debug path /sys/kernel/debug: 0/Success 

$ mount -t debugfs debugfs /sys/kernel/debug

'Embedded Lab > linux, x86' 카테고리의 다른 글

[gz 또는 bz2 압축하기/풀기]  (0) 2013.04.13
[blktrace 포맷을 disksim 포맷으로]  (0) 2013.04.08
[blktrace 사용법]  (0) 2013.04.08
[blktrace2]  (0) 2013.04.08
[blktrace1]  (0) 2013.04.08
Posted by cyj4369
,

Usage 1)
blktrace /dev/sda /dev/sdc &
kill -15 pid
blkparse sda sdc > events
less events
 
 
 
Usage 2)
화면에서 실시간 확인시
blktrace [블록장치경로] -a complete -o - | blkparse -f “%d,%S,%n\n” -i -
 
Usage 3)
파일로 저장시
blktrace [블록장치경로] -a complete
blkparse -f “%d,%S,%n\n”-i [tracefile] > test.csv
 
 -f Output format. Customize the output format. The format field
   identifiers are:

%a - Action
%c - CPU ID
%C - Task command (process) name
%d - Direction (r/w)
%D - Device number
%e - Error number
%M - Major
%m - Minor
%N - Number of bytes
%n - Number of sectors
%p - PID
%P - PDU
%s - Sequence number
%S - Sector number
%t - Time (wallclock - nanoseconds)
%T - Time (wallclock - seconds)
%u - Time (processing - microseconds)
%U - Unplug depth
 

Default Output

The standard header (or initial fields displayed) include:

"%D %2c %8s %5T.%9t %5p %2a %3d"

Breaking this down:

%D
Displays the event's device major/minor as: %3d,%-3d.
%2c
CPU ID (2-character field).
%8s
Sequence number
%5T.%9t
5-character field for the seconds portion of the time stamp and a 9-character field for the nanoseconds in the time stamp.
%5p
5-character field for the process ID.
%2a
2-character field for one of the actions.
%3d
3-character field for the RWBS data.

Seeing this in action:

8,0 3 1 0.000000000 697 G W 223490 + 8 [kjournald]

The header is the data in this line up to the 223490 (starting block). The default output for all event types includes this header.

 

 
 
$ blktrace -d /dev/sda -o - | blkparse -i -
/sys/kernel/debug does not apper to be a debug filesyste

위와 같은 에러를 내면서 blktrace가 동작하지 않는다면, 



아래와 같이 해 준다.



$ mount -t debugfs debugfs /sys/kernel/debug

 

To launch automatically,

put this into /etc/fstab

 

debug /sys/kernel/debug debugfs default 0 0



출처 : http://blog.naver.com/PostView.nhn?blogId=go4real&logNo=89718340&redirect=Dlog&widgetTypeCall=true

'Embedded Lab > linux, x86' 카테고리의 다른 글

[blktrace 포맷을 disksim 포맷으로]  (0) 2013.04.08
[blktrace 설치법]  (0) 2013.04.08
[blktrace2]  (0) 2013.04.08
[blktrace1]  (0) 2013.04.08
[printk 로그 레벨]  (0) 2013.04.08
Posted by cyj4369
,

이전 글 보기:


지금까지 상위 (filesystem) 계층에서 요청된 I/O 연산이 bio를 거쳐 request로 만들어지는 과정을
살펴보았다. 이제 이렇게 생성된 request가 I/O 스케줄러 단에서 처리되는 방식을 알아볼 것이다.

앞서 살펴보았듯이 생성된 request는 대부분 (per-task) plugging 기능이 적용된 상태일 것이므로
(직접적인 read/write의 경우는 물론 read-ahead, writeback의 경우도 이에 해당한다)
I/O 스케줄러에게 전달되기에 앞서 plugged list에 잠시 보관된다.

plugging 기능을 사용하려면 해당 함수의 스택에 blk_plug 구조체를 할당하고
먼저 blk_start_plug() 함수를 호출한 후에 I/O 연산을 발생시키고
마지막으로 blk_finish_plug() 함수를 호출하면 된다.

blk_start_plug() 함수는 주어진 blk_plug 구조체를 적절히 초기화한 후에
현재 태스크의 plug 필드에 저장하는데, 만약 blk_start_plug() 함수가 중첩된 실행 경로 상에서
여러 번 호출되었다면 제일 첫 번째로 호출된 경우에만 plug 필드를 저장한다.
이는 plugging 로직이 가장 상위 수준에서 처리될 수 있도록 보장해 준다.

blk_finish_plug() 함수는 태스크의 plug 필드와 인자로 주어진 blk_plug 구조체가 일치하는 경우에만
동작하며, 대응하는 start 함수와 현재 finish 함수 사이에서 발생한 I/O 연산 (request)들을 모두
I/O 스케줄러에게 전달하고 (insert) 실제로 드라이버가 I/O를 실행하도록 한다.
request를 I/O 스케줄러에게 전달하는 방식은 request의 종류 및 상황에 따라 몇 가지 정책이 적용된다.

만약 plugged list에 request가 존재하는 상황에서 어떠한 이유로 인해 현재 태스크가 더 이상
실행되지 못하고 (자발적으로!) sleep 해야한다면 kblockd 스레드가 대신 plugged list를 넘겨받아
I/O 스케줄러에게 전달한 뒤에 I/O 연산을 실행한다.

plugged list 내의 request들이 I/O 스케줄러에게 전달되는 순간 다시 한번 merge가 가능한지
검사하게 되는데 이는 여러 태스크들이 동시에 디스크 상의 비슷한 위치에 접근하는 경우 각각의 태스크들은
자신의 plugged list에 포함되어 다른 태스크들은 접근하지 못하던 request들이 이제 공유되므로
새로이 merge될 가능성이 있기 때문이다. 이러한 정책은 ELEVATOR_INSERT_SORT_MERGE로 나타내며,
plugging 기법을 이용하지 않을 시에는 이러한 merge 시도를 할 필요가 없으므로
ELEVATOR_INSERT_SORT 정책이 사용된다.

I/O 스케줄러는 주어진 request들을 디스크 상의 위치에 따라 배열하여 seek time을 최소화하기 위해
노력하는데, 이 때 기본적으로 디스크의 헤드가 한 쪽 방향으로만 일정하게 움직이도록 하므로
이를 엘리베이터 (elevator)라고도 부른다. (물론 세부 동작은 각 I/O 스케줄러마다 다르다)

이를 위해서는 I/O 스케줄러 내부에 request들을 (잘 정렬하여) 보관할 자료구조가 필요한데
여기서는 rb tree (red-black tree)가 사용되며, 앞서 살펴보았듯이 (merge를 위해)
정렬된 rb tree 내의 특정 request를 빨리 찾아내기 위해 별도의 해시 테이블을 가지고 있다.
이렇게 rb tree 내에 보관된 request들은 REQ_SORTED라는 플래그를 추가하여 표시한다.

하지만 FLUSH/FUA request에 대해서는 약간 다른 ELEVATOR_INSERT_FLUSH 정책을 취하게 되는데
이러한 request들은 해당 디스크의 특성에 따라 다르게 처리될 수 있으며 또한 일반적인 merge를
지원하는 대신 중첩된 flush 요청을 한꺼번에 처리하는 기법을 사용하기 때문이다.

앞서 살펴보았듯이 FLUSH는 디스크 내부의 write-back 캐시의 내용을 실제 디스크에 저장하라는 의미이며
FUA는 write-back 캐시가 없는 것처럼 현재 데이터를 디스크에 직접 기록하라는 의미이다.
따라서 디스크가 내부 캐시를 가지지 않는 경우라면 FLUSH/FUA는 아무런 의미가 없다.
또한 캐시를 가진 디스크라고 하더라도 FUA 지원 여부는 선택적이므로 지원하지 않는 디스크의 경우
FUA request가 들어오면 이를 다시 FLUSH로 변경하여 처리하게 된다.

특히 FUA request의 경우 write할 데이터와 함께 요청되므로 최악(?)의 경우
하나의 (FLUSH & FUA) request는 다음과 같이 세 단계로 나누어 처리되어야 한다.

 (pre) FLUSH + WRITE + (post) FLUSH

따라서 FLUSH/FUA request는 REQ_FLUSH_SEQ 플래그를 추가하여 이러한 과정을 거치고 있음을 나타내며
이에 대한 추가적인 정보를 request 구조체 내의 flush (구조체) 필드에 저장하고 있다.

또한 이러한 request를 여러 태스크가 동시에 요청하는 경우 FLUSH 연산이 여러 차례 실행될 수 있으나
그 사이 데이터가 write 되지 않았다면 실질적으로 의미가 없으므로 (캐시 내의 모든 데이터가 이미 저장되었다)
이러한 중첩된 FLUSH 연산을 한 번만 수행해도 동일한 효과를 얻을 수 있게 될 것이다.

따라서 이러한 FLUSH/FUA request를 효율적으로 처리하기 위해 별도의 queue를 유지하며
총 2개의 리스트를 통해 하나의 FLUSH 요청이 실행되는 동안 발생된 FLUSH request들은 다른 리스트에
대기시키는 double buffering 방식을 이용하여 중첩된 request들을 한꺼번에 완료시키게 된다.

이렇게 I/O 스케줄러에게 전달된 request는 최종적으로 dispatch queue로 전달된다.
이렇게 전달된 request는 더 이상 merge될 수 없으므로 해시 테이블에서 제거되며 dispatch queue 내에서
디스크 섹터 번호를 기준으로 정렬된다 (단, 이미 처리 중이거나 REQ_SOFTBARRIER 플래그가 설정된
request들은 더 이상 정렬할 수 없으므로 그 이후의 request들만을 고려하게 된다).

dispatch queue 내의 request들은 순서대로 드라이버에 의해 처리되며
이렇게 request의 처리를 실제로 시작하는 것을 dispatch 혹은 issue라고 부른다.
dispatch된 request들은 REQ_STARTED 플래그를 추가로 설정하며 queue에서 제거되며
디스크 오류로 인해 request가 오랫동안 완료되지 못하는 경우를 방지하기 위해 타이머를 설정한다.

dispatch queue가 비게되면 드라이버는 I/O 스케줄러에게 새로운 request를 queue에 추가하도록 요청한다.
request가 더이상 존재하지 않거나 I/O 스케줄러가 dispatch queue로 전달하지 않으면 처리는 종료된다.

지금껏 블록 장치 I/O 연산이 전달되는 과정을 간략히 살펴보았는데
리눅스 커널의 블록 서브시스템 관리자이기도 한 Jens Axboe님이 만든 blktrace 도구를 이용하면
현재 시스템 내의 디스크 장치의 I/O 과정을 한 눈에 알아볼 수 있는 방법을 제공한다.

만일 기본적인 출력 내용을 터미널 상에서 확인하고 싶다면 단순히 btrace라는 스크립트를 이용할 수 있다.
그 외의 자세한 옵션은 blktrace 및 blkparse의 man 페이지를 참조하기 바란다.
아래는 내 시스템에서의 출력 내용 중 일부이다.

# btrace /dev/sda
  ...
  8,0    0       60    10.168088873   178  A  WS 353925552 + 8 <- (8,5) 46516656
  8,0    0       61    10.168089576   178  Q  WS 353925552 + 8 [jbd2/sda5-8]
  8,0    0       62    10.168097323   178  G  WS 353925552 + 8 [jbd2/sda5-8]
  8,0    0       63    10.168098432   178  P   N [jbd2/sda5-8]
  8,0    0       64    10.168100785   178  A  WS 353925560 + 8 <- (8,5) 46516664
  8,0    0       65    10.168101033   178  Q  WS 353925560 + 8 [jbd2/sda5-8]
  8,0    0       66    10.168102298   178  M  WS 353925560 + 8 [jbd2/sda5-8]
  8,0    0       67    10.168104627   178  A  WS 353925568 + 8 <- (8,5) 46516672
  8,0    0       68    10.168104843   178  Q  WS 353925568 + 8 [jbd2/sda5-8]
  8,0    0       69    10.168105513   178  M  WS 353925568 + 8 [jbd2/sda5-8]
  8,0    0       70    10.168106517   178  A  WS 353925576 + 8 <- (8,5) 46516680
  8,0    0       71    10.168106744   178  Q  WS 353925576 + 8 [jbd2/sda5-8]
  8,0    0       72    10.168107411   178  M  WS 353925576 + 8 [jbd2/sda5-8]
  8,0    0       73    10.168109205   178  A  WS 353925584 + 8 <- (8,5) 46516688
  8,0    0       74    10.168109435   178  Q  WS 353925584 + 8 [jbd2/sda5-8]
  8,0    0       75    10.168110081   178  M  WS 353925584 + 8 [jbd2/sda5-8]
  8,0    0       76    10.168111110   178  A  WS 353925592 + 8 <- (8,5) 46516696
  8,0    0       77    10.168111328   178  Q  WS 353925592 + 8 [jbd2/sda5-8]
  8,0    0       78    10.168111953   178  M  WS 353925592 + 8 [jbd2/sda5-8]
  8,0    0       79    10.168112970   178  A  WS 353925600 + 8 <- (8,5) 46516704
  8,0    0       80    10.168113266   178  Q  WS 353925600 + 8 [jbd2/sda5-8]
  8,0    0       81    10.168113923   178  M  WS 353925600 + 8 [jbd2/sda5-8]
  8,0    0       82    10.168115804   178  A  WS 353925608 + 8 <- (8,5) 46516712
  8,0    0       83    10.168116019   178  Q  WS 353925608 + 8 [jbd2/sda5-8]
  8,0    0       84    10.168116656   178  M  WS 353925608 + 8 [jbd2/sda5-8]
  8,0    0       85    10.168118495   178  A  WS 353925616 + 8 <- (8,5) 46516720
  8,0    0       86    10.168118722   178  Q  WS 353925616 + 8 [jbd2/sda5-8]
  8,0    0       87    10.168119371   178  M  WS 353925616 + 8 [jbd2/sda5-8]
  8,0    0       88    10.168121449   178  A  WS 353925624 + 8 <- (8,5) 46516728
  8,0    0       89    10.168121665   178  Q  WS 353925624 + 8 [jbd2/sda5-8]
  8,0    0       90    10.168122304   178  M  WS 353925624 + 8 [jbd2/sda5-8]
  8,0    0       91    10.168123327   178  A  WS 353925632 + 8 <- (8,5) 46516736
  8,0    0       92    10.168123554   178  Q  WS 353925632 + 8 [jbd2/sda5-8]
  8,0    0       93    10.168124212   178  M  WS 353925632 + 8 [jbd2/sda5-8]
  8,0    0       94    10.168125241   178  A  WS 353925640 + 8 <- (8,5) 46516744
  8,0    0       95    10.168125462   178  Q  WS 353925640 + 8 [jbd2/sda5-8]
  8,0    0       96    10.168126087   178  M  WS 353925640 + 8 [jbd2/sda5-8]
  8,0    0       97    10.168128954   178  I  WS 353925552 + 96 [jbd2/sda5-8]
  8,0    0        0    10.168131125     0  m   N cfq178 insert_request
  8,0    0        0    10.168131926     0  m   N cfq178 add_to_rr
  8,0    0       98    10.168133660   178  U   N [jbd2/sda5-8] 1
  8,0    0        0    10.168135051     0  m   N cfq workload slice:100
  8,0    0        0    10.168136148     0  m   N cfq178 set_active wl_prio:0 wl_type:1
  8,0    0        0    10.168136908     0  m   N cfq178 Not idling. st->count:1
  8,0    0        0    10.168138014     0  m   N cfq178 fifo=          (null)
  8,0    0        0    10.168138615     0  m   N cfq178 dispatch_insert
  8,0    0        0    10.168139739     0  m   N cfq178 dispatched a request
  8,0    0        0    10.168140355     0  m   N cfq178 activate rq, drv=1
  8,0    0       99    10.168140588   178  D  WS 353925552 + 96 [jbd2/sda5-8]
  8,0    0      100    10.168534375     0  C  WS 353925552 + 96 [0]
  8,0    0        0    10.168554570     0  m   N cfq178 complete rqnoidle 1
  8,0    0        0    10.168555455     0  m   N cfq178 set_slice=120
  8,0    0        0    10.168556271     0  m   N cfq178 Not idling. st->count:1
  8,0    0        0    10.168556774     0  m   N cfq schedule dispatch
  ...

여기서 주의깊게 봐야할 부분은 알파벳 약자로 이루어진 6번째와 7번째 열 부분이다.
6번째 열이 나타내는 것은 해당 request가 처리되는 과정을 나타내며 (아래에서 설명)
7번째 열이 나타내는 것은 request의 종류로 여기서 WS는 sync write, N은 none에 해당한다.

6번째 열을 자세히 살펴보면 약간의 규칙성을 발견할 수 있는데 (첫번째 request는 제외)
먼저 A는 remap의 약자로 (8,5) 즉 /dev/sda5 파티션에 대한 I/O가
/dev/sda 디스크 전체에 대한 위치로 변환된 것을 뜻한다.
다음은 Q인데 이것은 queue의 약자로 make_request_fn이 실행되어 bio의 처리가 시작되었음을 뜻한다.
다음은 G인데 이것은 get (request)의 약자로 request 구조체가 하나 할당되었음을 뜻한다.
다음은 P인데 이것은 plug의 약자로 request가 plugged list에 포함되었음을 뜻한다.

이후의 요청들은 모두 A -> Q -> M의 과정을 거치는데, A와 Q는 위와 동일하고
M은 merge의 약자로 요청된 bio가 (앞선) request와 통합되었음을 뜻하는 것이며
8번째 열은 해당 bio의 시작 섹터 번호 및 크기임을 고려하면 연속된 요청이란 것을 쉽게 알 수 있다.

그 아래쪽에 I가 보이는데 이것은 insert의 약자로 앞서 생성(되고 merge)된 request가
I/O 스케줄러에게 전달되었음을 뜻한다. 그 바로 아래는 실제 request가 아닌 message를 의미하는
m이 있으며 (이는 CFQ 스케줄러에서 출력한 메시지이다) 지금은 무시하고 넘어가도 좋다.
다음은 U인데 이것은 unplug의 약자로 plugged list 내의 request들을 I/O 스케줄러에게 모두 전달했음을 뜻한다.
다음은 D인데 이것은 dispatch의 약자로 드라이버에게 I/O 연산의 실행을 시작하라고 요청하였음을 뜻한다.
다음은 C인데 이것은 complete의 약자로 dispatch된 request의 처리가 완료되었음을 뜻하는 것이다.

위의 경우 8섹터 (= 4KB) 크기의 bio 12개가 순서대로 요청되어 96섹터 (= 48KB) 크기의 한 request로
merge된 후 한 번에 처리되는 것을 볼 수 있었다.

지금까지 살펴본 과정을 그림으로 나타내면 다음과 같다.



출처 : http://studyfoss.egloos.com/tag/blktrace/page/1

'Embedded Lab > linux, x86' 카테고리의 다른 글

[blktrace 설치법]  (0) 2013.04.08
[blktrace 사용법]  (0) 2013.04.08
[blktrace1]  (0) 2013.04.08
[printk 로그 레벨]  (0) 2013.04.08
[환경변수 삭제]  (0) 2013.04.07
Posted by cyj4369
,

blktrace는 Block I/O Layer 에서 storage (disk, flash 등)로 입출력이 일어나는 과정을 분석해주는 tracing tool 이다.

blktrace가 분석한 내용을 blkparse 가 parsing하여 결과를 눈으로 쉽게 확인할 수 있게 한다.

[그림 1. blktrace architecture]

blktrace 및 blkparse options


blktrace는 여러 옵션을 사용하여 tracing 할 수 있도록 한다. 아래는 일반적인 blktrace 및 blkparse의 사용법이다.

% blktrace -d <dev> -o - | blkparse -i - -o <trace_file>

-d : Use specified device. May also be given last after options

-o : File(s) to send output to
      (위의 사용법에서는  뒤에 '-'가 오는데 이는 stdout 인 텍스트 터미널을 뜻한다.)

-i : Input file containing trace data, or '-' for stdin 
     (위의 사용법에서 blktrace 의 trace data가 stdout으로 지정했으므로, blkparse도 stdin으로 설정한다.)

위의 명령어로 수행하면 <dev>에서의 Block I/O trace결과가 <trace_file>에 저장된다.

이 외에도 많은 옵션들이 있지만, 특별한 경우에 사용되므로 사용해보지 않았다.


iozone를 이용한 blktrace 분석


1. blktrace 를 수행한다.

 blktrace -d /dev/sdb -o - | blkparse -i - -o ./blktrace.sdb.ext4.iozone

 : 현재 dev는 /dev/sbd 이고 분석결과가 저장된 output file은 임의로 blktrace.sdb.ext4.iozone 로 하였다.

2. iozone을 이용하여 mount된 dev에 io를 수행한다.   

 iozone -w -e -s 64k -f ./mnt/iozone.dummy -i 0

 : 64KB 사이즈의 파일(iozone.dummy)을 sequential write pattern으로 write하였다.

  (iozone에 대한 설명은 생략한다.)

3. blktrace 를 종료하고 결과파일을 확인한다.

dev<mjr,mnr>   <cpu>  <seq_num> <time stamp> <pid> <event> <start blk+#of blk>      <process>
 
 8,16           1        1     1.427376394  5529    Q  WS 274432 + 8                [iozone]
  8,16           1        0     1.427383444     0    m   N cfq5529 alloced
  8,16           1        2     1.427384090  5529    G  WS 274432 + 8                [iozone]
  8,16           1        3     1.427385813  5529    P   N [iozone]
  8,16           1        4     1.427386431  5529    I   W 274432 + 8                [iozone]
  8,16           1        0     1.427387153     0    m   N cfq5529 insert_request
  8,16           1        0     1.427387804     0    m   N cfq5529 add_to_rr
  8,16           1        5     1.427390420  5529    Q  WS 274440 + 8                [iozone]
  8,16           1        6     1.427391162  5529    M  WS 274440 + 8                [iozone]
  8,16           1        7     1.427392450  5529    Q  WS 274448 + 8                [iozone]
  8,16           1        8     1.427392667  5529    M  WS 274448 + 8                [iozone]
 ...
  8,16           1       83     1.538002853  5529    U   N [iozone] 1
  8,16           1       84     1.538011856  5529    D   W 274432 + 128              [iozone]
  8,16           1       85     1.591459857     0    C   W 274432 + 128              [0]

결과파일에서 pid=5529 를 가지는 iozone process가 실제로 write 작업을 수행하고 있는 과정을 확인할 수 있다.

실제로 block i/o 동작을 간단히 살펴보자. 

a. seq_num=5 에서 Q event 가 수행된다. Q는 Queue의 약어로, make_request_fn가 수행되어 bio처리가 시작되었음을 나타낸다. 

b. seq_num=6 에서 event 가 수행된다. M은 Merge의 약어로, 앞선 bio request 와 통합되었음(plugged)을 나타낸다. 

c. Q->M 동작이 128 sector (64KB) 까지 반복된다. 이는 현재 iozone이 sequential write를 수행하기 때문에 모든 bio request들이 하나로 통합(merge)됨을 알 수 있다.

d. seq_num=83 에서 event 가 수행된다. U는 unflugged의 약어로, plugged list 내의 request를 I/O scheduler에게 전달했음을 나타낸다. 

e. seq_num=84 에서 D event 가 수행된다. D는 dispatch의 약어로, I/O scheduler가 block device driver에게 수행하라고 요청한 것이다.

f. seq_num=85 에서 event 가 수행된다. C는 complete의 약어로, dispatch된 request의 I/O동작이 완료되었음을 나타낸다.


<event> field 뒤에는 RWBS field로 다음과 같이 정리된다. 

RWBS DESCRIPTION

       This is a small string containing at least one character ('R' for read, 'W'  for  write,  or  'D'  for block discard
       operation), and optionally either  a  'B'  (for  barrier  operations)  or  'S'  (for   synchronous operations).


위 과정을 보면, iozone에서 실제 128KB의 sequential write 요청에 대한 Block I/O 동작을 확인할 수 있다. blktrace는 Block I/O뿐만 아니라 I/O scheduler의 동작까지도 확인할 수 있다. 

아래는 blkparse 결과파일에서 확인할 수 있는 모든 event에 대해 정리한 것이다.


(출처 : http://linux.die.net/man/1/blkparse)


Trace Actions

The following trace actions are recognised:
C -- complete
A previously issued request has been completed. The output will detail the sector and size of that request, as well as the success or failure of it.
D -- issued
A request that previously resided on the block layer queue or in the i/o scheduler has been sent to the driver.
I -- inserted
A request is being sent to the i/o scheduler for addition to the internal queue and later service by the driver. The request is fully formed at this time.
Q -- queued
This notes intent to queue i/o at the given location. No real requests exists yet.
B -- bounced
The data pages attached to this bio are not reachable by the hardware and must be bounced to a lower memory location. This causes a big slowdown in i/o performance, since the data must be copied to/from kernel buffers. Usually this can be fixed with using better hardware -- either a better i/o controller, or a platform with an IOMMU.
M -- back merge
A previously inserted request exists that ends on the boundary of where this i/o begins, so the i/o scheduler can merge them together.
F -- front merge
Same as the back merge, except this i/o ends where a previously inserted requests starts.
M --front or back merge

One of the above

M -- front or back merge
One of the above.
G -- get request
To send any type of request to a block device, a struct request container must be allocated first.
S -- sleep
No available request structures were available, so the issuer has to wait for one to be freed.
P -- plug
When i/o is queued to a previously empty block device queue, Linux will plug the queue in anticipation of future ios being added before this data is needed.
U -- unplug
Some request data already queued in the device, start sending requests to the driver. This may happen automatically if a timeout period has passed (see next entry) or if a number of requests have been added to the queue.
T -- unplug due to timer
If nobody requests the i/o that was queued after plugging the queue, Linux will automatically unplug it after a defined period has passed.
X -- split
On raid or device mapper setups, an incoming i/o may straddle a device or internal zone and needs to be chopped up into smaller pieces for service. This may indicate a performance problem due to a bad setup of that raid/dm device, but may also just be part of normal boundary conditions. dm is notably bad at this and will clone lots of i/o.
A -- remap
For stacked devices, incoming i/o is remapped to device below it in the i/o stack. The remap action details what exactly is being remapped to what.


출처 : http://ji007.tistory.com/archive/20120426

'Embedded Lab > linux, x86' 카테고리의 다른 글

[blktrace 사용법]  (0) 2013.04.08
[blktrace2]  (0) 2013.04.08
[printk 로그 레벨]  (0) 2013.04.08
[환경변수 삭제]  (0) 2013.04.07
[간단한 블록 디바이스 드라이버 모듈(램디스크)]  (0) 2013.04.07
Posted by cyj4369
,

커널 함수에서 사용되는 출력 함수이다.

printf와의 차이는 메시지 기록관리를 위한 로그레벨을 지정할 수 있다는 것이다.

로그레벨                        명령어 의미

  "<0>"     KERN_EMERG         시스템이 동작하지 않는다.

  "<1>"     KERN_ALERT         항상 출력

  "<2>"     KERN_CRIT         치명적인 정보

  "<3>"      KERN_ERR        오류 정보

  "<4>"     KERN_WARNING 경고 정보 

  "<5>"     KERN_NOTICE         정상적인 정보 

  "<6>"     KERN_INFO         시스템 정보 

  "<7>"     KERN_DEBUG        디버깅 정보


위처럼 로그레벨을 지정하는 이유는 kernel source 내에서 원하는 정보만 출력할 수 있게 함이다.


사용법은 다음과 같다


 printk(KERN_ERR"This is KERN_ERR option\n");


다음 명령을 실행해보면 현재의 로그레벨을 확인 할 수 있다.


 $cat /proc/sys/kernel/prink 

      7     4     1     7


[7] : 현재 로그레벨

       이 레벨보다 높은 메시지(숫자가 작은 수)만 출력을 해준다.

[4] : 기본 로그레벨

       printk()함수를 입력하면서 별도로 로그레벨을 입력하지 않을 경우

[1] : 최소 로그레벨

       부여할 수 있는 최소 로그레벨이다.

       이 값이 1이라면 우리가 printk 함수를 입력하면서 0을 부여할 수 없다.

[7] : 부팅시 로그레벨

        부팅시 출력될 레벨을 지정해주는 것이다.


출력되지 않았을 경우 다음과 같은 명령어로 로그버퍼에 기록된 내용을 볼 수 있다. (출력되지 않은 메시지도 볼 수 있음)

dmesg

# cat /proc/kmsg

'Embedded Lab > linux, x86' 카테고리의 다른 글

[blktrace2]  (0) 2013.04.08
[blktrace1]  (0) 2013.04.08
[환경변수 삭제]  (0) 2013.04.07
[간단한 블록 디바이스 드라이버 모듈(램디스크)]  (0) 2013.04.07
[환경변수 삭제]  (0) 2013.03.29
Posted by cyj4369
,

export의 반대는..

unset '환경변수이름'

'Embedded Lab > linux, x86' 카테고리의 다른 글

[blktrace1]  (0) 2013.04.08
[printk 로그 레벨]  (0) 2013.04.08
[간단한 블록 디바이스 드라이버 모듈(램디스크)]  (0) 2013.04.07
[환경변수 삭제]  (0) 2013.03.29
[리눅스 압축명령]  (0) 2013.03.28
Posted by cyj4369
,

My current work involves writing my first Linux block device driver. Going to the web to find a sample, I discovered Jonathan Corbet's Simple Block Driver article with its associated block driver example code. It's a nice succinct implementation of a ramdisk - pretty much the simplest working block device. There's only one problem, though, the article was written in 2003, when kernel 2.6.0 was the new kid on the block. Trying to build it on openSUSE 11.2 with kernel 2.6.31 just produced a slew of compile errors. A bit of research revealed that there were major changes to the kernel block device interface in 2.6.31, so I would have to port the example to get it working.

About a day and a half of poring through the kernel source and the excellent LDD3 (hardcopy) later, I had a running simple block driver for kernel 2.6.31. I've also tested it successfully on SUSE 11 SP1 Beta, which uses kernel 2.6.32. Here's the code, followed by instructions for getting it working.

sbd.c

/*
 * A sample, extra-simple block driver. Updated for kernel 2.6.31.
 *
 * (C) 2003 Eklektix, Inc.
 * (C) 2010 Pat Patterson <pat at superpat dot com>
 * Redistributable under the terms of the GNU GPL.
 */

#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/init.h>

#include <linux/kernel.h> /* printk() */
#include <linux/fs.h>     /* everything... */
#include <linux/errno.h>  /* error codes */
#include <linux/types.h>  /* size_t */
#include <linux/vmalloc.h>
#include <linux/genhd.h>
#include <linux/blkdev.h>
#include <linux/hdreg.h>

MODULE_LICENSE("Dual BSD/GPL");
static char *Version = "1.4";

static int major_num = 0;
module_param(major_num, int, 0);
static int logical_block_size = 512;
module_param(logical_block_size, int, 0);
static int nsectors = 1024; /* How big the drive is */
module_param(nsectors, int, 0);

/*
 * We can tweak our hardware sector size, but the kernel talks to us
 * in terms of small sectors, always.
 */
#define KERNEL_SECTOR_SIZE 512

/*
 * Our request queue.
 */
static struct request_queue *Queue;

/*
 * The internal representation of our device.
 */
static struct sbd_device {
	unsigned long size;
	spinlock_t lock;
	u8 *data;
	struct gendisk *gd;
} Device;

/*
 * Handle an I/O request.
 */
static void sbd_transfer(struct sbd_device *dev, sector_t sector,
		unsigned long nsect, char *buffer, int write) {
	unsigned long offset = sector * logical_block_size;
	unsigned long nbytes = nsect * logical_block_size;

	if ((offset + nbytes) > dev->size) {
		printk (KERN_NOTICE "sbd: Beyond-end write (%ld %ld)\n", offset, nbytes);
		return;
	}
	if (write)
		memcpy(dev->data + offset, buffer, nbytes);
	else
		memcpy(buffer, dev->data + offset, nbytes);
}

static void sbd_request(struct request_queue *q) {
	struct request *req;

	req = blk_fetch_request(q);
	while (req != NULL) {
		// blk_fs_request() was removed in 2.6.36 - many thanks to
		// Christian Paro for the heads up and fix...
		//if (!blk_fs_request(req)) {
		if (req == NULL || (req->cmd_type != REQ_TYPE_FS)) {
			printk (KERN_NOTICE "Skip non-CMD request\n");
			__blk_end_request_all(req, -EIO);
			continue;
		}
		sbd_transfer(&Device, blk_rq_pos(req), blk_rq_cur_sectors(req),
				req->buffer, rq_data_dir(req));
		if ( ! __blk_end_request_cur(req, 0) ) {
			req = blk_fetch_request(q);
		}
	}
}

/*
 * The HDIO_GETGEO ioctl is handled in blkdev_ioctl(), which
 * calls this. We need to implement getgeo, since we can't
 * use tools such as fdisk to partition the drive otherwise.
 */
int sbd_getgeo(struct block_device * block_device, struct hd_geometry * geo) {
	long size;

	/* We have no real geometry, of course, so make something up. */
	size = Device.size * (logical_block_size / KERNEL_SECTOR_SIZE);
	geo->cylinders = (size & ~0x3f) >> 6;
	geo->heads = 4;
	geo->sectors = 16;
	geo->start = 0;
	return 0;
}

/*
 * The device operations structure.
 */
static struct block_device_operations sbd_ops = {
		.owner  = THIS_MODULE,
		.getgeo = sbd_getgeo
};

static int __init sbd_init(void) {
	/*
	 * Set up our internal device.
	 */
	Device.size = nsectors * logical_block_size;
	spin_lock_init(&Device.lock);
	Device.data = vmalloc(Device.size);
	if (Device.data == NULL)
		return -ENOMEM;
	/*
	 * Get a request queue.
	 */
	Queue = blk_init_queue(sbd_request, &Device.lock);
	if (Queue == NULL)
		goto out;
	blk_queue_logical_block_size(Queue, logical_block_size);
	/*
	 * Get registered.
	 */
	major_num = register_blkdev(major_num, "sbd");
	if (major_num < 0) {
		printk(KERN_WARNING "sbd: unable to get major number\n");
		goto out;
	}
	/*
	 * And the gendisk structure.
	 */
	Device.gd = alloc_disk(16);
	if (!Device.gd)
		goto out_unregister;
	Device.gd->major = major_num;
	Device.gd->first_minor = 0;
	Device.gd->fops = &sbd_ops;
	Device.gd->private_data = &Device;
	strcpy(Device.gd->disk_name, "sbd0");
	set_capacity(Device.gd, nsectors);
	Device.gd->queue = Queue;
	add_disk(Device.gd);

	return 0;

out_unregister:
	unregister_blkdev(major_num, "sbd");
out:
	vfree(Device.data);
	return -ENOMEM;
}

static void __exit sbd_exit(void)
{
	del_gendisk(Device.gd);
	put_disk(Device.gd);
	unregister_blkdev(major_num, "sbd");
	blk_cleanup_queue(Queue);
	vfree(Device.data);
}

module_init(sbd_init);
module_exit(sbd_exit);

Makefile

obj-m := sbd.o
KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

There are two main areas of change compared with Jonathan's original:

  • sbd_request() uses the blk_fetch_request()blk_rq_pos(),blk_rq_cur_sectors() and __blk_end_request_cur() functions rather thanelv_next_request()req->sectorreq->current_nr_sectors andend_request() respectively. The structure of the loop also changes so we handle each sector from the request individually. One outstanding task for me is to investigate whetherreq->buffer holds all of the data for the entire request, so I can handle it all in one shot, rather than sector-by-sector. My first attempt resulted in the (virtual) machine hanging when I installed the driver, so I clearly need to do some more work in this area!
  • The driver implements the getgeo operation (in sbd_getgeo), rather than ioctl, since blkdev_ioctl now handles HDIO_GETGEO by calling the driver's getgeo function. This is a nice simplification since it moves a copy_to_user call out of each driver and into the kernel.

Before building, ensure you have the kernel source, headers, gcc, make etc - if you've read this far, you likely have all this and/or know how to get it, so I won't spell it all out here. You'll also need to go to the kernel source directory and do the following to prepare your build environment, if you have not already done so:

cd /usr/src/`uname -r`
make oldconfig && make prepare

Now, back in the directory with the sbd source, you can build it:

make -C /lib/modules/`uname -r`/build M=`pwd` modules

You'll see a warning about 'Version' being defined, but not used, but don't worry about that :-). Now we can load the module, partition the ramdisk, make a filesystem, mount it, and create a file:

opensuse:/home/pat/sbd # insmod sbd.ko
opensuse:/home/pat/sbd # fdisk /dev/sbd0
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x5f93978c.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-16, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-16, default 16):
Using default value 16

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
opensuse:/home/pat/sbd # mkfs /dev/sbd0p1
mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
64 inodes, 504 blocks
25 blocks (4.96%) reserved for the super user
First data block=1
Maximum filesystem blocks=524288
1 block group
8192 blocks per group, 8192 fragments per group
64 inodes per group

Writing inode tables: done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
opensuse:/home/pat/sbd # mount /dev/sbd0p1 /mnt
opensuse:/home/pat/sbd # echo Hi > /mnt/file1
opensuse:/home/pat/sbd # cat /mnt/file1
Hi
opensuse:/home/pat/sbd # ls -l /mnt
total 13
-rw-r--r-- 1 root root     3 2010-04-29 07:04 file1
drwx------ 2 root root 12288 2010-04-29 07:04 lost+found
opensuse:/home/pat/sbd # umount /mnt
opensuse:/home/pat/sbd # rmmod sbd

Hopefully this all works for you, and is as useful for you as it has been for me. Many thanks to Jonathan for the original version and the excellent LDD3. One final piece of housekeeping - although the comment at the top of sbd.c mentions only GPL, the MODULE_LICENSE macro specifies "Dual BSD/GPL". I am interpreting the original code as being under the dual GPL/BSD license and this version is similarly dual licensed.

UPDATE (Feb 5 2011) See the comment by Michele regarding changes to logical_block_size!


출처 : http://blog.superpat.com/2010/05/04/a-simple-block-driver-for-linux-kernel-2-6-31/

'Embedded Lab > linux, x86' 카테고리의 다른 글

[printk 로그 레벨]  (0) 2013.04.08
[환경변수 삭제]  (0) 2013.04.07
[환경변수 삭제]  (0) 2013.03.29
[리눅스 압축명령]  (0) 2013.03.28
[리눅스가 부팅이 안될 때/MBR에 GRUB을 다시 설치하는 방법]  (0) 2013.03.28
Posted by cyj4369
,

환경변수 삭제


unset

Posted by cyj4369
,