수안이의 컴퓨터 연구실

/proc파일 시스템은 커널메모리 영역에 직접 데이터를 읽고 쓸수 있다는 점때문에 커널 모듈프로그램을 작성하는데 유용하게 사용할 수 있다. 이 기사에는 관련 함수들에 대한 설명과 이를 응용한 간단한 예제를 포함하고 있다.

1절. 소개
2절. 왜 proc파일시스템을 이용하는가
2.1절. 파일 시스템 오버헤드를 줄일 수 있다.
2.2절. 물리적인 파일시스템 장치를 필요로 하지않는다
2.3절. 최적화된 파일작업 수행
3절. proc 파일시스템을 어디에 사용할 수 있을까
3.1절. 커널 모듈 프로그래밍
3.2절. 임베디드 프로그래밍
4절. proc 프로그래밍
4.1절. proc 구조체 및 API
4.1.1절. proc_dir_entry 구조체
4.2절. proc API
4.2.1절. create_proc_entry
4.2.2절. create_proc_read_entry
4.2.3절. create_proc_info_entry
4.2.4절. proc_mkdir
4.2.5절. proc_symlink
4.2.6절. remove_proc_entry
4.3절. 기타 포장 함수들
4.3.1절. proc_net_create
4.3.2절. proc_net_remove
4.4절. 일반 유저와의 데이터 교환
4.4.1절. 데이터 읽기
4.4.2절. 데이터 쓰기
4.5절. Proc파일 시스템을 이용한 예제

--------------------------------------------------------------------------------

1절. 소개
유닉스에서 사용되는 proc파일 시스템은 운영체제의 각종 정보를 커널모드가 아닌 유저모드에서 쉽게 접근할 수 있도록 만들어 줌으로 시스템 정보를 일반 프로그래머가 쉽게 접근 할 수 있도록 도와준다.

특히 리눅스에서는 프로세스 정보뿐만 아닌 다른 시스템 정보들까지 광범위 하게 제공해 준다. 이말은 proc파일시스템을 제대로 이해할 경우 리눅스 운영체제를 좀더 깊이 있게 다룰 수 있다는 말이 된다. 실제 ps와 같은 프로세스 상황감시에서 부터, CPU사용율, 인터럽트, 네트워크 패킷전송량, 적재된 모듈, IDE-SCSI와 같은 장치정보, CPU정보등의 데이터를 어렵지 않게 얻어 올 수 있다. 다른 대부분의 유닉스에서 이러한 정보를 얻어올려면 상당한 애로사항을 격게 될것이다.

이제 proc파일시스템에서 데이터를 읽어오는 것을 지나서 proc파일 시스템에 필요한 데이터를 쓰는 방법에 대해서 알아보도록 하겠다.


--------------------------------------------------------------------------------

2절. 왜 proc파일시스템을 이용하는가
우리는 이미 일반 파일 시스템을 이용해서 필요한 데이터를 남기는 방법을 알고 있다. read(2), open(2), write(2) 이 3개의 함수만 사용할 줄 안다면, 필요한 모든 데이터를 읽고 쓰는데 별 부족함이 없다. 그렇다면 왜 굳이 proc파일시스템을 이용해야 하는지에 대해서 알아 보도록 하겠다.


--------------------------------------------------------------------------------

2.1절. 파일 시스템 오버헤드를 줄일 수 있다.
일반적으로 사용되는 파일 시스템은 상당한 오버헤드를 가지고 있다. 각 파일의 inode와 superblocks와 같은 객체를 관리해야 하며 이러한 정보를 필요할때 마다 운영체제에 요청해야 한다. 이들 파일 시스템의 데이터들은 서로 어긋날수도 있으며, 단현화 현상등이 발생할 수도 있다. 운영체제는 이러한 모든 것을 관리해 주어야 하며, 당연히 상당한 오버헤드가 발생하게 된다.

proc파일 시스템은 이러한 일반 파일시스템의 문제점을 없애기 위해서 리눅스 커널에서 직접 파일시스템을 관리하는 방법을 채택하고 있다.

지금 여러분의 리눅스 시스템에서 mount명령을 내리면 다음과 같이 proc 파일 시스템이 자동으로 마운트 되어 있는 것을 확인할 수 있을 것이다. # mount
/dev/hda7 on / type ext3 (rw)
none on /proc type proc (rw)
/dev/hda5 on /usr type ext3 (rw)
...
                       

여러분이 최초에 리눅스 운영체제를 설치할 때 proc파일 시스템을 위해서 별도로 파티션작업을 한적이 없을 것이므로 mount정보에 표시되는게 이상할 수도 있을 것이다. 이유는 앞에서 말했듯이 proc파일 시스템은 리눅스 커널에서 직접 관리하는 것으로 운영체제가 부팅 되었을 때 생성되는 파일 시스템이기 때문이다. mount정보를 보면 알겠지만 어떤 장치에도 마운트되어 있지 않음을 확인할 수 있다. proc파일 시스템은 커널메모리에서 돌아가는 일종의 가상 파일 시스템이다.

메모리에서 그것도 커널이 직접관리를 하게 되니.. 당연히 빠를 수 밖에 없다.


--------------------------------------------------------------------------------

2.2절. 물리적인 파일시스템 장치를 필요로 하지않는다
/proc는 커널메모리에서 유지하는 파일 시스템이다. 때문에 별도의 장치(하드디스크 같은)을 필요로 하지 않는다. 이러한 특징은 임베디드시스템을 설계하고자 할때 중요한 요소가 된다.


--------------------------------------------------------------------------------

2.3절. 최적화된 파일작업 수행
일반적인 파일 시스템 계층은 은 프로그래머를 위해서 POSIX 형식의 인터페이스를 제공한다. open, read, write, close등이 이것이다. 데이터 블럭들은 용이한 확장을 위해서 추상화 되어 있으며 상속가능한 형태로 구성된다.

이러한 일반 파일 시스템은 대용량의 데이터를 다루어야 하는 경우 매우 유용하지만, 고정적이고 처리해야할 데이터의 양이 적은 분야에는 오히려 비효율적이다. proc파일 시스템에서 다루어야 할 정보는 대부분 정해져 있으며, 데이터의 양도 그리 많지 않다. 고로 일반 파일시스템에서 제공하는 인터페이스를 사용하지 않고 필요한 작업에 최적화된 인터페이스를 사용할 수 있다.


--------------------------------------------------------------------------------

3절. proc 파일시스템을 어디에 사용할 수 있을까
2절에서 proc 파일시스템을 사용했을 때 얻을 수 있는 잇점에 대해서 알아보았다. 그럼 어느 용도에 유용하게 사용할 수 있을지에 대해서 알아보자.


--------------------------------------------------------------------------------

3.1절. 커널 모듈 프로그래밍
proc파일 시스템(이하 proc) 자체가 커널과 밀접하게 연관있는 이유로 일반 애플리케이션에서 proc를 사용하는 일은 드물다. 위에서 설명 했듯이 커널메모리에서 proc를 유지하게 되므로 많은 양의 데이터를 처리하는 애플리케이션의 용도와는 맞지 않다는 점도 있다.

그런점에서 proc는 커널모듈과 같이 커널과 밀접하게 관계있는 프로그램에서 유용하게 사용할 수 있다. 커널 모듈 프로그램은 주로 장치를 올리기 위한 용도로 사용되는데, 커널 레벨에서 작동하다 보니 모듈의 작동상황이나 성능등을 알아오기가 그리 쉽지 않다. 그렇다고 해서 일반 파일 시스템을 IPC를 사용하는 것 역시 그리 좋은 생각은 아니다. 이럴 때 proc를 이용하면 문제를 깔끔하게 해결 할 수 있다.


--------------------------------------------------------------------------------

3.2절. 임베디드 프로그래밍
임베디드 시스템은 파일 시스템을 가지지 않는 경우가 많거나 가지고 있다고 하더라도 매우 제한적인 경우가 많다. 이럴 때 proc를 이용해서 관리자 환경이라든지 데이터 입출력 환경을 만들 수 있다.

물론 이경우는 리눅스커널을 기반의 임베디드 환경에 해당된다.


--------------------------------------------------------------------------------

4절. proc 프로그래밍
이번장에서는 커널에서 제공하는 proc API들에 대해서 살펴볼 것이다. 다루어 지는 내용들은 커널 2.4.x를 기준으로 하고 있다.


--------------------------------------------------------------------------------

4.1절. proc 구조체 및 API
4.1.1절. proc_dir_entry 구조체
proc에 있어서 가장 중요한 구조체로써 다음과 같이 정의되어 있다.
struct proc_dir_entry {    unsigned short low_ino;    unsigned short namelen;    const char *name;    mode_t mode;    nlink_t nlink;    uid_t uid;    gid_t gid;    unsigned long size;    struct inode_operations * proc_iops;    struct file_operations * proc_fops;    get_info_t *get_info;    struct module *owner;    struct proc_dir_entry *next, *parent, *subdir;    void *data;    read_proc_t *read_proc;    write_proc_t *write_proc;    atomic_t count;     /* use count */    int deleted;        /* delete flag */    kdev_t  rdev; };
                               

name은 proc파일의 이름이다. mode는 proc파일의 권한으로 일반파일에 사용되는 권한과 동일하게 사용할 수 있다. mode에 대한 자세한 내용은 stat(2)의 man페이지를 참고하기 바란다.

struct proc_dir_entry *next ...는 proc파일이 위치하는 디렉토리로 일반 파일에서의 디렉토리 권한과 동일하게 사용되며, 링크드 리스트로 관리된다.

data proc에서 읽은 데이터를 리턴하기 위해서 사용된다.

read_proc, write_proc 유저영역의 프로세스는 직접 커널영역에 데이터를 읽거나 쓸수 없다. 때문에 모듈 프로그램등이 중간에서 커널과 유저영역 사이의 데이터전달을 해주어야 한다. 이러한 데이터 전달은 callback함수를 통해서 이루어진다. read_proc는 커널로 부터 읽은 데이터를 유저영역 프로세스로 되돌려주기 위해서 write_proc는 유저역역 프로세스에서 쓴데이터를 커널메모리 영역으로 복사하기 위해서 사용한다.


--------------------------------------------------------------------------------

4.2절. proc API
proc는 사용하기 간단한 몇개의 API만을 제공하는데, 이들 API는 커널의 메이저 버젼에 따라서 차이가 있을 수 있다. 만약 여러분이 2.4.x외의 다른 커널 버젼을 사용하길 원한다면 해당 커널버젼의 커널 문서를 참고해야 할 것이다. 그렇다고 해서 이 문서가 전혀 필요 없지는 않을 것이다. 대부분의 경우 커널의 메이저 버젼이 업그레이드 된다고 하더라도 함수 API가 아주 크게 변하는 경우는 없기 때문이다. 이 문서를 익혀 놓는다면 다른 커널 버젼에도 쉽게 적응할 수 있을 것이다.


--------------------------------------------------------------------------------

4.2.1절. create_proc_entry
struct proc_dir_entry *create_proc_entry (    const char *name,    mode_t     mode,    struct proc_dir_entry *parent); );
                               

이 함수는 첫번째 인자인 name을 이름으로 하는 proc파일을 생성한다. mode는 생성 될때의 파일 모드로 open(2)에 사용되는 것과 동일하게 사용된다. mode에 대한 자세한 내용은 man페이지를 참고하기 바란다.

마지막 인자인 parent는 name로 만들어진 proc파일이 위치할 디렉토리다. proc파일은 루트디렉토리가 "/"아닌 "/proc"에서 부터 시작하게 된다. 만약 NULL이라면 /proc 디렉토리 밑에 위치하게 된다.


--------------------------------------------------------------------------------

4.2.2절. create_proc_read_entry
static inline struct proc_dir_entry *create_proc_read_entry (    const char *name,    mode_t mode,    struct proc_dir_entry *base,    read_proc_t * read_proc,    void *data );
                               

이 함수는 create_proc_entry의 포장(wrapper)함수다.
static inline struct proc_dir_entry *create_proc_read_entry (    const char     *name,    mode_t         mode,    struct proc_dir_entry *base,    read_proc_t  *read_proc,    void         *data ) {    struct proc_dir_entry *res = create_proc_entry(name, mode, base);    if (res)    {        res->read_proc = read_proc;        res->data=data;    }   return res; }
                               

create_proc_read_entry는 쉽게 읽기용 proc파일을 만들 수 있도록 도와준다.


--------------------------------------------------------------------------------

4.2.3절. create_proc_info_entry
static inline proc_dir_entry *create_proc_info_entry (    const char *name,    mode_t     mode,    get_info_t *get_info );
                               

마찬가지로 create_proc_entry의 포장함수이다.
ststic inline struct proc_dir_entry *create_proc_info_entry (    const char            *name,    mode_t                mode,    struct proc_dir_entry *base,    get_info_t            *get_info ) {    struct proc_dir_entry *res = create_proc_entry (name, mode, base);    if (res) res->get_info = get_info;    return res; }
                               


--------------------------------------------------------------------------------

4.2.4절. proc_mkdir
proc파일 시스템에 디렉토리를 생성한다. 만들어 지는 디렉토리는 proc파일 시스템의 최상위 디렉토리(/proc)를 기준으로 한다.
extern struct proc_dir_entry *proc_mkdir (    const char *dir_name,    struct proc_dir_entry *parent )
                               




--------------------------------------------------------------------------------

4.2.5절. proc_symlink
심볼릭 링크를 만들기 위해서 사용된다. 단지 실제 사용자(real user)만이 사용가능하다.
extern struct proc_dir_entry *proc_symlink (    const char    *file_name,    struct proc_dir_entry *parent,    const char    *symlink_name   );
                               




--------------------------------------------------------------------------------

4.2.6절. remove_proc_entry
커널 모듈 프로그램밍시 celanup_module()함수에서 proc 파일을 지워주지 않을 경우 시스템에 좋지 않은 영향을 미칠 수 있다. 일단 proc를 생성했다면 프로그램 종료시 반드시 이 함수를 호출해서 proc파일을 지워주도록 하자.

extern void *remove_proc_entry (    const char            *name,    struct proc_dir_entry parent );
                               




--------------------------------------------------------------------------------

4.3절. 기타 포장 함수들
모듈 프로그래밍시 proc파일 시스템은 매우 자주 이용된다. 그러므로 이왕이면 쓰기편한 함수들이 준비되면 좋을 것이다. 여기에서 설명하는 함수들은 기존의 proc함수들을 사용하기 편하도록 포장한 함수들이다.


--------------------------------------------------------------------------------

4.3.1절. proc_net_create
이 함수는 create_proc_info_entry의 /proc/net정보에 대한 포장함수이다. 네트워크 서브시스템에 대해서 쉽게 접근하도록 도와준다.
static inline struct proc_dir_entry *proc_net_create (    const char *name,    mode_t     mode,    get_info_t *get_info ) {    return create_proc_info_entry(name, mode, proc_net, get_info); }
                               




--------------------------------------------------------------------------------

4.3.2절. proc_net_remove
네트워크 서브 시스템에 대한 remove_proc_entry의 포장함수이다.
static inline void proc_net_remove(const char *name) {    remove_proc_entry(name, proc_net) }
                               




--------------------------------------------------------------------------------

4.4절. 일반 유저와의 데이터 교환
일반 파일에서 유저와의 데이터 교환은 매우 단순하며, 별로 신경쓸 필요도 없다. 프로그램이 파일에 쓴 내용 그대로를 유저가 보며, 유저가 파일에 쓴 내용그대로를 다시 프로그램이 읽어들인다.

그러나 proc파일 시스템에서의 데이터는 실제 파일에 저장되는 것과는 달리 커널메모리에 저장된다. 알다 시피 커널메모리는 유저레벨 에서 직접 접근할 수 없다. 유저가 cat(혹은 read함수)등을 통해서 파일의 내용을 읽을려고 하면 커널에서 데이터를 유저에게 일정한 포맷으로 뿌려주게 된다. 마찬가지로 유저가 어떤 내용을 proc파일에 쓰게되면 데이터를 받아들인후 가공해서 커널메모리에 적재하게 된다.

이를 위해서 커널과 일반유저 사이에 데이터를 서로에게 전달해 주는 어떤 함수가 필요하고 이 함수가 다룰 수 있는 표준적인 자료구조가 있어야 한다. 유저가 데이터를 읽고 쓰기 위해서는 읽기와 쓰기를 위한 callback함수를 등록시켜서 사용 해야한다.

struct proc_dir_entry *entry; entry->read_proc = read_proc_foo; entry->write_proc = write_proc_foo;
                       

위에서 처럼 pric_dir_entry에 읽기/쓰기를 위한 콜백함수를 등록하면 된다.


--------------------------------------------------------------------------------

4.4.1절. 데이터 읽기
콜백함수로 등록되는 읽기함수는 유저영역 프로세스의 요청을 받으면 커널로 부터 데이터를 읽어들여서 알맞은 포맷으로 변경한다음 유저영역 프로세스로 되돌려준다. 읽기함수는 다음과 같은 모습을 가진다.
int read_func(char* page, char** start, off_t off, int count, int* eof, void* data);
                               

읽기함수는 일어들인 정보를 page에 쓰게 된다.


--------------------------------------------------------------------------------

4.4.2절. 데이터 쓰기
쓰기 콜백함수는 유저영역 프로세스로 부터 데이터를 받은다음 커널이 읽기에 적당한 형식으로 변경후 커널에 넘겨준다. 쓰기함수는 다음과 같은 모습을 가진다.
int write_func(struct file* file, const char *buffer, unsigned long count, void *data);
                               

쓰기함수는 buffer로 부터 유저가 쓴 데이터를 읽어들인다. buffer는 유저 데이터 이므로 copy_from_user을 이용해서 커널메모리영역으로 데이터를 복사한다.


--------------------------------------------------------------------------------

4.5절. Proc파일 시스템을 이용한 예제
그럼 간단한 예제를 만들어 보도록 하겠다. 예제는 일반 애플리케이션이 아닌 커널 모듈 프로그램이다. 커널 모듈프로그래밍에 대한 내용은 커널 모듈 프로그래밍을 참고하기 바란다.

프로그램의 이름은 my_proc.c로 하겠다. 이 모듈은 proc파일 시스템에 myproc라는 디렉토리를 만들고 이 모듈 아래에 foo와 jiffies라는 파일을 만든다. 만약 유저가 cat등을 통해서 이들 파일을 열면 모듈은 모듈 정보를 적당한 포맷으로 만들어서 사용자에게 보여주게 된다. foo파일의 경우에는 파일에 내용을 쓸수도 있도록 되어 있어서 사용자가 내용을 바꾸면 이 내용은 모듈에서 읽어 들이게 된다.

여러분이 커널 모듈 프로그래밍에 대한 이해가 있다는 가정하에 설명은 주석으로 대신하도록 하겠다. 모듈에서 main()함수에 해당하는 module_init()함수에서 차근차근 분석해나가면 좀더 쉽게 이해할 수 있을 것이다.

예제 : myproc.c
#include <linux/module.h> #include <linux/tty.h> #include <linux/init.h> #include <linux/kernel.h> #include <linux/proc_fs.h> #include <linux/sched.h> #include <asm/uaccess.h> #define MODULE_VERSION        "1.0" // 모듈의 이름이다. // 이 모듈이름으로 /proc밑에 디렉토리가 생성된다. #define MODULE_NAME                "myproc" // 생성된 /proc/MODULE_NAME 밑에 아래 2개의 파일이 // 생성된다. #define FOO_FILE                "foo" #define JIFFIE_FILE                "jiffies" #define FOOBAR_LEN 8 // foo 파일에 저장될 데이터 구조체 struct fb_data_t {        char name[FOOBAR_LEN + 1];        char value[FOOBAR_LEN + 1]; }; struct fb_data_t foo_data; static struct proc_dir_entry *example_dir, *foo_file, *jiffies_file; // 사용자가 cat등을 통해서 /proc/[MODULE_NAME]/jiffies파일을 열면 // 커널은 이 함수를 호출해서 해당 정보를 넘겨준다. static int proc_read_jiffies(char *page, char **start, off_t off,                           int count, int *eof, void *data) {        int len;        MOD_INC_USE_COUNT;        // 사용자가 이해하기 쉬운 포맷으로 만든다.        // cat, vi등을 사용해서 이 파일을 열경우        // jiffies = 1234 와 같은 형식으로 보인다.        len = sprintf(page, "jiffies = %ld\n", jiffies);        // 해당 내용을 printk를 통해서 로그로 남긴다.          // 이 데이터는 /var/log/message로 출력된다.        printk("<1> read jiffies = %ld\n", jiffies);        MOD_DEC_USE_COUNT;        return len; } // 사용자가 /proc/[MODULE_NAME]/foo 파일을 열었을 때 // 출력해주는 정보 static int proc_read_foobar(char *page, char **start, off_t off,                                                        int count, int *eof, void *data) {        int len;        struct fb_data_t *fb_data = (struct fb_data_t *)data;        MOD_INC_USE_COUNT;        // fb_data구조체의 내용을 보시쉽게 만들어서 출력해준다.        len = sprintf(page, "%s = %s",                                        fb_data->name, fb_data->value);        MOD_DEC_USE_COUNT;        return len; } // 사용자는 /proc/[MODULE_NAME]/foo에 내용을 쓰기를 원할때도 있을 것이다. // 이 때 이함수가 호출된다. static int proc_write_foobar(struct file *foke, const char *buffer,                                                        unsigned long count, void *data) {        int len;        struct fb_data_t *fb_data = (struct fb_data_t *)data;        MOD_INC_USE_COUNT;        if (count > FOOBAR_LEN)                len = FOOBAR_LEN;        else                len = count;        printk("<1> DATA COPY %d\n", len);        // echo "xxxxx" > /proc/[MODULE_NAME]/foo 등으로 입력받은 값을        // fb_data->value에 저장한다.        if (copy_from_user(fb_data->value, buffer, len))        {                MOD_DEC_USE_COUNT;                return -EFAULT;        }        fb_data->value[len] = 0x00;        MOD_DEC_USE_COUNT;        return len; } // 커널 모듈 초기화 함수 static int init_myproc(void) {        int rv = 0;        printk("<1> Module Start\n");        example_dir = proc_mkdir(MODULE_NAME, NULL);        if (example_dir == NULL)        {                rv = -ENOMEM;                printk("<1> mkdir failure\n");                goto out;        }        // JIFFILE파일의 경우 단지 읽기만 허용한다.        example_dir->owner = THIS_MODULE;        jiffies_file = create_proc_read_entry(JIFFIE_FILE, 0444, example_dir,                                                                        proc_read_jiffies, NULL);        if (jiffies_file == NULL)        {                rv = -ENOMEM;                printk("<1> read entry failure\n");                goto no_jiffies;        }        printk("<1> OK MAKE MODULE\n");        jiffies_file->owner = THIS_MODULE;        // FOO_FILE의 경우 읽기와 쓰기 모두 가능해도록 해야 하며        // 각각의 경우에 호출될 함수를 지정해 줘야 한다.        foo_file = create_proc_entry(FOO_FILE, 0644, example_dir);        if (foo_file == NULL)        {                rv = -ENOMEM;                goto no_foo;        }        strcpy(foo_data.name, "foo");        strcpy(foo_data.value, "dream");        // 커널 자료구조에 저장될 데이터        foo_file->data = &foo_data;        // 읽기를 요청했을 때 호출될 함수        foo_file->read_proc = proc_read_foobar;        // 쓰기가 요청되었을 때 호출될 함수        foo_file->write_proc = proc_write_foobar;        foo_file->owner = THIS_MODULE;        printk("<1> %s %s initialised\n", "myproc", "1.0");        // 제대로 초기화가 이루어졌다면 0을 리턴해야 한다.        return 0;        no_foo:                remove_proc_entry(FOO_FILE, example_dir);        no_jiffies:                remove_proc_entry(MODULE_NAME, NULL);        out:                return rv; } // cleanup 함수 static void cleanup_myproc(void) {        printk("<1> END\n");        remove_proc_entry(FOO_FILE, example_dir);        remove_proc_entry(JIFFIE_FILE, example_dir); } module_init(init_myproc); module_exit(cleanup_myproc); MODULE_AUTHOR("yundream"); MODULE_DESCRIPTION("Sanmpe proc");
                       



다음은 위 프로그램을 컴파일 하기 위한 make파일이다.

Makefile WARN    := -W -Wall -Wstrict-prototypes -Wmissing-prototypes    
INCLUDE := -isystem /lib/modules/`uname -r`/build/include    
CFLAGS  := -O2 -DMODULE -D__KERNEL__ ${WARN} ${INCLUDE}    
CC      := gcc                                
TARGET  := my_proc
   
my_proc.o: my_proc.c
       ${CC} ${CFLAGS} -c my_proc.c
                                   
.PHONY: clean                                                      
                                         
clean:                                    
       rm -rf ${TARGET}.o    
                       



insmod를 이용해서 모듈을 올린후 cat, echo 등을 통해서 직접 테스트가 가능하다. # echo "okok" > /proc/myproc/foo
# cat /proc/myproc/foo
foo = okok
                       

작성된 모듈프로그램의 작동상황은 /var/log/message의 내용을 확인하면 된다. 만약 syslog와 klogd가 떠있다면 tail등의 도구를 이용해서 모듈작동상황을 확인할 수 있을 것이다.



출처 : http://joinc.co.kr/modules.php?name=new ··· 3Dnested

데이터 문제에 대한 차세대 NFS 계열 파일 시스템 대안
난이도 : 초급


Frank Pohlmann
U.K. Technical 편집자 및 개발자, LinuxUser and Developer
2005년 5 월 17 일

분산 파일 시스템은 최근까지 많은 이슈는 없었다. 이를 사용하는 것이 대개는 기업과 교육 네트워크이기 때문이다. 시스템이 오픈 소스 파일 시스템 퍼즐에 어떻게 맞는지는 개념상으로 언제나 명확한 것은 아니다. Open Andrew File System (OpenAFS)은 Network File System (NFS)의 성숙한 대안이다.
사용자들은 파일 시스템의 개념을 두 가지 방식으로 이해한다. 첫 번째는 파일과, 그 파일을 포함하고 있는 디렉토리, 그리고 디렉토리 구조를 보유한 파티션으로 구성하는 방식이다. 그리고 두 번째는, 파일 시스템은 파일들이 미가공 금속으로 조직화 또는 매핑되는 방식이다. 원래는 가상 파일 시스템(VFS) 레이어와 실제 메모리 관리 루틴 처럼 중간에 존재하는 레이어이지만 사용자가 접근할 수 있는 구조화된 정보를 관리하는 것과 관련해서는 파워 유저가 파일 시스템 내부를 들여다 보고 커널의 후미진 곳 까지 파악하도록 하는 것이 이치에 맞는다.

메탈은 RAM 또는 하드 디스크로 구성되지만, 어떤 경우에는 파일 시스템 데이터 구조는 하드웨어 제조자들이 만든 섹터와 바이트로 구성된다. 보다 원시적인 경우는, 사용자들이 스스로 개념상 이를 쪼갤 수도 있다. 큰 사이즈의 파일에 액세스 할 때 속도를 높일 수 있는 툴도 있다. 또한 디렉토리와 파일을 재구성할 수 있는 툴도 있는데 이 툴들은 비트, 바이트, 섹터로부터 안전하다.

파일 시스템 개념
이러한 개념적 정의의 고전적인 경우는 FreeBSD—유닉스의 BSD—가 UNIX File System V2 (UFS2)를 사용하여 디스크 상의 데이터를 구성하고, Flash File System (FFS)을 사용하여 파일을 디렉토리로 구성하고 디렉토리 액세스를 최적화하던 방식이다. 리눅스는 원래 두개 이상의 파일 시스템 보다 더 많은 것을 허용하기 때문에 약간 다르게 작동한다. 따라서 VFS 레이어에서는 리눅스 사용자가 리눅스가 메모리를 관리하는 방식에 구애 받지 않고 새로운 파일 시스템 지원을 추가할 수 있다.

정적 그리고 저널 파일 시스템에 대서 나중에 이야기 할 때, 영속성과 더 나아가서 파일 시스템 콘텐츠의 보안에 대해 강조할 것이다. BSD UNIX 관점에서 보면 정적 저널 파일 시스템들은 UNIX File System (UFS)이 파일을 구성하고 보안화 하는 방식과 관련이 있다. 비록 리눅스 파일 시스템들이 Journal File System (JFS), 차세대 파일 시스템 (XFS), 초기 ReiserFS들을 사용할 수 있을 때부터 저널 파일 시스템들을 포함하긴 했지만 기술적 저널리즘 이나 기업 공공성이 빛을 발하지 않은 또 다른 영역은 분산 파일 시스템이다.

NFS에서 내가 배운 것
대규모의 사용자들에게 TCP 또는 User Datagram Protocol (UDP)을 통해 사용할 수 있는 네트워크 중심의 파일 시스템 레이어를 만드는 것은 신중하지 못한 것처럼 보인다. pre-V3 NFS 관련 공포 시나리오는 10명 남짓의 사용자들로 네트워크를 관리하는 많은 관리자들을 고생시킨다. 게다가 매우 빠른 마더보드 아키텍쳐로 지원되는 다중 프로세서 아키텍쳐의 출현은 분산 파일 시스템 문제를 우선순위 밖으로 밀어낸다. 속도는 지능적으로 구현된 분산 시스템들이 아닌 하드웨어로 보장된다. 분산 파일 시스템들이 기저의 파일 시스템 구현- ext2, ext3, ReiserFS 파일 시스템 드라이버-들에 의존한다면 분산 파일 시스템들은 큰 대학 네트워크와 과학 또는 기업 네트워크로 제한될 것이다.

그렇다면 분산 파일 시스템은 우리가 언급했던 두 개 중 상단에 있는 제 3의 레이어인가? 현대 네트워킹의 큰 문제 중 하나는 이종의 네트워크를 결합해야 한다는 점이다. (Samba가 대표적인 예이다.) 하지만 파일 시스템 퍼즐에 세 개의 주요한 플레이어가 있다는 것을 이해해야 한다: Microsoft® Windows® 파일 시스템 군 (FAT16, FAT32, NTFS 파일 시스템); Apple Mac OS X (HFS+); 그리고 원시 리눅스 저널 파일 시스템(대게ReiserFS와 ext3). Samba는 Windows와 리눅스 파일 시스템의 협업을 돕지만 모든 주요 파일 시스템에 접근하여 관리할 수 있다는 것을 의미하지는 않는다.

어떤 사람들은 NFS V4를 이 문제를 해결 때 시도하지만 NFS V4를 다루는 Request for Comments (RFC) 3530은 아직 2년 밖에 되지 않았고, 2.6 커널용 NFS V4도 너무 어리기 때문에 제품 서버에 쓸 것을 권하기가 망설여진다. Fedora cores 2와 3은 NFS V4 패치와 NFS V4 유틸리티를 제공한다. 이것은 NFS가 더 많은 포트를 열고 사용자들에게 반출된 각 네임스페이스에 개별 클라이언트를 설정하는 것으로 네트워크 관리자들을 애를 먹인 이후로 개발자가 만들어 낸 현상이다. RFC 3530은 대부분 보안 문제만 언급한다. 아직도 NFS 디렉토리는 개별적으로 마운트되어야 한다. 통합 sign-on과 Kerberos를 사용하여 보안화 할 수 있지만 손질이 필요하다.

OpenAFS 논거
OpenAFS는 소프트웨어의 설치와 관리 고통을 제거한다. OpenAFS는 다른 파일 시스템들 끼리 효율적으로 협업하도록 돕는다. 비록 유닉스용 원래의 메타포와 이것의 매력적인 후계자 Plan 9는 파일이었지만 현대의 네트워크로 된 파일 시스템들을 완전히 다시 만들기 보다는 또 다른 분산 파일 시스템 레이어가 추가되었어야 했다.

카네기 멜론 대학교 프로그래머들은 1983년에 AFS를 개발했다. 그 뒤 바로, 이 대학은 Transarc라는 회사를 설립하여 AFS 기반 서비스를 팔았다. IBM은 1998년에 Transarc를 인수하여 AFS를 OpenAFS란 이름으로 오픈 소스 제품으로서 사용할 수 있도록 했다. 하지만 OpenAFS가 Coda와 Arla 같은 다른 분산 파일 시스템들을 만들어냈기 때문에 무용담은 여기가 끝이 아니다. OS 클라이언트들이 존재했고 문서도 충분하다. Gentoo.org는 OpenAFS에 노력을 기울여 리눅스 사용자들도 접근할 수 있도록 했다. 다른 조직들은 여전히 분산 파일 시스템이 필요할 때 NFS를 거론한다.

OpenAFS 아키텍쳐
OpenAFS는 셀로 알려진 파일 서버 그룹 주위에 조직된다. 각 서버의 아이디는 보통 파일 시스템 뒤에 숨겨진다. AFS 클라이언트의 형태로 로그인하는 사용자들은 어떤 서버에서 작업하고 있는지 말할 수 없다. 사용자 관점에서 보면 인식 가능한 유닉스 파일 시스템으로 하나의 시스템 상에서 작업하는 것이기 때문이다. 파일 시스템 콘텐트는 셀을 통해 복제되어 하드 디스크가 오류가 생긴다고 해서 OpenAFS의 클라이언트 작업에 지장을 주지 않는다. OpenAFS는 1 GB 정도의 클라이언트 캐싱 장치를 통해 자주 사용되는 파일에 접근할 수 있어야 한다. 이것 역시 완전히 보안화 된 Kerberos 기반 시스템으로서 작동한다. 이는 액세스 제어 리스트(ACL)을 사용하여 보통의 리눅스 및 유닉스 보안 모델 기반이 아닌 정교한 액세스를 가능하게 만든다.

기저 파일 시스템으로 ext2를 실행하는 OpenAFS의 일부가 되는 캐시 매니저를 제외하고 OpenAFS의 기본적인 구조는 요즘의 NFS 구현을 닮았다. 기본 아키텍쳐는 전혀 같아 보이지 않는다. NFS를 더 선호하는 사람들에겐 OpenAFS 장치를 활용하는 것이 더 좋지만 소위 NFS/AFS 트랜슬레이터를 사용할 수 있다. OpenAFS 클라이언트 머신이 NFS 서버 머신으로 설정되는 한 두 파일 시스템의 장점을 활용할 수 있어야 한다.

OpenAFS 방식
NFS는 위치 독립적이고 로컬 디렉토리들을 원격 파일 시스템 위치로 매핑한다. OpenAFS는 사용자들에게 파일 위치를 숨긴다. 모든 소스 파일들은 다양한 복제된 파일 서버 위치에 읽기-쓰기 카피로 저장되기 때문에 복제된 카피를 동시에 갖게 된다. Ubik이라고 하는 기술을 통해 이것이 가능하다. 동부 유럽과 유비쿼터스에서 사용한다. Ubik 프로세스는 AFS 파일 시스템 상에서 파일, 디렉토리, 볼륨을 동시에 관리하지만 세 개 이상의 파일 서버를 가진 시스템들이 효과를 볼 수 있다. 시스템 관리자는 여러 AFS 셀들을 그룹핑할 수 있다. 오래된 AFS는 OpenAFS 파일 시스템에 보관된다. 관리자는 AFS 셀의 양과 셀이 저장할 수 있는 한계와 그 사이트 내에 AFS 셀에서 사용할 수 있는 파일들을 결정해야 한다.

파티션, 볼륨, 디렉토리
AFS 관리자들은 셀을 볼륨으로 나눈다. 볼륨은 하드 디스크 파티션으로 확장가능하지만 대부분의 관리자들은 한 개의 볼륨으로 전체 파티션을 채우지는 않는다. AFS 볼륨은 실제로 Volume Manager 라고 하는 유닉스 유형의 프로세스로 관리된다. 유닉스 파일 시스템 디렉토리와 비슷한 방식으로 볼륨을 마운트 할 수 있다. 하지만 AFS 볼륨을 파일 서버에서 파일 서버로 옮길 수 있다. 하지만 유닉스 디렉토리는 파티션에서 파티션으로 물리적 이동이 불가능하다. AFS는 Volume Location Manager를 통해 볼륨과 디렉토리 위치를 자동으로 트래킹하고 복제된 볼륨과 파일을 계속 트래킹한다. 따라서 사용자는 파일 서버가 예상치 못하게 작동을 멈출 때 걱정하지 않아도 된다. AFS가 사용자를 다른 파일 서버 머신 상의 복제된 볼륨으로 변환하기 때문이다. 사용자는 이를 인식하지 못한다.

사용자들은 AFS 서버상에 위치한 파일에 대해 절대 작업하지 않는다. 클라이언트 측 캐시 매니저에 의해 파일 서버에 붙은 파일에 대해 작업한다. Cache Manager는 클라이언트 운영 체계 커널에 살아있는 재미있는 동물이다. 리눅스의 경우 패치가 커널에 추가된다. (2.4 커널에서 Cache Manager를 실행할 수 있다.)

Cache Manager
Cache Manager는 로컬 애플리케이션의 요청에 응답하여 AFS 파일 시스템을 통해 파일을 붙일 수 있다. 물론 파일이 종종 바꾸게 되는 소스 파일 이라면 여러 복제된 버전으로 존재하는 것은 이상적이지 못하다. 사용자는 빈번히 요청되는 소스 파일을 자주 변경할 수 있기 때문에 두 가지의 문제가 생긴다: 첫째, 파일은 클라이언트 캐시와 여러 파일 서버 머신 상의 여러 복제된 볼륨에 저장된다; 둘째, Cache Manager는 모든 볼륨을 업데이트 해야 한다. 파일 서버 프로세스는 콜백을 붙여 파일을 클라이언트 캐시로 보내서 시스템이 어딘가에서 일어난 모든 변경들을 처리할 수 있도록 한다. 사용자가 어딘가에서 캐시 된 복제된 파일에 변경을 추가하면 원래 파일 서버는 콜백을 활성화하고 원래 캐시 된 버전에 업데이트가 필요함을 상기시킨다.

분산 버전의 제어 시스템은 이러한 고전적인 문제에 직면해 있지만 중요한 차이가 있다: 분산 버전 제어 시스템은 연결이 해제될 때 완벽히 작동하지만 AFS는 파일 시스템의 일부를 잘라낼 수 없다. 개별 AFS 섹션은 원래 파일 시스템과 재연결 할 수 없다. 파일 서버는 오류가 여전히 실행중인 AFS 파일 서버로 다시 연결되도록 처리하지만 잘려나간 후에 로컬에서 보유하고 잇는 새로운 변경을 추가할 수 없다.

OpenAFS 대안
AFS는 새로운 파일 시스템에 대한 여러 시도의 출발점이다. 원래의 분산 파일 시스템 아키텍쳐에서 배운 교훈들을 두 개의 시스템들이 결합했다: Coda와 스웨덴의 오픈 소스 자원자들의 노력의 산물인, Arla 이다.

Coda 파일 시스템은 원래 AFS를 향상하려는 첫 번째 시도였다. 1987년에 카네기 멜론 대학에서 개발자들은 AFS를 Coda로 발전시켜 V2.0까지 이르렀다. 1980년대 후반과 90년대 초에 Coda 파일 시스템은 Venus라고 하는 다른 캐시 매니저를 선보였다. Coda의 기본적인 기능은 AFS와 비슷한 반면 Venus는 클라이언트가 분산 파일 시스템에서 연결이 끊어져도 Coda를 실행하는 크라이언트를 위해 계속 작동할 수 있다. Venus는 AFS Cache Manager와 같은 기능을 갖고 있다. 커널 내에 VFS에서 파일 시스템 작업을 가져온다.

Coda 서버들과 Venus 캐시 매니저들간 연결 해제가 네트워크 기능에 결정적인 것은 아니다. 랩톱 클라이언트는 중앙 서버에서 멀리 떨어져 작업할 수 있어야 한다. 따라서 Venus는 클라이언트 변경 로그에 모든 업데이트들을 저장한다. 캐시 매니저가 중앙 서버로 재연결 될 때 시스템은 클라이언트 변경 로그를 재통합하면서 모든 파일 시스템 업데이트들을 클라이언트가 사용할 수 있다.

연결 해제는 또 다른 문제를 만들 수 있지만 Venus 캐시 매니저는 분산된 파일 시스템들이, 연결된 상태로 실행되는 복잡한 네트워크들 보다 훨씬 더 많이 확장될 수 있음을 나타내고 있다.

프로그래머들은 1993년 이후 OpenAFS의 GPLed 구현을 제공하는 스웨덴 프로젝트인 Arla를 개발해왔다. 사실 대부분의 개발과 포트는 1997년 이후에 이루어졌다. XFS 파일 시스템이 Arla가 실행되는 모든 운영 체계에서 작동해야 한다는 것을 제외하고는 Arla는 OpenAFS를 아주 잘 모방했다. Arla는 V0.39까지 나왔고 OpenAFS처럼 모든 BSD에서 실행된다. kernel V2.0x과 Sun Solaris 이후 상당량의 리눅스 커널이다. Arla는 원래 AFS 코드에는 없었던 AFS의 기능을 부분적으로 구현한다. 연결 해제 작동이 바로 그것이다. 하지만 갈 길은 멀고 개발자들은 테스팅도 끝마치지 못했다.

GPLed InterMezzo 같은 기타 AFS 유형의 파일 시스템들도 사용 가능하다. 하지만 이것은 AFS 명령행 문법 또는 아키텍쳐를 복제하지 않았다. 오픈 소스 분산 파일 시스템의 세계는 매우 활동적이고 다른 분산 파일 시스템은 모바일 컴퓨팅에서 실행할 애플리케이션을 모색하고 있다.

http://www-128.ibm.com/developerworks/k ··· dex.html

dnotify를 대체할 2.6 커널의 파일 시스템 이벤트 모니터링 메커니즘
난이도 : 초급


Eli M. Dow
소프트웨어 엔지니어, IBM Linux Test and Integration Center
2005년 4 월 12 일

Inotify는 차기 리눅스 커널에 포함될 파일 시스템 모니터링 메커니즘으로서, 구 커널에서 지원되던 파일 모니터링 메커니즘이였던 dnotify의 강력한 대체재이다. Inotify는 강력하고 세련된 비동기식 메커니즘으로서 보안과 퍼포먼스 등 다양한 파일 모니터링의 필요를 이상적으로 채운다. Inotify를 설치하는 방법과 파일 시스템 이벤트에 응답하는 사용자 공간의 애플리케이션 샘플을 구현하는 방법을 설명한다.
파일 시스템 이벤트 모니터링은 파일 매니저에서 보안 툴에 이르기까지 다양한 유형의 프로그램들에 필수적인 것이지만, 이전 커널의 표준인 dnotify는 아쉽게도 제한이 많았다. 이제, 보다 현대적인 파일 시스템 이벤트-모니터링 대안인 Inotify를 만나보자.

왜 Inotify인가?
dnotify 대신 Inotify를 사용하는데는 많은 이유가 있다. 우선, dnotify는 변경사항을 보고자 할 때 각 디렉토리에 대한 한 개의 파일 디스크립터를 열어야 한다. 따라서, 여러 디렉토리들을 한번에 모니터링 할 때는 작업량이 많을 수 밖에 없다. 프로세스 당 파일 디스크립터 제한에 걸리기 때문이다.

게다가 파일 디스크립터는 디렉토리를 고정하기 때문에 지원 장치의 언마운트가 허용되지 않는다. 따라서 제거 가능한 미디어가 개입된 시나리오에서 문제가 발생한다. Inotify를 사용할 때, 언마운트 된 파일시스템 상의 파일을 보고자 한다면, 보기(watch)는 자동으로 제거되고 언마운트 이벤트를 받는다.

dnotify 보다 Inotify가 더 나은 두 번째 이유는 약간 복잡하다. dnotify 인프라를 사용하는 단순한 파일시스템-모니터링 세분성은 디렉토리 레벨에서만 존재한다. dnotify를 이용하여 보다 정밀한 모니터링을 하려면 애플리케이션 프로그래머들은 관찰되고 있는 각 디렉토리와 관련된 stat 구조의 캐시를 유지해야한다. stat 구조의 사용자 공간 캐시는 공지 신호를 받았을 때 디렉토리에 정확히 어떤 변화가 발생했는지를 결정하는데 필요하다. 공지를 받으면 stat 구조의 리스트가 생성되고 마지막 상태와 비교된다. 확실히 이는 최상의 방법은 아니다.

Inotify의 또 다른 장점은 기본 인터페이스로서 파일 디스크립터를 사용하여 애플리케이션 개발자들이 select와 poll 을 사용하여 장치 볼 수 있다는 점이다. 이로서 효율적인 다중화 I/O와 Glib의 mainloop와의 통합이 가능하다. 이와 반대로, dnotify는 프로그래머들이 어려워하는 신호를 사용하고 있다.

Inotify는 최소한의 파일 디스크립터를 사용하고 보다 세분화된 모니터링을 보장하는 등의 고급 기능을 제공하여 이러한 문제들을 해결한다. Inotify와의 통신은 디바이스 노트를 통해 이루어진다. 따라서, Linux 2.6에서 파일 모니터링을 할 때 선택을 분명히 해야 한다.

Inotify 설치하기
Inotify를 설치하는 첫 번째 단계는 현재 사용하고 있는 리눅스 커널이 이를 지원하는지의 여부를 결정하는 것이다. 배포판을 확인하는 가장 간단한 방법은 /dev/inotify 장치의 존재 유무를 확인하는 것이다. 이 장치가 있으면 애플리케이션에서 Inotify 사용하기섹션으로 이동하기 바란다.

이 글이 쓰여질 당시, Inotify는 Andrew Morton의 리눅스 Linux 2.6-mm 트리에 포함되었고 여러 리눅스 배포판들이 Inotify를 실행하는 커널(Gentoo와 Ubuntu)을 제공하고 있거나 또는 이를 지원하는 보조 커널 패키지를 갖고 있었다. (Fedora와 SuSE). Andrew가 트리에서 Inotify 지원을 제거할 수도 있고 Inotify를 제거하는 일은 개발 단계에서는 종종 있는 일이였기 때문에 처음부터 다시 붙이는 것을 권장한다.

이 장치가 없다면 커널을 패치하고 장치를 만들어야 한다.

Inotify용 커널 패치
Linux Kernel Archives (참고자료)에서 Inotify 패치를 얻을 수 있다.

자신의 커널에 해당하는 버전 숫자 중 가장 높은 숫자를 가진 패치를 적용해야 한다. 배포판마다 커널 설치를 약간 다르게 핸들하긴 하지만 여기에서는 일반적인 가이드라인을 설명하겠다: Note: 배포판의 2.6 리눅스 커널 소스나, Linux Kernel Archives에서 안정적인 최신 릴리스를 사용해야 한다.

우선 커널 소스 디렉토리로 간다:

bash:~$ cd /usr/src

앞서 커널 소스를 설치했기 때문에 이를 패킹을 푼다(unpack):

bash:~$ sudo tar jxvf linux-source-2.6.8.1.tar.bz2

symlink를 새로운 소스 트리로 만든다:

bash:~$ sudo ln -sf linux-source-2.6.8.1 linux

현재 디렉토리를 방금 만든 커널 소스 디렉토리로 변경한다:

bash:~$ cd linux

Inotify 패치를 복사한다:

bash:~$ sudo cp ~/inotify* /usr/src

커널을 붙인다(patch):

bash:~$ sudo patch -p1 < ../inotify*.patch

커널을 구현한다:

bash:~$ sudo make menuconfig

inotify 기능을 확인하면서 일반적인 방식으로 커널을 설정한다. 필요하다면 이 새로운 커널을 bootloader에 추가한다. 단 구 커널 이미지와 bootloader 옵션을 기억해야 한다. 이 단계는 bootloader 마다 다양하다. (bootloader 관련 추가정보는 참고자료 참조). 머신을 재부팅하고 inotify 기능이 추가된 커널을 선택한다. 새로운 커널을 테스트하여 올바르게 작동하는지 확인한다.

inotify 장치 만들기
다음에는, /dev/inotify 장치가 만들어졌는지를 확인해야 한다. 다음은 그 단계이다. Important note: 마이너 넘버(minor number)가 변경될 수 있기 때문에 최신 것인지를 부지런히 검토해야 한다. 자신의 리눅스가 udev 기능을 지원한다면 자동으로 업데이트 된다.

새로운 커널로 재부팅 한 후에, 마이너 넘버를 획득해야 한다:

bash:~$ dmesg | grep ^inotify

다음은 리턴된 예제이다:

inotify device minor=63

inotify는 misc 장치이기 때문에 메이저는 10이다. 다음 명령행을 실행하여 장치 노드를 root 사용자로 만든다:

bash:~$ mknod /dev/inotify c 10 63

Note: 필요할 경우 "63"을 적당한 마이너 넘버로 대체한다.

선택적으로 허가(permission)를 설정해야 한다. 허가 설정 샘플은 다음과 같다:

bash:~$ chown root:root /dev/inotify
bash:~$ chmod 666 /dev/inotify

이제 파일 시스템 모니터링을 위한 inotify 장치를 사용할 준비를 갖추게 되었다.

애플리케이션에서 Inotify 사용하기
파일 시스템 이벤트에 임의의 디렉토리를 감시하는 샘플 프로그램일 만드는 방법을 설명하겠다. inotify가 파일 시스템 모니터링을 얼마나 쉽게 만드는지를 보여줄 예정이다.

주 메소드
이 간단한 예제를 통해 임의의 디렉토리에 대한 watch를 설정하는 것이 얼마나 쉬운지를 보게 될 것이다. 주요 헬퍼 루틴은 나중에 설명하도록 하겠다. 여기에 사용되는 샘플 코드는 Download 섹션을 참조하기 바란다.

Listing 1. 디렉토리에 대한 watch 설정하기


/* This program will take as argument a directory name and monitor it,   printing event notifications to the console. */ int main (int argc, char **argv) {   /* This is the file descriptor for the inotify device */   int inotify_fd;   /* First we open the inotify dev entry */   inotify_fd = open_inotify_dev();   if (inotify_fd < 0)   {      return 0;   }   /* We will need a place to enqueue inotify events,      this is needed because if you do not read events      fast enough, you will miss them.   */   queue_t q;   q = queue_create (128);   /* Watch the directory passed in as argument      Read on for why you might want to alter this for      more efficient inotify use in your app.   */   watch_dir (inotify_fd, argv[1], ALL_MASK);   process_inotify_events (q, inotify_fd);   /* Finish up by destroying the queue, closing the fd,      and returning a proper code   */   queue_destroy (q);   close_inotify_dev (inotify_fd);   return 0; }



중요한 헬퍼 메소드
다음은 모든 inotify 기반 애플리케이션에 공통적으로 적용되는 가장 중요한 헬퍼 루틴들이다:

읽기를 위한 inotify 장치 열기
이 장치에서 읽혀지는 이벤트 큐잉(queuing)
애플리케이션들이 이벤트 공지를 사용하여 유용하게 일을 수행하도록 하는 이벤트 핸들러
여러 전략들이 사용될 수 있기 때문에 이벤트 큐잉에 대한 자세한 설명은 하지 않겠다. 멀티 쓰레디드 방식이 진화될수록 어디에서나 구현될 수 있다. 그와 같은 구현은 읽기 쓰레드가 inotify 장치에 대해 select()를 수행하고 그런 다음 이벤트를 몇몇 쓰레드가 공유된 스토리지(또는 Glib의 비동기식 메시지 큐)에 복사한다. 이곳은 핸들러 쓰레드가 실행되는 장소이다.

Listing 2. inotify 장치 열기


/* This simply opens the inotify node in dev (read only) */ int open_inotify_dev () {   int fd;   fd = open("/dev/inotify", O_RDONLY);   if (fd < 0)   {      perror ("open(\"/dev/inotify\", O_RDONLY) = ");   }   return fd; }



이것은 리눅스 시스템 상에서 파일들을 이용한 프로그래밍을 했다면 매우 익숙할 것이다.

Listing 3. 실제 이벤트-핸들링 루틴


/* This method does the dirty work of determining what happened,   then allows us to act appropriately */ void handle_event (struct inotify_event *event) {   /* If the event was associated with a filename, we will store it here */   char * cur_event_filename = NULL;   /* This is the watch descriptor the event occurred on */   int cur_event_wd = event->wd;   if (event->len)   {      cur_event_filename = event->filename;   }   printf("FILENAME=%s\n", cur_event_filename);        printf("\n");   /* Perform event dependent handler routines */   /* The mask is the magic that tells us what file operation occurred */   switch (event->mask)   {      /* File was accessed */      case IN_ACCESS:         printf("ACCESS EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* File was modified */      case IN_MODIFY:         printf("MODIFY EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* File changed attributes */      case IN_ATTRIB:         printf("ATTRIB EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* File was closed */      case IN_CLOSE:         printf("CLOSE EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* File was opened */      case IN_OPEN:         printf("OPEN EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* File was moved from X */      case IN_MOVED_FROM:         printf("MOVE_FROM EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* File was moved to X */      case IN_MOVED_TO:         printf("MOVE_TO EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* Subdir was deleted */      case IN_DELETE_SUBDIR:         printf("DELETE_SUBDIR EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* File was deleted */      case IN_DELETE_FILE:         printf("DELETE_FILE EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* Subdir was created */      case IN_CREATE_SUBDIR:         printf("CREATE_SUBDIR EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* File was created */      case IN_CREATE_FILE:         printf("CREATE_FILE EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* Watched entry was deleted */      case IN_DELETE_SELF:         printf("DELETE_SELF EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* Backing FS was unmounted */      case IN_UNMOUNT:         printf("UNMOUNT EVENT OCCURRED: File \"%s\" on WD #%i\n",                 cur_event_filename, cur_event_wd);      break;      /* Too many FS events were received without reading them         some event notifications were potentially lost.  */      case IN_Q_OVERFLOW:         printf("Warning: AN OVERFLOW EVENT OCCURRED: \n");      break;      case IN_IGNORED:         printf("IGNORED EVENT OCCURRED: \n");      break;      /* Some unknown message received */      default:         printf ("UNKNOWN EVENT OCCURRED for file \"%s\" on WD #%i\n",              cur_event_filename, cur_event_wd);      break;   } }



각 case 문장 내에서 필요에 맞춰 구현한 어떤 메소드라도 실행할 수 있다.

퍼포먼스 모니터링과 관련하여 어떤 파일들이 가장 자주 읽히는지, 그리고 파일이 열려있던 기간을 파악할 수 있다. 이러한 종류의 모니터링은 쉽다. 어떤 상황에서, 짧은 기간 동안 애플리케이션에 의해 파일이 반복적으로 읽힌다면, 디스크로 돌아가기 보다는 메모리의 파일을 캐시하여 퍼포먼스를 향상시키기 때문이다.

특정 액션을 수행하는 이벤트 스팩의 핸들러들에 대한 다른 예제들도 이해하기 쉽다. 예를 들어, 기반 파일 시스템에 대해 메타데이터 스토리지 인덱스를 구현한다면 파일 생성 이벤트를 찾아 그 파일에 대한 데이터 마이닝 작동을 실행할 수 있다. 보안을 위해서는, 어떤 누구도 작성해서는 안되는 디렉토리에 파일이 쓰여졌다면 시스템 경고를 실행할 수 있다.

inotify가 많은 정밀한 이벤트들 CLOSE versus CLOSE_WRITE을 지원한다는 것도 기억하라.

이 글에서 사용된 코드의 많은 이벤트들이 코드가 실행될 때마다 보고자 하는 것이 아닐 수도 있다. 사실, 가능하다면 본인의 애플리케이션에 필요한 이벤트의 하위세트만 요청할 수 있으면 좋겠다. 이 글에서 제시한 코드에서는 전체 마스크를 사용하여 많은 이벤트들을 보여주고자 하였다. (샘플 코드에 있는 51줄의 main 메소드 (참고자료) 또는 Listing 1의 29줄) 애플리케이션 프로그래머들은 일반적으로 많은 선택권이 주워지길 바란다. 또한 여러분도 필요에 맞는 특정 마스크가 필요하다. 이는 앞서 보여준 handle_event() 메소드에서 catch 문장에서 관심 없는 아이템들을 제거할 수 있다.

결론
inotify가 퍼포먼스 모니터링, 디버깅, 자동화 같은 분야에 적용된다면 강력하고 정밀한 리눅스 파일 시스템의 모니터링 메커니즘이 된다. 이 글에 제시된 코드를 사용하여 최소한의 퍼포먼스 오버헤드로 실시간 파일 시스템 이벤트에 응답하고 이를 기록할 수 있는 애플리케이션을 작성할 수 있다.

http://www-128.ibm.com/developerworks/k ··· ify.html