하드 링크가 존재하는 이유는 무엇입니까?

하드 링크가 무엇인지 알고 있는데 왜 사용해야합니까? 하드 링크의 유틸리티는 무엇입니까?

하드 링크의 주요 장점은 소프트 링크와 비교할 때 크기 나 속도 저하가 없다는 것입니다. 소프트 링크는 일반적인 파일 액세스 외에 추가 간접 계층입니다. 커널은 파일을 열 때 링크를 역 참조해야하며 시간이 조금 걸립니다. 또한 링크의 텍스트를 보유하기 위해 디스크에 약간의 공간이 필요합니다. 이러한 처벌은 파일 시스템의 구조에 내장되어 있기 때문에 하드 링크에는 존재하지 않습니다.

내가 아는 가장 좋은 방법은 다음과 같습니다.

$ ls -id .
1069765 ./
$ mkdir tmp ; cd tmp
$ ls -id ..
1069765 ../

파일 의 inode 번호 를 제공 하는 -i옵션 입니다. 위의 예제를 준비한 시스템에서 inode 번호가 1069765 인 디렉토리에 있었지만 특정 값은 중요하지 않습니다. 특정 파일 / 디렉토리를 식별하는 고유 한 값일뿐입니다.ls

이것이 말하는 것은 우리가 서브 디렉토리로 들어가서 라는 다른 파일 시스템 항목을 ..볼 때 이전과 동일한 inode 번호를 가지고 있다는 것입니다. ..MS-DOS 및 Windows에서와 같이 셸이 사용자를 위해 해석 하기 때문에 이러한 상황이 발생하지 않습니다 . 유닉스 파일 시스템 ..에는 실제 디렉토리 엔트리가 있습니다. 이전 디렉토리를 다시 가리키는 하드 링크입니다.

하드 링크는 파일 시스템의 디렉토리를 묶는 힘줄입니다. 옛날 옛적에 유닉스는 하드 링크가 없었습니다. Unix의 원래 플랫 파일 시스템 을 계층 파일 시스템 으로 전환하기 위해 추가되었습니다 .

(자세한 내용 은 '/'에 '..'항목이있는 이유는 무엇입니까?를 참조하십시오 .)

동일한 실행 파일로 여러 명령을 구현하는 것이 Unix 시스템에서도 다소 일반적입니다. 더 이상 Linux의 경우 될 것 같지 않지만, 시스템에서 나는 과거에 사용 cp, mv그리고 rm모두 같은 실행했다. 볼륨 사이에서 파일을 이동할 때, 실제로 사본과 제거가 뒤 따르므로 mv이미 다른 두 명령의 기능을 구현해야했습니다. 실행 파일은 호출 한 이름이 전달되므로 제공 할 작업을 파악할 수 있습니다.

임베디드 리눅스 에서 흔히 볼 수있는 또 다른 예로는 수십 개의 명령 을 구현하는 단일 실행 파일 인 BusyBox 가 있습니다.

대부분의 파일 시스템에서 사용자는 디렉토리에 대한 하드 링크를 만들 수 없습니다. .및 ..항목은 자동으로 일반적으로 커널의 일부 파일 시스템 코드에 의해 관리됩니다. 디렉토리 하드 링크를 작성하고 사용하는 방법에주의하지 않으면 심각한 파일 시스템 문제가 발생할 수 있으므로 제한 사항이 있습니다. 이것은 소프트 링크가 존재하는 많은 이유 중 하나입니다. 그들은 같은 위험을 감수하지 않습니다.

매우 유용한 하드 링크 사용법 중 하나는 rsync와 결합 된 증분 백업입니다. 공간을 많이 절약하고 복원 절차를 정말 쉽게 만듭니다. 서버에서 백업을 위해이 방법을 사용합니다.

이 설명 을 읽으려면 시간 이 좀 걸립니다 .

위키 백과 페이지를 읽은 후에 "왜 내가 그것을 사용하겠습니까?"라는 질문이 있다면 하드 링크가 무엇인지 이해할 수 없습니다.

링크는 디스크 블록을 가리키는 디렉토리 항목이다. 즉, 시스템의 모든 파일에는 하나 이상의 링크가 있습니다. 때 rm파일 실제 시스템 호출이다 unlink(). 디렉토리 항목을 제거합니다. 디스크의 블록은 변경되지 않았지만 링크는 없어 졌으므로 파일은 디렉토리 목록에서 사라졌습니다.

개인적으로 하드 링크를 사용하지는 않지만 시스템 전체에 있습니다. 예를 들면 다음과 같습니다.

$ ls -li /bin | grep 53119771
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bunzip2
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzcat
53119771 -rwxr-xr-x 3 root root  26292 2010-08-18 10:15 bzip2

당신은 그것을 볼 수 있습니다 bunzip2, bzcat그리고 bzip모두 같은 아이 노드를 사용합니다. 본질적으로 3 개의 이름을 가진 하나의 파일입니다. 당신은 수있는 세 개의 파일의 복사, 그런데 왜가? 불필요하게 디스크 공간 만 사용합니다.

여러 가지 용도가 있습니다. 파일 기반 잠금을 만드는 데 사용합니다. link (2) 시스템 호출은 대부분의 다른 시스템 호출과 달리 원자 적입니다.

또 다른 용도는 rsnapshot 내에서 시간이 지남에 따라 하드 링크를 사용하여 백업을 수행하여 디스크 공간을 줄입니다. 파일이 변경되지 않은 경우 파일은 파일의 이전 인스턴스에 하드 링크되고 변경된 파일이 새로 복사됩니다.

또한 서버에서 구성 파일을 교환하는 데 사용합니다 rm file.cfg && ln ~/tmp/file.cfg file.cfg. ~ / tmp / * 파일을 안전하게 삭제할 수 있습니다.

이미 제시된 몇 가지 좋은 토론에 추가하려면 ...

• 프로그램에 대한 리소스 액세스가 유닉스에서 구현되는 방식 (즉, "모든 것이 파일" ) 은 파일 에 대한 여러 참조를 처리하기위한 인프라가 OS가 전혀 작동하는 데 필요하므로 추가 비용이 들지 않음을 의미합니다.
• 방법 디렉토리가 (원래 유닉스 파일 시스템에 구현 된, 즉 고정 된 형식 목록 (inode, name)쌍 하드 링크를 (필요에 파일 시스템에 아무런 추가 비용이 없다는 것을 의미 아니라, 같은 우리가보다 (디렉토리에 다른 hardlinke 허용하지 않음으로 사이클을 방지하기로 .하고 ..(이것은 다른 사람에게 거짓말처럼 느껴지기 시작합니까?))

그래서 우리는 그것들을 무료로 얻습니다.

아마도 하드 링크 의 함정 시나리오 를 다루어야 할 것입니다 . 하드 링크는 원래 링크 된 파일이 존재 하는 한 다른 이름 및 / 또는 다른 위치 를 가진 동일한 파일입니다 . 파일을 "원본"으로 생각하는 것은 옳지 않습니다. 둘 다 자신의 디렉토리 항목이며 둘 다 같은 피어입니다. 오래 지속되는 파일의 경우 이는 큰 도움이 될 수 있지만 동일한 이름과 내용으로도 쌍 중 하나를 삭제 한 다음 생성하면 파일이 분리됩니다.

에 대한 링크를 생성 /foo/myfile했다고 가정 해 봅시다 /repo/myfile. 둘 다 동일한 파일 데이터에 대한 포인터입니다. 하나를 변경하고 다른 하나를 변경하십시오. 그러나 그것이 /repoGit 저장소를 보유 한다고 가정하십시오 . 당신이 포함되지 않은 지점도 확인해보세요 myfile그것에를 /repo/myfile삭제됩니다. 현재이 쌍의 다른 링크가 연결 해제 된 것처럼 /foo/myfile간단한 사본이 /repo/myfile되었습니다. 파일 레퍼토리가 변경되는 브랜치 사이를 넘길 때조차 눈치 채기가 쉽지 않지만 원래 브랜치를 체크 아웃하면 새 파일/repo/myfileGit에 의해 생성됩니다. 주의를 기울이지 않으면 두 파일의 내용이 다른 이유가 무엇인지 궁금 할 것입니다. 파일 간의 하드 링크 관계는 파일 이름에 대해 전혀 알지 못하기 때문에 이해하기 쉽습니다. 반대로 소프트 링크는이 삭제 작성주기 동안에도 유지됩니다.

반면에 하드 링크를 사용하는 소프트웨어는이를 잘 알고 있으며 Git이 그 대표적인 예입니다. Git은 파일을 복사하는 대신 기본적으로 하드 링크를 사용하기 때문에 거의 동일한 파일 시스템의 저장소를 거의 무료로 복제합니다. Git의 경우 하드 링크는 객체 및 팩 파일이 변경되지 않으므로 저장소의 한 복제본이 다른 복제본을 수정하지 않으므로 (Git은 수정 가능한 파일을 하드 링크하지 않는 것으로 알고 있음) 모든 복제본을 사용할 수 있으므로 완벽한 유스 케이스입니다. 사전 예방 조치없이 삭제 : "원본" 파일 을 추적하고 실제로 파일을 포함 할 필요가 없습니다 . 하드 링크는 모두 동등한 파트너이며 전체 파일을 "포함"합니다. 소프트 링크는 여기서 작동하지 않습니다.

하드 링크의 또 다른 장점은 파일 내용에 대한 액세스를 중단하지 않고 모든 링크를 이동할 수 있다는 것입니다. 소프트 링크를 사용하면 원본 파일을 이동하면 모든 소프트 링크가 매달려 있습니다.

결론은 많은 유스 케이스에서 링크 유형이 동일하게 작동하지만 일부 유형 또는 다른 유형이 유리하다는 것입니다. 여기에 많은 답변에서 언급 된 효율성은 퓨니 임베디드 컨트롤러의 FLASH 칩에서 파일 시스템을 청소하지 않는 한 현대 컴퓨터 및 파일 시스템에는 거의 관심이 없을 것입니다. 기능 차이가 더 중요하며, 일반적으로 엔지니어링 제약 최강의 선택을 지시 :

• 하드 링크 "소스"는 안전하게 이동할 수 있지만 소프트 링크는 끊어집니다.
• 하드 링크는 링크 된 파일과 구별 할 수 없으며 하드 링크가 존재하는 한 파일이 활성화됩니다. 소프트 링크는 비대칭입니다.
• 하드 링크 된 피어는 삭제하고 다시 만들면 링크 된 그룹에서 끊어 지지만 소프트 링크는 대상을 잃지 않습니다.
• 소프트 링크는 파일 시스템을 교차 할 수 있으며 하드 링크는 불가능합니다.
• 소프트 링크는 디렉토리를 가리킬 수 있으며, 하드 링크는 일반적으로 할 수 없으며 (실제로는 항상 그렇지 않아야합니다).

또한 파일을 삭제하는 라이브러리 호출이 unlink()이유 때문에 호출되었음을 지적해야합니다 ! 모든 디렉토리 항목은 초기에 inode에 대한 단일 하드 링크입니다.