조회 수 5199 추천 수 0 댓글 1
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

1. 파일 시스템의 이해 - inode

링크(Link)는 ‘연결하다’라는 의미를 가지고 있으며, 파일 시스템 입장에서는 파일에 대한 좀 더 유연한 접근과 관리를 가능하도록 해주는 중요한 역할을 하고 있습니다.

 

링크를 하기전 먼저 파일 테이블과 inode 테이블에 대한 이해가 필요합니다.

사용자의 데이터가 저장되는 장치인 하드디스크는 수많은 섹터, 트랙, 실린더, 클러스터로 구성되어있습니다.
(모든 그림은 클릭하시면 크게보실 수 있습니다.)


filesystem_1.jpg

 


하드디스크에 자료가 항상 규칙적으로(빈 공간없이 차례로) 저장된다면 좋겠지만 데이터를 쓰고 지우기를 반복하다보면 위 그림처럼 공간이 생기게 마련입니다. 이 상태에서 또 다른 파일을 하드디스크에 저장한다면 어떻게 될까요? 빈 공간 아무 곳이나 데이터를 빈 공간만큼 잘라 저장하게 됩니다.


그렇다면 방금 저장한 데이터를 읽을 때에는 어떻게 할까요? 저장된 데이터를 찾기 위해 모든 섹터를 검색할 수는 없을 것입니다. 이때 필요한 것이 바로 파일 테이블과 inode입니다.


아래 그림은 파일 테이블과, inode 테이블 그리고 하드디스크에 저장되는 물리적인 데이터를 나타내고 있습니다.


filesystem_2.jpg

 

위 그림을 보면 파일 테이블은 사용자 인터페이스 입장에서 보는 파일들의 목록 이고, inode 테이블은 파일 테이블에 있는 파일이 실제 하드디스크의 어느 위치(주소)에 저장되어있는지를 저장한 테이블입니다.


위 그림으로 예를들면, 사용자 인터페이스에서 `ls` 명령을 이용하여 보는 note.txt 파일은 파일 테이블에 저장된 내용입니다. 이때 사용자가 `cat` 명령을 이용하여 note.txt 파일의 내용을 보려고 한다면 파일시스템은 inode 테이블을 확인하게 됩니다. 그리고 `C:Users바탕화면note.txt` 파일의 실제 주소는 ‘100번 섹터’라는 것을 알게 되고 이 정보를 이용해 실제 파일에 엑세스하게 됩니다.

즉, inode 테이블은 사용자 인터페이스와 하드디스크에 저장된 물리 데이터를 연결해주는 역할을 하기 때문에 파일 관리에 필요한 모든 정보를 저장하고 있다고 볼 수 있습니다.


실제 inode 정보를 확인해 볼까요?
`ls –li’ 명령을 이용하여 inode 정보를 확인할 수 있습니다.
link_001.jpg

 

리스트 맨 앞의 숫자가 바로 inode를 의미합니다.


참고 : inode가 가지고 있는 정보
inode에는 파일의 소유권 및 이용할 수 있는 권한에 대한 정보, 파일 내용이 들어있는 디스크 내의 물리적 주소(디스크 내의 물리적 주소가 inumber), 파일의 링크 수/형태/크기, 파일의 만들어진 시간/최근 사용시간/최근 수정시간, inode의 최근 수정시간의 정보가 포함되어 있습니다.
ls -i 명령을 이용하여 inode 정보를 확인할 수 있습니다(하나의 파일에 대해 하나의 inode를 생성).



그렇다면 파일을 삭제하는 경우에는 어떻게 될까요? 사용자가 특정 파일을 삭제하면 하드디스크에서 물리적으로 파일을 삭제 하는게 아닌 inode 테이블의 연결 고리만 끊습니다. 즉, inode 테이블에서 해당 파일의 정보만 삭제하는 것입니다. 이렇게 되면 물리적으로는 파일이 하드디스크에 존재하지만 사용자 입장에서는 파일이 존재하지 않는 것처럼 보이게 됩니다.


파일 복구 프로그램은 이러한 원리를 이용하는 것으로 하드디스크를 물리적으로 일일이 스캔하면서 연결이 끊긴(물리적으로 데이터는 존재하지만 inode 테이블에는 정보가 없는) inode를 다시 연결해주는 역할을 하는 것입니다.

 


2. 파일 시스템의 이해 - 링크

이제 링크에 대해서 알아보도록 하겠습니다. 링크는 하드링크와 심볼릭링크로 구분되어집니다.


1) 심볼릭 링크

심볼릭 링크는 윈도우 환경에서의 바로가기 아이콘과 유사합니다.
새로운 inode를 생성하기 때문에 별도의 파일로 인식하고, 다른 파일시스템간 링크가 가능하며 긴 디렉터리명을 갖는 경로로 이동시 유용하기 때문에 주로 사용자 입장에서 많이 사용됩니다. 하지만 원본을 다른 곳으로 이동시키거나 삭제하는 경우 링크가 깨지기 때문에 링크 파일을 더 이상 사용하지 못합니다.


아래 그림을 보겠습니다.
link_002.jpg

 

C드라이브 바탕화면에 있는 note.txt 파일과 이 파일을 심볼릭 링크한 파일을 D 드라이브에 저장했다고 가정해보겠습니다.

사용자는 어떠한 파일을 열어도 동일한 파일에 엑세스 할 수 있습니다. 링크를 실행한다 하더라도 원본 파일에 대한 포인터(inode 4006번 주소)를 가지고 있기 때문에 원본 파일을 실행한 것과 동일하다고 볼 수 있습니다. 또한 어떠한 파일을 수정해도 동시에 수정된 내용이 적용됩니다.


이번에는 아래 그림과 같이 원본 파일을 삭제한다고 가정해보겠습니다.
link_003.jpg

 

심볼릭 링크는 실제 파일에 직접 연결되어 있는 게 아니기 때문에 연결한 원본 링크가 삭제되거나 이름이 바뀌게되면 링크파일은 더 이상 사용할 수 없게 됩니다.

즉, 심볼 링크는 별도의 독립된 파일이며 원본이 삭제되기 전까지는 실제 파일처럼 사용할 수 있습니다. 이제 심볼 링크를 생성해보도록 하겠습니다.

 

먼저 원본 파일을 생성합니다.

[root@ites ~]# cat > test.txt   // test.txt라는 원본 텍스트 파일 생성(Hello~ 문자 입력 후 Ctrl+D)
[root@ites ~]# cat test.txt      // 텍스트문서 내용 확인
[root@ites ~]# ls –il             // inode 및 기타 파일정보 확인


link_004.jpg

 

 

심볼릭 링크 명령은 다음과 같습니다.
[root@ites ~]# ln -s 원본파일명 링크파일명


심볼릭 링크를 위해 아래 명령을 입력합니다. 링크 파일은 link.txt로 하겠습니다.
[root@ites ~]# ln -s test.txt link.txt  // 심볼릭 링크
[root@ites ~]# cat link.txt    // 링크된 파일 확인
[root@ites ~]# ls -il    // inode 및 기타 파일정보 확인

 

link_005.jpg

 

위 그림을 보듯이 링크된 파일을 확인해보면 원본파일과 동일한 내용인 것을 확인할 수 있습니다.  inode 정보를 확인해보면 원본파일은 685504, 링크파일은 685528인 것을 알 수 있습니다.

즉, 심볼릭 링크는 별도의 inode를 생성하기 때문에 단독 파일이라 말할 수 있으며 하드디스크에 추가적으로 용량을 할당받는다고 볼 수 있습니다.


이제 원본 파일을 삭제해보겠습니다.
[root@ites ~]# rm -f test.txt    // 원본파일 삭제
[root@ites ~]# ls -il               // inode 및 기타 파일정보 확인
[root@ites ~]# cat link.txt       // 링크파일 내용 확인

 

link_006.jpg

 

링크된 파일은 변함이 없지만 확인해보면 파일이 존재하지 않는다는 메시지가 나옵니다.

 

 

2) 하드 링크

하드 링크는 원본과 동일한 inode를 갖는 파일을 하나 더 생성합니다. 즉, 1MB의 원본 파일을 하드링크하면 링크된 파일도 1MB의 크기를 갖습니다. 얼핏 파일 복사와 동일하게 보이지만 파일복사와는 방식이 다릅니다.
아래 그림을 보겠습니다.
link_007.jpg

 

심볼릭 링크와는 달리 하드링크는 inode 주소가 동일합니다. inode 주소가 동일하다는 것은 두 개의 파일이 하드디스크 내의 하나의 원본 파일을 가리키는 것을 의미합니다. 따라서, 사용자가 보는 목록 화면에서는 1MB의 크기를 갖는 파일이 2개로 보이지만 실제 하드디스크의 용량은 1MB만 차지하게 됩니다.


이번에는 아래 그림과 같이 원본 파일을 삭제한다고 가정해보겠습니다.
link_008.jpg

 

하드 링크는 두 개의 파일이 모두 같은 주소에 연결되어있기 때문에 원본 링크가 삭제되거나 이동되어도 문제없이 파일에 엑세스할 수 있습니다.
즉, 하드링크는 하나의 파일을 삭제하였다 하더라도 실제 파일 위치를 가리키는 주소만 지운것이기 때문에 다른 파일은 그대로 남아 있게 됩니다. 그렇게 때문에 파일을 지우고자 한다면 두 개의 파일을 모두 삭제해야 합니다.


이제 하드링크를 생성해보도록 하겠습니다. 원본 파일은 test.txt로 가정하겠습니다.
[root@ites ~]# cat > test.txt
[root@ites ~]# cat test.txt
[root@ites ~]# ls -il  // inode 및 기타 파일정보 확인

 

link_009.jpg

 

하드 링크 명령은 다음과 같습니다.
[root@ites ~]# ln 원본파일명 링크파일명


하드 링크를 위해 아래 명령을 입력합니다. 링크 파일은 hard.txt로 하겠습니다.
[root@ites ~]# ln test.txt hard.txt   // 하드 링크
[root@ites ~]# cat hard.txt           // 링크된 파일 확인
[root@ites ~]# ls -il
[root@ites ~]# du -sh                 // 용량 확인

 

link_010.jpg

 

위 그림을 보듯이 링크된 파일을 확인해보면 심볼릭 링크와 동일하게 원본파일과 동일한 내용인 것을 확인할 수 있습니다. 하지만 inode 정보를 확인해보면 심볼릭 링크와는 다르게 inode 번호가 동일하다는 것을 확인할 수 있습니다. 또한 용량을 확인해보면 8KB로 하나의 용량만 계산된 것을 확인할 수 있습니다.


즉, 하드링크는 원본파일과 모두 동일한 속성을 상속받는다는 것을 확인할 수 있습니다.
이제 원본 파일을 삭제해보겠습니다.
[root@ites ~]# rm -f test.txt  // 원본파일 삭제
[root@ites ~]# ls -il   // inode 및 기타 파일정보 확인
[root@ites ~]# cat hard.txt  // 링크파일 내용 확인

 

link_011.jpg

 

심볼릭 링크와는 다르게 파일에 문제없이 엑세스할 수 있습니다. 그렇다면 하드링크는 언제, 왜 사용하는 것일까요?


하드링크는 백업에 아주 유용하게 사용됩니다. 실제로 파일을 복사하지 않고 파일의 '복사'본을 만들 수 있기 때문입니다. 예를 들어 매우 중요한 데이터가 있고, 그 데이터를 서버의 모든 사용자가 엑세스할 수 있도록 해야한다면 계정마다 파일을 사해 놓아야 할 것입니다.

하지만 데이터가 1TB가 넘는다면 어떻게 해야 할까요?
이러한 경우 하드 링크가 유용합니다. 일부 사용자가 실수로 파일을 이동, 이름 변경, 삭제등을 한다 하여도 파일은 원본 파일을 전혀 손상받지 않습니다. 또한 하드 링크를 아무리 많이 한다 하여도 용량은 1TB 고정되기 때문에 여러 이점이 있다고 할 수 있습니다.

 

?

List of Articles
번호 분류 제목 글쓴이 날짜 조회 수
9 Linux Server Fedora(페도라) Linux 12 소개 및 설치 file 송재진 2009.12.21 11066
8 Linux Server 문서편집기의 사용 - vi editor file 송재진 2011.11.05 9586
7 Linux Server 계정 관리 1 - 사용자 계정생성/삭제 file 송재진 2013.04.30 9363
6 Linux Server Linux 사용을 위한 기초 명령어 1 송재진 2009.12.24 7168
5 Linux Server 파일시스템 관리 1 - 리눅스 파일시스템의 이해 file 송재진 2013.11.07 6804
» Linux Server 파일시스템 관리 2 - 하드링크와 소프트링크 1 file 송재진 2013.11.25 5199
3 Linux Server 계정 관리 3 - PAM 모듈을 이용한 로그인 관리 file 송재진 2013.07.24 4298
2 Linux Server 계정 관리 2 - chage를 이용한 비밀번호 관리 file 송재진 2013.07.23 3676
1 Linux Server 리눅스의 부팅과 Run Level(실행레벨) file 송재진 2013.04.01 3568
Board Pagination Prev 1 Next
/ 1
© k2s0o1d6e0s8i2g7n. ALL RIGHTS RESERVED.