하드 링크를 만드는 것이 언제 유용한가요?

하드 링크에는 기본적으로 두 가지 주요 제한 사항이 있습니다.

1. 하드 링크는 일반적으로 링크와 파일이 동일한 파일 시스템에 있어야합니다.
2. 수퍼 유저 만 디렉토리에 대한 하드 링크를 만들 수 있습니다.

따라서 하드 링크의 한계를 극복하기 위해 기호 링크가 도입되었습니다. 따라서 문제는 여전히 하드 링크가 필요합니까? 그들이 더 유용한 상황이있을 수 있습니까?

하드 링크는 파일 시스템을 훨씬 융통성있게 구성하는 데 도움이됩니다. 기본적으로 하드 링크를 사용하면 파일 하나를 가져 와서 파일 시스템에서 한 번에 여러 위치에 둘 수 있습니다. 당신이 사진 사이고 많은 사진을 가지고있는 시나리오를 생각해보십시오 (이것은 제 인생의 예입니다!). 때로는 사람들이 사진을 요구하기 때문에 사람들을 표시 할 수도 있습니다. 그러나 위치와 날짜별로 구성 할 수도 있습니다. 이 세 가지를 중첩시킬 실제 방법은 없으며 완전히 분리 된 조직 축입니다. 따라서이 세 가지 사물에 대해 서로 다른 세 가지 계층을 만들 수 있으며 각 사진을 세 가지로 모두 표시 할 수 있습니다각 사진을 세 번 저장해야합니다. 이것이 바로 하드 링크의 마법입니다. 심볼릭 링크를 해제하면 "실제 파일"이 모두 실제 파일이기 때문에 어디에 있는지 걱정할 필요가 없습니다. 더 이상 참조가 없을 때까지 파일이 유지되고 마지막 하드 링크를 삭제할 때 제거되기 때문에 우리는 마음대로 삭제하고 이동할 수 있습니다. 간단하고 매우 많이 추적 할 필요가 없습니다.

파일의 내용은 모든 하드 링크 (예, 모든 파일 이름은 하드 링크, 첫 번째 파일도 하드 링크 임)가 지워지고 파일이 닫힐 때까지 제거되지 않습니다. 파일이 여러 위치에 필요한 경우 따라서, 그것은 도움이 될 수 있지만, 사이 예, 언제든지 어떤에서 제거 될 수 ~/Downloads/coolsong.mp3및 ~/Music/Cool Song.mp3.

심볼릭 링크에 비해 하드 링크의 중요한 이점 중 하나는 하드 링크의 inode에 도달 할 때 커널이 파일에 액세스하기 위해 더 이상 처리 할 수 ​​없다는 것입니다. 심볼릭 링크가 발견되면 커널은 링크 값을 읽고 파일의 inode에 도달하기 전에 디렉토리 구조를 계속 탐색해야합니다. 차이를 반드시 쉽게 측정 할 필요는 없지만 시간이 오래 걸립니다. symlink 값의 요소 중 하나가 자체적으로 symlink이면 정말 재미있을 것입니다.

하드 링크에는 몇 가지 이유가 있습니다

1. Ignacio가 지적한 것처럼 마지막 참조가 사라질 때까지 파일에 대한 참조를 유지
2. 파일을 하드 링크하면 파일 시스템에서 한 파일의 공간 만 차지합니다 (파일에 대한 참조는 동일한 i- 노드를 공유 함). 따라서 하드 링크는 동일한 파일 시스템에 있어야합니다.

따라서 하드 링크를 사용하는 한 가지 이유는 많은 공간을 절약하는 것입니다 ...

참조 중 하나에 추가 할 수 있으며 데이터는 공유 파일로 이동합니다. 다른 파일을 읽는 동안 한 파일 설명자를 추가 할 수도 있습니다 (예 : tail -f).

여기에 제공된 많은 예제는 유효하지만 소프트 링크에서도 동일하게 작동합니다 (예 : "여러 위치에 하나의 파일이 필요합니다"문제).

하드 링크가 실제로 도움이되는 좋은 예는 백업 소프트웨어 Dirvish입니다 .

Dirvish는 빠른 디스크 기반의 회전 네트워크 백업 시스템입니다.

dirvish를 사용하면 파일 시스템의 완전한 이미지 세트를 자동 생성 및 만료와 함께 유지할 수 있습니다. 더러운 백업 볼트는 데이터의 타임머신과 같습니다.

Dirvish는 파일을 별도의 (백업) 파일 시스템 (예 : USB 하드 디스크)에 복사하여 파일 시스템 수준에서 백업을 만듭니다 (즉, 파일을 복사하고 이미지를 만들지 않습니다). 백업 할 때마다 dirvish는 저장할 디렉토리 트리의 별도의 완전한 사본을 만듭니다.

비결은 dirvish가 이미 저장하고있는 트리의 오래된 백업 사본이 있음을 감지하면 새 트리에서 하드 트리를 이전 트리의 파일에 연결하여 변경되지 않은 파일을 자동으로 재사용한다는 것입니다.

이렇게하면 각 백업 복사본은 완전하고 독립적 인 디렉토리 트리의 복사본이지만 동시에 변경된 파일 만 실제로 파일 시스템의 공간을 차지합니다. 즉, 증분 백업 (공간 절약)과 전체 백업 (쉬운 검색)의 이점을 동시에 얻을 수 있습니다.

이것은 하드 링크가 사용자 공간 도구에 완전히 투명하기 때문에 가능합니다.

이것은 아마도 심볼릭 링크와 함께 작동 할 것입니다 (심볼릭 링크 자체를 사용하는 데이터를 백업 할 때 문제가 발생하더라도). 하드 링크에서만 가능한 한 가지 이점은 다음과 같습니다.

오래된 백업을 버리려면 해당 백업 디렉토리 트리를 삭제하면됩니다. 해당 트리에서만 링크 된 파일은 파일 시스템에 의해 자동으로 삭제되지만 (마지막 하드 링크가 삭제되기 때문에) 다른 사본에도 나타나는 파일은 디스크에 남아 있습니다.

유용한 임시 사례는 큰 임시 타르볼을 다운로드해야하는 프로그램 (또는 스크립트)이 있고이를 추출하면 프로그램이 즉시 삭제됩니다.

어떤 이유로 든 나중에 사용할 수 있도록 해당 tarball을 보존하려는 ln /tmp/tarball.tgz ~경우 tarball을 계속 다운로드 하는 동안 가장 좋은 방법 입니다. 그러면 아무것도 할 필요가 없습니다.

다운로드가 완료되고 프로그램이 '원본'을 삭제 한 후에도 정확한 사본은 여전히 ​​홈 디렉토리에 있어야합니다.

'하드 링크'를 사용하여 일부 'HowTos'및 스 니펫을 백업합니다.

내 사용자 / 루트에 '공유 문서'라는 디렉토리가 있습니다. 해당 디렉토리에는 팁, 트릭, 스 니펫, 해당 디렉토리에있는 하우투에 대한 '하드 링크'가 있습니다. php, mysql, css, regex, formulas, linux 등을 '한 곳에서'사용하면 문서 / 디렉토리에서 자주 사용하는 문서를 찾는 것보다 훨씬 쉽게 사용하고 업데이트 할 수 있습니다.

오래 전에 심볼릭 링크를 사용했습니다. 이 공통된 '공유 문서'디렉토리를 서버에 충실하게 백업합니다. 문제는 symlinks 또는 'Soft Links'입니다. 복사 (cp -auv) 또는 tar를 복사하고 복사 한 경우 문서의 내용이 아닌 'link'만 백업하거나 복사하십시오. 따라서 디렉토리를 탐색하고 실제 위치에서 24 개 파일을 각각 복사해야합니다.

HARD LINKS를 ​​사용하면 '공유 문서'디렉토리를 복사, tar, 재 동기화 할 수 있으며 실제로 광범위하게 분산 된 문서를 자신있게 백업 할 수 있습니다. 실제로 내용이 백업됩니다. 내가 물린 '링크 파일'을 백업하고 정보가 아니라는 것을 깨달았을 때 정말 빨랐습니다.

'하드 링크'를 사용하는 것의 단점은 디렉토리에서 ls를 수행해도 파일이 다른 파일과 '링크'되었거나 해당 파일이 공존 할 수 있다는 표시를 제공하지 않는다는 것입니다. 그것들을 찾는 방법이 있지만, 간단한 ls -l->가 가리키는 것은 분명하지 않습니다. 그래서, 나는 보통이 파일의 디렉토리 / 파일을 나타내는 문서의 시작 부분에 메모를 추가합니다. '은 (는)'와 (과) 공유 함

랜디스.