1. JOIN 이란?
데이터를 검색하다 보면 테이블 하나만을 이용해서는 원하는 정보를 다 가져오지 못하는 경우가 많습니다. 예를 들어 사원의 급여 정보를 검색하는 경우에 [급여] 테이블에는 사원 번호와 급여 정보만 있는 경우 사원 이름을 같이 검색하고자 한다면 사원 이름을 가지고 있는 [사원] 테이블을 참조해야 합니다. 이렇게 테이블을 서로 연결하여 검색을 할 때 사용되는 것이 JOIN 문 입니다.
JOIN의 종류는 다음과 같이 나눌 수 있습니다.
INNER JOIN
OUTER JOIN
FULL JOIN
CROSS JOIN
이 중에서 가장 많이 사용되는 것이 INNER JOIN 입니다. 다음 [그림 1]을 기준으로 해서 이들 조인의 기능을 살펴보도록 하겠습니다.

[그림 1]
[그림 1]과 같이 [사원] 테이블과 [급여] 테이블이 있습니다. 실제 업무와 다를 수 있지만 조인의 기능을 확인하기 위하여 가정을 하도록 하겠습니다. [사원] 테이블에는 사원 정보가, [대출] 테이블에는 대출 정보가 기록되어 있습니다.
2. INNER JOIN
INNER JOIN은 양쪽의 행들 중에서 서로 연관된 내용만 검색하는 조인 방법입니다. INNER JOIN을 위해서는 우선 [그림 2]처럼 두 테이블에서 공통되지 못한 부분은 JOIN의 대상에서 제외가 됩니다.

[그림 2]
그리고 남아 있는 양쪽의 행들이 다음 [그림 3]과 같이 서로 연관된 행들끼리 결합을 하게 됩니다.

[그림 3]
결국 다음 [그림 4]와 같은 결과를 얻을 수 있게 됩니다.

[그림 4]
위 내용을 INNER JOIN을 이용한 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A INNER JOIN 대출 B ON A.사번 = B.사번


o 이 쿼리문에서 A와 B 는 [사원] 테이블과 [대출] 테이블을 가리키는 Alias 입니다. 
o ON 부분을 보면 두 테이블을 '사번' 을 이용하여 연결하고 있습니다.

위 쿼리문은 다음과 같이 표현 할 수도 있습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A JOIN 대출 B ON A.사번 = B.사번
즉 'INNER' 를 생략하고 단순히 'JOIN' 만 사용해도 'INNER JOIN'으로 인식됩니다. 이것은 대부분의 JOIN 이 INNER JOIN 이기 때문에 사용자의 편의를 위한 것입니다.
3. OUTER JOIN
OUTER JOIN은 한쪽 테이블을 기준으로 해서 조인을 형성합니다. 그래서 기준이 되는 테이블은 조인되는 테이블과 연관성이 없다 하여도 검색의 대상이 됩니다. 이러한 이유로 OUTER JOIN에는 다음과 같이 두가지의 방법이 존재하게 됩니다.
LEFT OUTER JOIN (기본값)
RIGHT OUTER JOIN
만일 [사원] 테이블과 [대출] 테이블을 OUTER JOIN 시킬 때 [사원] 테이블을 기준으로 한다면 다음 [그림 5] 와 같은 결과를 얻게 됩니다.

[그림 5]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A LEFT OUTER JOIN 대출 B ON A.사번 = B.사번
하지만 [대출] 테이블을 기준으로 한다면 다음 [그림 6] 과 같은 결과를 얻게 됩니다.

[그림 6]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A RIGHT OUTER JOIN 대출 B ON A.사번 = B.사번
4. FULL JOIN
FULL JOIN은 [그림 5]와 [그림 6]의 결합이라고 생각하시면 됩니다. 결합이 되는 양쪽 테이블에서 연관성이 없는 행도 조인의 결과에 포함되기 때문입니다. [사원] 테이블과 [대출] 테이블의 FULL JOIN의 결과는 다음 [그림 7]과 같습니다.

[그림 7]
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A FULL JOIN 대출 B ON A.사번 = B.사번
5. CROSS JOIN
CROSS JOIN은 한쪽 테이블의 모든 행들에 대하여 다른 쪽 행들이 전부 대입이 되는 형태의 조인입니다. 만일 [사원] 테이블과 [대출] 테이블을 CROSS JOIN 시킨다면 [그림 8] 과 같은 각각 대입되어 [그림 9]와 같은 결과를 얻게 됩니다. 단, [그림 8]은 첫번째 행에 대한 대입만을 보여주고 있는데 이러한 대입이 [사원] 테이블의 모든 행에 대하여 이루어지게 됩니다.

[그림 8]

[그림 9]
결국 [사원] 테이블의 행의 갯수 X [대출] 테이블의 행의 갯수 만큼의 행이 CROSS JOIN의 결과를 얻어지게 됩니다.
위 내용을 쿼리문으로 표현한다면 다음과 같습니다.
SELECT A.사번, A.이름, B.도서
FROM 사원 A CROSS JOIN 대출 B
즉, 두 테이블의 연관성이 전혀 필요없게 되므로 ON 절이 포함되지 않습니다.
6. 정리
SELECT 문을 사용 할 때 가장 이해하기 힘든 부분이 JOIN 이 아닌가 싶습니다. JOIN 기능을 잘 익혀 두면 좀더 효율적인 검색을 할 수 있습니다. OUTER JOIN이나 FULL JOIN, CROSS JOIN은 잘 사용이 되지 않습니다. 그 이유는 많은 사람들이 INNER JOIN 까지만 배우고 더이상은 JOIN에 대하여 배우지 않고 무작정 SELECT 문을 사용하기 때문이 아닌가 싶습니다.
다음 강좌에서는 실제로 JOIN을 사용하는 예제를 보면서 다시한번 JOIN에 대하여 살펴볼 예정입니다. 온라인 설명서(Books Online)을 보시면 JOIN에 대한 방대한 량의 설명이 있습니다. 그 내용을 꼭 참고하여 주시기 바랍니다.


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

데이터베이스 - MySql  (0) 2015.11.26
데이터베이스 - 데이터 타입  (0) 2015.11.26
데이터베이스 - 트랜잭션  (0) 2015.11.26
데이터베이스 - SQL  (0) 2015.11.25
데이터베이스 - 관계 대수  (0) 2015.11.25

출처: http://sejoong.github.io/dev/2015/02/15/dev/HTTP 2.0 : The New Web Standard and Issue(허태성, saturn.twinfish@gmail.com)

HTTP 1.1 이후로 처음 등장한 새로운 버전인 HTTP/2.0을 알아보기 전에 HTTP가 무엇인지 알아보고 HTTP/2.0에서는 어떤 변화가 있는지 알아보자.

HTTP

HyperText Transfer Protocol의 약자로 WWW(World Wide Web)에서 하이퍼텍스트(hypertext) 문서를 교환하기 위하여 사용되는 통신규약이다.
1.0(1996s)m 1.1(1999s)두가지 버전이 있다.

  • Status code:
    http 통신중 요청의 상태 정보를 제공한다. 공식 적인 상태코드 목록은 IANA에서 확인할 수 있다.
    상태코드의 첫 숫자는 응답의 종류를 나타낸다. 아래는 응답의 종류와 내가 개발중 많이 접했던 몇가지 상태 코드 이다.
  1. 1xx - Informational - 정보교환
  2. 2xx - Success - 성공
    200 - OK - 요청이 성공적으로 전송됨
  3. 3xx - Redirection - 방향 지정
    301 - Moved Permanently - 요청 페이지의 영구적인 위치 변화
    302 - Found - 요청 페이지이 일시적인 위치 변화
  4. 4xx - Client Error - 클라이언트 오류
    404 - Not Found - 요청받은 자원을 서버에서 찾을 수 없을때 나타나는 상태 
    405 - Method Not Allowed - 서버에서 사용자가 요청한 주소의 메소드를 지원하지 않을때 나타남
  5. 5xx - server Error - 서버 오류
  • Request methods:
    요청이 수행될 작업의 방법을 나타낸다.

    1. OPTIONS: 요청한 URL에 어떠한 메소드 요청이 가능한지 묻는다.
    2. GET: 다른 작업없이 데이터의 검색에 이용.
    3. HEAD: 데이터의 검색에 이용하나 GET과는 다르게 응답 HEADER만 받는다.
    4. POST: URL에 새로운 데이터를 보낼때 사용.
    5. PUT: URL에 저장될 정보를 보낸다.
    6. DELETE: URL의 리소스를 삭제한다.
    7. TRACE: 보낸 메세지를 다시 돌려받는다.
    8. CONNECT: 프록시에서 사용되는 예약 메소드.
  • 요청/응답 스펙

Request-Line
*(( general-header | request-header | entity-header ) CRLF)
CRLF
[ message-body ]

  1. Request-line: method, request url, http버전
  2. Request-header: general-header, request-header, entity-header가 존재하며 필요에 따라 사용

Status-Line

*(( general-header | response-header | entity-header ) CRLF)
CRLF
[ message-body ]

  1. status-line: http 버전, 상태 코드, 상태 메세지
  2. Request-header: general-header, response-header, entity-header

HTTP/2.0의 등장 배경 및 특징

latency를 줄여 웹의 속도를 개선하기 위해 등장.
1. HTTP Header 데이터 압축
2. Server Push(서버에서 부터 시작되는 전송)
3. HTTP 1에서 존재하던 head-of-line blocking 문제 개선
4. 싱글 TCP connection내에서 병렬 페이지 로딩 구현
2.0은 기존 버전인 1.1과의 높은 호환성(method, status codes 등)은 보장하고 클라이언트 서버 간 전송 및 프레임의 개선에 초점을 맞췄다.
head-of-line blocking: 동일한 송신 포트 자원에 대한 처리량 경쟁으로 인해 처리량 지연 및 프레임 손실 발생 유발 작업대기 중인 2개의 패킷이 존재할 경우 첫번째 패킷이 대기중이면 그 뒤 패킷들은 무조건 대기할때 발생












HTTP 2.0의 개선 사항

  1. 효율적인 페이지 로딩을 위해 URL의 이미지, 스크립트등의 자원을 압축해 페이지 렌더링을 위한 요청횟수를 감소시켰다.
  2. 뿐만 아니라 server가 push가 가능해 웹페이지의 렌더링이 필요하단 사실을 알게되면 추가 요청없이 서버가 리소스를 제공한다.
  3. 그 외에도 성능 개선을 위한 요청 다중화, 헤더 압축, HOL Blocking해결을 위한 요청 우선순위 결정등이 있다.

HTTP/2.0과 SPDY와의 관계

  • SPDY:
    Google이 ‘speedy’라는 단어를 기반으로 제안한 새로운 프로토콜이다. HTTP의 단점들을 보완하여, 인터넷 환경을 보다 효율적으로 이용하기 위한 프로토콜이다. HTTP/2.0에서는 스펙에 SPDY를 반영할 예정이다.

  • 특징:

    1. TLS 위에서 동작한다.

      • https에서만 적용가능
    2. HTTP 헤더를 압축한다.

      • 요청마다 반복되는 내용을 압축해 성능 향상 효과가 나타남
    3. 바이너리로 프레임을 구성한다.

      • 파싱 속도가 향상되고 오류확률은 낮아진다.
    4. 다중 연결을 지원한다.

      • 다수의 요청, 응답 을 동시에 처리 할 수 있어 속도 향상
    5. 인터리빙을 허용한다.

      • 우선순위가 높은 데이터가 더 빨리 전송 될 수있다.
    6. 서버 푸시가 가능하다.

결론

HTTP 1.1 이 사용하는 전송방식(RFC7230)에는 몇가지 문제점이 존재했다.
HTTP/1.0은 TCP connection에서 한번에 하나의 요청 만이 가능했고 HTTP/1.1에서는 그보다 발전하여 request pipelining을 사용했지만 여전히 HOL Blocking 문제가 존재했다.
HTTP/2.0은 오랫동안 변화하지 않았던 HTTP를 현 웹 환경에 맞게 발전시켜 속도의 향상을 도모 한다는데 크 의의가 있다.

참고: http://http2.github.io/http2-spec/#intro 참고: http://helloworld.naver.com/helloworld/140351


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

http vs https  (0) 2016.03.23
네트워크 - 총 정리  (0) 2015.12.18
네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
  • HTTPS(Hypertext Transfer Protocol over Secure Socket Layer)는 월드 와이드 웹 통신 프로토콜인 HTTP의 보안이 강화된 버전이다. HTTPS는 통신의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발했으며, 전자 상거래에서 널리 쓰인다.
    HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다. 따라서 데이터의 적절한 보호를 보장한다. HTTPS의 기본 TCP/IP 포트는 443이다.
    보호의 수준은 웹 브라우저에서의 구현 정확도와 서버 소프트웨어, 지원하는 암호화 알고리즘에 달려있다.
    HTTPS를 사용하는 웹페이지의 URL은 'http://'대신 'https://'로 시작한다.

5. HTTPS

SSL은 전자상거래에서의 데이터 보안을 위해서 개발한 통신 레이어다. SSL은 표현계층의 프로토콜로 응용 계층 아래에 있기 때문에, 어떤 응용 계층의 데이터라도 암호화해서 보낼 수 있다.

HTTP는 기본적으로 평문 데이터 전송을 원칙으로 하기 때문에 개인의 프라이버시가 오가는 서비스들(전자상거래, 전자메일, 사내문서)에 사용하기 힘들다. HTTPS는 SSL 레이어위에 HTTP를 통과 시키는 방식이다. 즉 평문의 HTTP 문서는 SSL 레이어를 통과하면서 암호화 돼서 목적지에 도착하고, 목적지에서는 SSL 레이어를 통과하면서 복호화 돼서 웹 브라우저에 전달된다.

간혹 HTTPS를 하나의 프로토콜로 인식하기도 하는데, HTTP와 SSL은 전혀 다른 계층의 프로토콜콜의 조합이다. HTTPS over SSL로 보는게 좀더 정확한 시각이다. 거의 모든 웹 서버와 웹 브라우저와 HTTP 기반의 툴들 - wget, curlab 기타등등 - 이 SSL을 지원한다.

5.1.1. HTTP와 다른 점

  • HTTPS URL은 "https://"로 시작한다. 기본 포트번호는 443이다. HTTP URL은 "http://"로 시작한다. 기본 포트번호는 80이다.
  • HTTP는 평문 데이터를 기반으로 하기 때문에, 유저정보와 같은 민감한 정보가 인터넷 상에 그대로 노출된다. 이 정보는 수집되거나 변조될 수 있다. HTTPS는 이러한 공격을 견딜 수 있도록 설계돼 있다.
  • HTTPS는 인증서를 이용해서, 접속 사이트를 신뢰할 수 있는지 평가할 수 있다.
  • 일반적으로 HTTPS는 HTTP에 비해서 (매우 많이)느리다. 많은 양의 데이터를 처리할 경우 성능의 차이를 체감할 수 있다. 많은 웹 사이트들이 민감한 정보를 다루는 페이지(로그인 혹은 유저정보) 페이지를 HTTPS로 전송하고, 기타 페이지는 HTTP로 전송하는 방법을 사용한다. 하드웨어 SSL 가속기를 이용해서 암/복호화 성능을 높이는 방법을 사용하기도 한다.

출처: http://www.joinc.co.kr/w/Site/Network_Programing/AdvancedComm/HTTP

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

HTTP1.0 ~ HTTP2.0  (0) 2016.04.12
네트워크 - 총 정리  (0) 2015.12.18
네트워크 - Link Layer  (0) 2015.12.17
네트워크 - Network Layer  (0) 2015.12.10
네트워크 - Transport Layer  (0) 2015.12.09
  • Module Programming


    - 절차


    - 특징



    - Module 적재 및 제거


    - 기본 구조


    - Module 관련 유틸리티


    - Module Program 작성




  • Device Driver
    : 디바이스와 시스템 사이에 데이터를 주고받기 위한 인터페이스
    : 표준적으로 동일한 서비스 제공을 목적
    : 커널의 일부분으로 내장
    : 서브루틴과 데이터의 집합체
    : 디바이스의 고유한 특성을 내포




    - Device 종류



    - 디바이스 파일



    - File Operations







    ■ Character Device Driver


    ■ Ext4_file_operations



    - 디바이스 드라이버 구현



    : 모드간 데이터 전송

     

     

     : I/O 영역 경쟁 처리

     

     

     

    : 디바이스 종류별 등록/해제

     


    문자 디바이스 드라이버
     - 2.6 이후
      1. 디바이스 번호 등록
      2. cdev 구조체 생성 및 초기화
      3. 디바이스 등록 cdev_add(); -> module_init();
      4. file_operations 구조체에 대입될 함수들을 작성

    - 출처 : http://blog.dasomoli.org/223

    : register_chrdrv_region 함수는 원하는 디바이스의 번호를 미리 알고 있을 때 사용하고, alloc_chrdev_region 함수는 디바이스의 번호를 동적으로 할당받아 파라미터로 받는 dev_t 구조체 포인터를 이용해 dev_t 구조체에 넣는다.
    register_chrdrv 대신 register_chrdrv_region을 사용하는 것으로 혼동할 수 있는데 그게 아닌 cdev_add 함수까지 사용하여야 한다. 실제 커널 소스의 register_chrdrv 함수를 보면 이런 과정이 구현되어 있음을 볼 수 있다.
    cdev_add 함수를 사용하기 위해서는 struct cdev 구조체를 사용하여야 하는데 이 구조체를 초기화 시켜주는 함수가 cdev_init 이다. struct cdev 구조체 등을 사용하려면 <linux/cdev.h> 를 include하여야 한다. 다음은 사용 예이다.

     
    #include <linux/kernel.h>
    #include <linux/cdev.h>
    #include <linux/fs.h>
    
    ...
    struct file_operations dasom_fops;
    
    static struct cdev dasom_cdev = {
        .owner = THIS_MODULE,
        .ops = &dasom_fops,
    };
    
    int _init dasom_init(void)
    {
        dev_t dev;
        int err = 0;
    
        if(major) {
            dev = MKDEV(major, minor);
            err = register_chrdev_region(dev, 1, "dasomoli");
        } else {
            err = alloc_chrdev_region(&dev, mior, 1, "dasomoli");
            major = MAJOR(dev);  
        }
        if(err < 0) {
            err = -ENODEV;
            return err;
        }
        ...
        
        cdev_init(&dasom_cdev, &dasom_fops);
        dasom_cdev.owner = THIS_MODULE;
        dasom_cdev.ops  = &dasom_fops;
    
        if(cdev_add(&dasom_cdev, dev, 1)) {
            printk(KERN_INFO"dasom: cdev creation failed.\n");
            err = -ENODEV;
            goto error_label;
        }
        
        ...
        
        return 0;
        
    error_label:
        return err;
    }
    


     - 2.6 이전
     
     

     블록 디바이스 드라이버
     
     

    ■ 

    네트워크 디바이스 드라이버

     
     

    - Character Device Driver with VFS


    - File System and Device Driver




  • 전체 요약







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

리눅스 - Ext4 File System  (0) 2016.02.01
리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (7) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
  • 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
  • 파일 시스템 (File System)
    : 저장장치 내에서 데이터를 읽고 쓰기 위해 미리 정해진 약속
    : 파일 저장 및 검색을 용이하도록 유지/관리하는 방법
    : 파일을 어떻게 관리할 것인가에 대한 메커니즘과 정책
    : 파일 + 디렉토리 구조
    : EXT2, EXT3, FAT, FAT32, NTFS, JFFS, JFFS, JFFS2, ISO 9660 ...
    : Journaling File System - 파일 시스템의 변화를 기록해 두었다가 시스템 결함으로 문제가 발생할 경우 파일 시스템 복구

       

    - 섹터에 대한 파일 매핑
     

    - 기능
     : 파일 생성, 제거, 수정
     : 타인과 파일 공동 사용
     : Backup & Recovery
     : 물리적 장치 이름 대신 기호화된 이름 사용- 장치와의 독립성 제공 : C:, D:, /, /home, /dev/sda1
     : 정보의 안전한 보관편리한 인터페이스
     : 타겟 저장장치에 따른 최적화된 접근, 할당 정책
     
  • 파일 (File)
    : 디스크와 같은 물리적인 저장 매체에 저장되는 데이터 집합
    : 데이터 정보에 대한 논리적인 저장 단위
    : 저장장치의 물리적 특성을 추상화한 논리적 저장 단위
    : 자료가 파일 안에 존재해야만 보조 저장장치에 기록될 수 있음

    - 속성(Attributes)

     : 이름, 식별자, 타입, 위치, 크기, 보호, 시간 등
     : 파일의 내용을 제외한 파일의 모든 정보는 보조 저장장치에 상주하는 디렉터리 구조 내에 유지
     : 1단계, 2단계 디렉터리 구조, 트리 구조 디렉터리, 일반 그래프 디렉터리 구조 등 다양한 디렉터리 구조가 존재
     

  • 할당 방법 (Allocation Methods)
    : 파일 시스템은 파일을 디스크 블록(block)이라는 논리적인 단위의 집합으로 관리
     -> 사용자가 파일을 디스크에 저장하기를 요청하면 파일은 블록단위로 분할되어 파일 시스템 정책에 따라 일정한 장소에 내용을 기록
     -> 블록의 크기는 1KB, 4KB, 16KB, 64KB 등
    : 디스크 할당의 주요 문제는 파일들을 어떻게 디스크 공간에 배치해야 디스크 공간을 효율적으로 사용할 수 있고, 파일들에 빨리 접근할 수 있는가
    : 디스크의 직접 접근 특성이 파일의 구현에 융통성을 허용

    - 디스크 블록 할당 방법
     ■ 연속 할당 (Contiguous Allocation)
      : 하나의 파일을 디스크 내의 연속된 블록에 순차적으로 할당하는 방법, 디스크 탐색 횟수를 최소화
      : 가용 공간을 선택하는 방법 - First-Fit, Best-Fit, Worst-Fit
      : 파일의 크기가 가변적으로 변화되는 경우 연속 할당을 사용할 경우 성능 저하 발생
      : 내부 단편화, 외부 단편화 발생
       

     ■ 불연속 할당 (Disc
    ontiguous Allocation)
      : 불연속적인 공간에 흩어진 디스크 블록에 나누어 저장

      □ 연결 할당(Linked Allocation)
       : 흩어진 블록들을 연결 리스트로 관리
       : 순차 접근인 경우 효과적이지만 직접 접근 시에는 매우 비효율적 -> 포인터 접근 시마다 디스크 읽기와 탐색 오버헤드 존재
       : FAT
       : 연속 할당의 문제점인 외부 단편화와 내부 단편화 문제를 해결

       

      □
     색인 할당(Indexed Allocation)
       : 디스크 블록에 대한 위치 정보를 가지고 있는 인덱스 블록 사용
        -> 블록이 할당될 때마다 해당 정보를 인덱스 블록에 기록
        -> 직접 접근 문제 해결. 인덱스 블록 유지 비용 발생
       : 파일이 커지면 하나의 인덱스 블록만으로 관리 불가능
        -> 여러 개의 인덱스 블록이 필요하면 이를 연결리스트로 관리
       : Linux는 inode 기법을 이용
       

  • 리눅스 파일 시스템 계층 분석

     

    - 리눅스 디스크 접근
      장치 파일은 /dev에 위치

      : 디스크가 설치되면 장치 파일을 이용하여 해당 디스크 접근

      -> /dev/sdb3 -> SCSI 타입의 두 번째 디스크의 세 번째 파티션

      -> /dev/sda1 -> SCSI 타입의 첫 번째 디스크의 첫 번째 파티션

     ■ 파티션 (partition)
      : 물리 장치의 논리적인 분리
      : 파일 시스템은 파티션마다 하나씩 만들어짐

      -> SCSI 타입의 하드 디스크 -> sda, sdb

      -> IDE 타입의 하드 디스크 -> hda, hdb


    - Mount
     : 파일 시스템을 트리 구조의 특정 노드에 mapping하는 역할
     : Root file system -> 시스템 부팅 시 root directory로 mount 됨
     : 각각의 파일 시스템은 마운트될 위치를 지정해 mount 명령으로 마운트시키거나 unmount 명령으로 언마운트(해체)할 수 있음
     ■ mount 과정
      ① 추가된 HDD가 정상적으로 인식되었는지 확인

       -> cat /var/log/dmesg | grep sdb
      ② 파티션 생성
       -> fdisk /dev/sdb
      ③ 파일 시스템 생성
       -> mkfs -t ext3 /dev/sdb1
      ④ 파일 시스템 마운트
       -> mkidr /home2  (Mount point 생성)
       -> mount -t ext3 /dev/sdb1 /home2 (새로 추가한 HDD를 /home2로 마운트)

    - 계층 개요
     


      ■ 가상 파일 시스템 (VFS : Virtual File System)
       : 표준 유닉스 파일 시스템이 제공하는 모든 시스템 콜을 처리하는 커널 소프트웨어 계층
       : 여러 종류의 파일 시스템에 대해 공통 인터페이스를 제공함


      ■ 디스크 파일 시스템 (Ext2,Ext3,Ext4 등)
       : 디스크나 입출력 장치에 정보를 저장하거나 입출력 및 검색 등을 하기 위한 계층

       : 장치에의 입출력이나 저장 형태 등, 장치에 의존적인 부분은 감추고 사용자에게 논리적이고 장치에 독립적인 쉬운 사용 인터페이스를 제공하기 위해 존재.


      ■ 페이지 캐시 (=Disk Cache)
       : 디스크의 정상적인 일부 데이터를 램이 보유하는 소프트웨어 메커니즘.
       : 
    Page라는 단위로 메모리에 일부 데이터를 저장.
       -> 한번 접근했던 데이터에 다시 접근할 때 디스크에 접근하지 않고 메모리에서 데이터를 읽음으로써 빠른 처리가 가능.

      ■ 일반 블록 계층 (Generic Block Layer)
       : 
    시스템 내 모든 블록 장치에 대한 요청을 다루는 커널 구성 요소
       : 
    일반 블록 계층은 각 하드웨어 블록 장치의 특징들을 숨겨서 블록 장치에 대한 추상적인 관점을 제공
       : 
    실제 입출력 연산을 위해 하위 구성 요소에 필요한 모든 정보를 준비하는 계층.

      ■ 
    I/O Scheduler Layer
       : 
    일반 블록 계층에서 넘어온 입출력 전송 요청을 커널 정책에 따라 정렬하는 계층
       : 
    I/O 스케줄러의 목적은 서로 가까운 I/O 요청을 그룹화 시켜서 디스크 탐색 오버헤드를 줄이는 것

      ■ (Block) Device Driver
       : I/O 스케줄러가 큐잉한 I/O 요청을 처리하는 계층. 요청을 해석하여 디스크 컨트롤러의 하드웨어 인터페이스에 적당한 명령을 보냄
       : 하드웨어(디스크) 인터럽가 발생했을 시 이를 처리할 수 있는 인터럽트 핸들러가 있음
     
      ∴ 각 계층 구조 동작

      



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

리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (7) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
리눅스 - 기초  (0) 2016.01.28
내장형 시스템 - 하드웨어  (0) 2016.01.26
  • System Call?




    - System Call Number


    - System Call 처리 과정




  • System Call 구현
    : "두 개의 정수 값을 더하여 결과 값을 반환"하는 System Call 구현









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

리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (7) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - 기초  (0) 2016.01.28
내장형 시스템 - 하드웨어  (0) 2016.01.26
  • 리눅스 커널 구조


    - 커널 구조에 따른 운영체제 구분
    ■ Monolithic 구조
      

     Micro-Kernel 구조
     

     

  • 리눅스 부팅 과정
      

  • Directory 구조
    : 리눅스 디렉토리 구조는 리눅스 커널의 소스 구조와는 다름
    - 리눅스 디렉토리 구조





    - 커널 소스 트리 구조



  • 리눅스 기본 명령어
    :파일 관련압축 관련프로세스/시스템 관련

    기능

    사용법 

    예시 

     파일 목록 출력

     ls [option]

     ls 
     ls -al

     현재 디렉토리에서 다른 디렉토리로 경로 변경

     cd 디렉토리 
     cd /디렉토리

     cd / ,cd .. 
     cd Downloads

     파일을 다른 파일명 또는 다른 디렉토리로 복사

     cp [option] source_file destination_file

     cp [option] source_file destination_directory

     cp -r Downloads backup

     파일을 다른 디렉토리로 이동하거나 다른 이름으로 변경

     mv [option] source_file destination_file

     mv [option] source_file destination_directory

     mv -i Downloads/helloworld.c backup

     파일 삭제

     rm [option] file

     rm [option] source_file destination_directory

     rm *
     rm -r backup, rm -i Downloads/helloworld.c

     새로운 디렉토리 생성

     mkdir [option] directory_name

     mkdir sub1 sub2 sub3

     디렉토리 삭제 rmdir [option] directory_name rmdir sub1
     현재 디렉토리명 표시 pwd [option]  
     텍스트 파일의 내용 출력 cat [option] file  cat etc/default/grub
     텍스트 파일의 내용을 화면에 한 페이지씩 출력 more [option] file  Space - 다음 페이지 출력, b - 이전 페이지로 이동
     q - 출력 중지 
     빈 파일을 생성하거나 파일의 수정 시간 변경 touch [option] file  touch test_file 
     리눅스 파일 권한 변경 chmod [options] mode[,mode] file1 [file2 ...]

     chmod 777 Downloads/helloworld.c
     chmod -R 707 /bin/su
     여러 파일이나 디렉토리를 묶거나 푼다.
     
     tar [option] file [directory]
        -c : 하나의 파일로 묶기
        -x : 묶인 파일 풀기
        -v : 파일을 묶거나 풀 때 진행 과정을 상세히 표시
        -t : 묶음 파일에 있는 내용 표시. 실제 묶음 파일을 풀지 않는다.
        -f : 묶음 파일명 .tar 명령어를 사용할 때 반드시 사용
        -z : gzip 관련하여 압축/복원을 동시에 수행 
     tar cvf test.tar test
     tar xvf test.tar (압축 기능은 없다)
     tar xvfz test.tar
     tar tf test.tar
     파일 압축/해제 유틸리티 – 압축 후 파일 확장자는 .gz가 붙는다 gzip [option] file
     gunzip [option] file
     gzip test.tar
     현재 진행 중인 프로세스에 대한 정보 출력 ps [option]   ps -efu
     현재 실행 중인 프로세서의 시스템 자원 사용 현황 표시 top [option] 
     실행 중인 프로세스를 종료 kill [option] process ID  kill -9 4647
     다른 사용자 계정으로 로그인 su - [login ID] [option]  su -
     su - swmem
     다른 계정의 권한이 요구될 때, 그 계정으로 직접 로그인하지 않고 해당 계정의 권한으로 작업을 수행  sudo command
     sudo -u user_name command
     sudo vi /etc/shadow
     시스템을 종료할 때 일반적으로 사용되는 명령
     시스템 리부팅
     shutdown [option] time [message]
     shutdown now
     reboot

  • Make Utility




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

리눅스 - 가상 파일 시스템  (0) 2016.01.28
리눅스 - 파일 디스크립터  (7) 2016.01.28
리눅스 - 파일 시스템  (0) 2016.01.28
리눅스 - System Call  (0) 2016.01.28
내장형 시스템 - 하드웨어  (0) 2016.01.26

+ Recent posts