[Linux] inode, 심볼릭 링크(소프트 링크), 하드링크

🖥️ Computer Science/Linux

[Linux] inode, 심볼릭 링크(소프트 링크), 하드링크

Rosieblue 2023. 5. 31. 00:34

728x90

리눅스의 링크에는 두 가지 종류가 있다. 바로 심볼릭 링크(소프트 링크)와 하드링크이다. 이를 알기 전에 먼저 i-node의 개념부터 보고 가자.

inode

inode는 index-node의 약자이다.
index는 한국어로는 '색인'이다. 즉, 보통 무언가를 찾을 때 빨리 찾기 위해서 쓰인다. 예를 들어 배열 arr[3]의 정보를 찾기위해 index 3을 이용하면 쉽게 찾을 수 있다.
따라서 index-node, 즉 inode는 무언가를 찾기 위해 사용하는 것이라는 것을 추측할 수있는데, 여기서 그 '무언가'가 '파일'이 되는 것이다.
즉 inode는 파일의 실제 위치를 찾기 위해 파일마다 부여된 노드라고 볼 수 있다.

* 참고로 리눅스는 모~~~든 것을 파일이라고 생각한다. 예를 들어 일반 파일이나 디렉토리를 제외하더라도 디바이스, 파이프, 소켓, 명령어 등마저 정말 모든 것이 파일이다. 그러니까 inode는 방금 든 파일의 예시들에도 다 부여돼있다.

조금 더 전문적으로 표현하자면, inode는 UFS와 같은 전통적 리눅스 파일 시스템에서 사용하는 자료구조 중 하나로, 파일의 정보와 주소를 가지고있는 식별자이다. 즉 inode로 파일을 구분할 수 있는 것이다.
여기서 중요한 것은 파일은 고유한 inode를 가지며, i-node 번호를 통해 구별이 가능하다.

inode에는 디스크 상의 실제 파일 위치가 담겨져 있다. 그렇다면 inode는 단순히 파일 주소만 가지고 있는 것일까? 그렇다면 포인터랑 다를게 없지 않을까??
역시나 inode는 파일의 주소 뿐만 아니라 다른 정보들도 많이 담고 있다. 그렇다면 inode가 담고 있는 정보들은 무엇이 있을까?

정확히 inode가 어떤 정보를 담고 있는지 궁금해서 http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/ch12lev1sec6.html 에서 inode가 어떻게 구조체로 구현되어있는지 가지고 와봤다.

struct inode {
        struct hlist_node       i_hash;              /* hash list */
        struct list_head        i_list;              /* list of inodes */
        struct list_head        i_dentry;            /* list of dentries */
        unsigned long           i_ino;               /* inode number */
        atomic_t                i_count;             /* reference counter */
        umode_t                 i_mode;              /* access permissions */
        unsigned int            i_nlink;             /* number of hard links */
        uid_t                   i_uid;               /* user id of owner */
        gid_t                   i_gid;               /* group id of owner */
        kdev_t                  i_rdev;              /* real device node */
        loff_t                  i_size;              /* file size in bytes */
        struct timespec         i_atime;             /* last access time */
        struct timespec         i_mtime;             /* last modify time */
        struct timespec         i_ctime;             /* last change time */
        unsigned int            i_blkbits;           /* block size in bits */
        unsigned long           i_blksize;           /* block size in bytes */
        unsigned long           i_version;           /* version number */
        unsigned long           i_blocks;            /* file size in blocks */
        unsigned short          i_bytes;             /* bytes consumed */
        spinlock_t              i_lock;              /* spinlock */
        struct rw_semaphore     i_alloc_sem;         /* nests inside of i_sem */
        struct semaphore        i_sem;               /* inode semaphore */
        struct inode_operations *i_op;               /* inode ops table */
        struct file_operations  *i_fop;              /* default inode ops */
        struct super_block      *i_sb;               /* associated superblock */
        struct file_lock        *i_flock;            /* file lock list */
        struct address_space    *i_mapping;          /* associated mapping */
        struct address_space    i_data;              /* mapping for device */
        struct dquot            *i_dquot[MAXQUOTAS]; /* disk quotas for inode */
        struct list_head        i_devices;           /* list of block devices */
        struct pipe_inode_info  *i_pipe;             /* pipe information */
        struct block_device     *i_bdev;             /* block device driver */
        unsigned long           i_dnotify_mask;      /* directory notify mask */
        struct dnotify_struct   *i_dnotify;          /* dnotify */
        unsigned long           i_state;             /* state flags */
        unsigned long           dirtied_when;        /* first dirtying time */
        unsigned int            i_flags;             /* filesystem flags */
        unsigned char           i_sock;              /* is this a socket? */
        atomic_t                i_writecount;        /* count of writers */
        void                    *i_security;         /* security module */
        __u32                   i_generation;        /* inode version number */
        union {
                void            *generic_ip;         /* filesystem-specific info */
        } u;
};

~~개많다~~ (여기에도 잘 나와있는 것 같은데 언제 한번 궁금하면 읽어보는 것도 좋을 듯 하다.)
아무튼 위에 struct를 보니까 생각보다 많은데 일단 지금 당장은 저걸 모두 알 필요는 없다.

우린 생각보다 inode를 많이 접하고 있다. 아래를 보자. 이는 ls -li로 파일 정보를 출력한 결과이다.
(참고로 ls 에 -i 옵션을 주면 inode 번호가 출력된다. 아래 사진 좌측 번호 396850이 inode 번호이다)

굉장히 많이 본 정보 아닌가? 위에는 inode 번호, 권한, 링크 수, 소유자,소유그룹, 파일 크기, 생성 날짜, 이름 등이 적혀있다. inode는 이러한 정보를 가지고 있는 것이다. stat 명령어를 통해서도 파일 정보를 많이 출력할 수 있으니 참고하자.

즉 inode는 실제 파일은 아니지만 주소를 포함한 파일의 메타데이터를 가지고 있는 파일 고유의 식별자라고 보면 되겠다. 그래서 파일에 접근할 때는 먼저 inode를 접근하고 inode를 통해 파일의 실제 위치로 접근하는 것이라고 생각하면 된다.

한편, 이러한 inode들은 파일 시스템의 inode list table이란 곳에 모아져있다.

파일을 생성할 때 새로운 inode가 만들어지고 파일이 삭제될 때 inode도 또한 삭제되는 것을 쉽게 추측할 수 있다.
한편 삭제될 때의 경우에는 좀더 조심스럽게 접근해야하는데, 일단 inode가 제거되면 해당 파일의 데이터 블록도 삭제되어 실제 디스크 공간이 반환된다.

단, 1)다른 프로세스가 해당 파일을 열어 사용 중이거나, 2)파일에 대한 하드 링크가(아래에서 다룸) 존재하는 경우에는 파일의 inode가 삭제되더라도 실제 데이터 블록은 유지될 수 있다. 파일이 모든 하드 링크에서 참조가 제거되고, 파일을 열고 있는 모든 프로세스가 종료된 후에야 실제 데이터 블록도 해제되어 디스크 공간이 반환된다.

stat 명령어를 사용하면 아래처럼 inode 정보를 확인할 수 있다.

심볼릭(소프트) 링크

우리가 리눅스에서 사용하는 링크는 보통 심볼릭 링크(소프트 링크)를 의미한다. 참고로 소포트 링크과 심볼릭 링크는 완전히 같은 말이다. 심볼릭 링크는 Windows의 바로가기 기능과 비슷하다. 즉, 원본파일과 동일한 것이 아니라 단지 원본 파일을 '가리키는' 것 뿐이다. 이는 C에서의 포인터와 비슷한 성질을 지니고 있다.

하드 링크

하드링크는 원본파일이랑 똑같다고 보면된다. 왜냐하면 같은 inode를 가리키기 때문이다. 같은 inode면 디스크에서 완전 똑같은 파일위치로 접근한다.

cp 명령어랑 헷갈릴 수도 있는데, cp는 내용만 같은 '다른' 파일을 만드는 것이다. 따라서 inode 번호는 당연히 다르다. 한편 하드링크는 단지 inode 번호만 복사하는 것이므로 동일한 파일을 가리킨다.

참고로 디렉토리에 소프트링크를 거는 건 가능하지만 하드링크를 거는 것은 불가능하다.

여기서 원본 파일, 하드 링크 파일은 둘 다 inode1을 가리키고, 심볼릭 링크 파일은 inode2를 가리킨다.
inode는 리눅스/유닉스 파일 시스템에서 사용하는 자료구조로 여러 정보가 담겨져 있고 실제 데이터 위치 주소도 담고 있다. 이때 inode2는 원본 파일 포인터를 데이터로 가지고, 원본 파일 포인터는 원본 파일로 향하는 포인터이다. 즉 하드 링크 파일과 심볼릭 링크 파일이 가지고 있는 정보는 다른 것이다. inode가 다르면 그냥 아예 다른 파일이라고 생각하면된다.

아래는 링크를 만드는 명령어이다.

ln 원본파일이름 링크파일이름 ; 하드링크 생성
ln -s 원본파일이름 링크파일이름 ; 소프트링크(심볼릭링크) 생성

위 명령어를 참고하여 이제 직접 하드 링크와 심볼릭 링크 생성 실습을 해보자.

실습

nano 에디터로 원본파일이 될 basefile 을 생성해준다. 안의 내용은 Hello World로 입력했다.
그리고 ln basefile hardlink 로 하드링크 파일인 hardlink를, ln -s basefile softlink으로 심볼릭 링크인 softlink를 생성해주었다.

일단 cat 명령어로 두 파일의 내용을 출력해보면 정상적으로 Hello World가 출력되는 것을 볼 수 있다. 링크가 잘 된 것을 알 수 있다.

이제 ls 명령어로 linktest의 디렉토리 정보를 출력해주는데, 위에서 언급했듯 -i 옵션은 inode 번호를 제일 앞에 출력해준다.

출력된 결과에서 396850, 395100이 inode 번호이다.

아무튼 이렇게 출력된 결과에서 주목할 것은 먼저 소프트링크의 파일 종류만 l로 표시되고, 하드링크는 그렇지 않다는 것도 확인할 수 있다는 것이다. 또한 basefile과 hardlink 의 inode 번호(396850)는 같지만 그 번호와 softlink의 inode 번호(395100)는 다르다는 것 또한 확인할 수 있다.

즉, 하드링크와 원본파일은 동일한 inode를 가리키지만, 소프트파일은 원본파일의 포인터를 담은 inode를 가리킨다.

basefile과 hardlink는 데이터 블록에 동일한 데이터를 저장하므로 파일 크기가 13으로 동일하지만, softlink는 데이터 블록에 원본파일의 포인터를 저장하므로 위의 두 파일과 다른 데이터를 저장하므로 크기가 8로 다르다. 즉 심볼릭 링크 파일의 크기와 원본 파일의 크기는 상관이 없는 것이다.

삭제

rm basefile을 통해 원본 파일을 삭제했다.

softlink가 빨갛게 변한 것을 볼 수 있다. 왜냐하면 소프트링크가 가리키는 애가 사라졌기 때문이다. 위에서 말했듯이 소프트링크는 원본파일을 가리키고 있다.

역시 접근이 되지 않는다.

하지만 아래와같이 cat hardlink를 해보면 또 다르다.

하드링크의 정보는 베이스파일이 사라져도 잘 출력되고 있다. 왜냐하면 원본 파일이 사라져도 하드링크는 원래 파일이 있던 곳으로 접근할 수 있기 때문이다. 하드링크를 지워야지 이 파일이 디스크에서 완전히 삭제된다.

수정

basefile에 I am Haeun을 추가해줬다.

하드링크, 소프트링크 파일을 읽어보니 결과가 잘 적용되었다.

이번에는 소프트링크 파일을 수정해보았다.

원본 파일, 하드링크 파일도 수정이 적용된 것을 볼 수 있다.

파일 이동

이제 basefile의 위치를 다른 디렉토리로 옮겨보자.

softlink가 빨갛게 되면서 어딘가 잘못되었다는 것을 나타내고 있다. cat softlink를 해보면 현재 디렉토리에 basefile이 없으므로 오류가 났다고 출력되고 있다. 즉 softlink과 basefile의 연결이 끊어진 것이다. 하지만 cat hardlink를 해보면 정상적으로 Hello World가 출력되는데 이는 디렉토리가 달라져도 하드링크와 원본파일의 연결은 끊어지지 않는것을 의미한다.

이제 basefile을 다시 linktest 디렉토리로 옮겨보자