☰

하드 링크의 사용 사례는 무엇입니까? [폐쇄]

tag-icon • tag-icon filesystems hard-link
하드 링크의 사용 사례는 무엇입니까? [폐쇄]

어떤 상황에서 누군가가 소프트 링크 대신 하드 링크를 사용하고 싶습니까? 저는 개인적으로 소프트 링크 대신 하드 링크를 사용하고 싶은 상황을 겪어본 적이 없으며, 웹을 검색하면서 만난 유일한 사용 사례는 다음과 같습니다.중복된 동일한 파일 제거.

답변1

다른 의견에서 언급한 백업 사용법(BTRFS 볼륨의 스냅샷도 포함한다고 생각함) 외에도 소프트 링크를 통한 하드 링크의 사용 사례는 태그별로 정렬된 파일 모음입니다. (컬렉션을 생성하는 가장 좋은 방법은 아니며 데이터베이스 기반 접근 방식이 더 나을 수도 있지만 상당히 안정적인 간단한 컬렉션의 경우 나쁘지 않습니다.)

모든 파일이 단일 디렉토리에 저장되고 다양한 기준(예: 연도, 주제, 아티스트, 장르 등)에 따라 다른 디렉토리로 분류되는 미디어 컬렉션입니다. 이는 개별 영화 모음일 수도 있고 상업 스튜디오의 작품 모음일 수도 있습니다. 기본적으로 파일은 저장되고 수정될 가능성이 없으며 정렬되며 여러 위치에 대한 링크를 통해 저장될 수 있습니다.

"원본"과 "복사본"의 개념은 하드 링크에는 적용되지 않습니다. 즉, 파일에 대한 모든 링크에는 적용되지 않습니다.예일반적인 의미의 "복사본"은 없습니다. 그러나 사용 사례 설명의 경우 이러한 용어는 동작 논리를 모방합니다.

"원본"은 "카탈로그" 디렉토리에 저장되고, 정렬된 "사본"은 이 파일에 하드 링크됩니다. 정렬 디렉터리의 파일 속성을 r/o로 설정하면 파일 이름과 정렬 구조가 실수로 변경되는 것을 방지할 수 있고, 카탈로그 디렉터리의 속성은 필요에 따라 수정할 수 있도록 r/w로 설정할 수 있습니다. (이것은 일부 플레이어가 미디어 파일에 포함된 태그, 사용자 입력 또는 인터넷 검색을 기반으로 파일의 이름을 바꾸고 재구성하려고 시도하는 음악 파일의 경우입니다.) 또한 "복사된" 디렉토리의 속성이 다를 수 있으므로 "원래" 디렉터리에 있는 디렉터리에서 정렬된 구조는 제한된 액세스 권한을 가진 그룹이나 월드에서 사용할 수 있는 반면, 기본 "디렉터리"는 전체 액세스 권한이 있는 기본 사용자만 액세스할 수 있습니다. 그러나 파일 자체는 해당 inode를 가리키는 모든 링크에서 항상 동일한 속성을 갖습니다. (이를 향상시키기 위해 ACL을 탐색할 수 있지만 이는 내 지식 영역이 아닙니다.)

원본 파일의 이름이 바뀌거나 이동된 경우(예: 단일 "디렉터리" 디렉터리가 관리하기에는 너무 커짐) 하드 링크는 계속 작동하지만 소프트 링크는 끊어집니다. "복사본"이 이동되고 소프트 링크가 상대적인 경우 소프트 링크는 다시 끊어지지만 하드 링크는 끊어지지 않습니다.

참고: 소프트 링크와 관련하여 다양한 도구에서 디스크 사용량을 보고하는 방식에 불일치가 있는 것 같습니다. 그러나 하드 링크의 경우 일관성이 있는 것 같습니다. 따라서 "태그" 모음으로 분류된 디렉터리에 100개의 파일이 있으면 쉽게 500개의 링크 "사본"이 있을 수 있습니다. (날짜, 사진 작가 및 평균 3개의 "주제" 태그와 같은 사진 모음의 경우) 예를 들어 Dolphin은 하드 링크의 경우 100개의 파일을 보고하고 소프트 링크를 사용하는 경우 600개의 파일을 보고합니다. 흥미롭게도 어느 쪽이든 동일한 디스크 공간 사용량을 보고하므로 소프트 링크된 작은 파일의 대규모 컬렉션과 하드 링크된 대규모 파일의 작은 컬렉션처럼 보입니다.

이러한 유형의 사용 사례에 대한 주의 사항은 COW를 사용하는 파일 시스템에서 "원본"을 수정하면 하드 링크가 끊어질 수 있지만 소프트 링크는 끊어질 수 없다는 것입니다. 그러나 목적이 편집, 저장 및 정렬 후 마스터 복사본을 얻는 것이라면 COW는 해당 시나리오에 들어 가지 않습니다.

답변2

하드 링크는 두 파일의 존재를 바인딩하고 싶지 않을 때 유용합니다. 생각해 보세요:

touch a
ln -s a b
rm a

이제는 b쓸모가 없습니다 . (이러한 단계는 서로 멀리 떨어져 있거나 다른 사람이 수행할 수 있습니다.)

하드링크를 사용하는 경우,

touch a
ln a b
rm a

b아직 살아 있고 정확합니다.

이는 많은 상황에서 유용합니다. 일반적인 것은 중복 제거입니다.

  • 파일 시스템 내에서,예를 들어홈 디렉터리에서 중복 제거 도구는 복사본을 하드 링크로 대체할 수 있습니다. 이렇게 하면 다른 파일에 영향을 주지 않고 삭제할 수 있다는 점에서 두 파일의 일부 "독립성"이 유지됩니다. 다른쪽에 표시됩니다 (변경을 수행하는 도구가 "새 파일에 저장하고 이름 바꾸기" 전략을 사용하지 않는 한)
  • 백업 시스템에서는 여러 스냅샷을 유지하기 위해 하드 링크가 자주 사용됩니다. 특정 파일이 매일 백업되는 경우 백업 시스템은 모든 복사본을 하드 링크할 수 있습니다(그러나아니요원본 버전), 이는 공간 요구 사항을 줄이는 동시에 각 스냅샷이 파일 시스템 수준에서 자체 지원되도록 보장합니다.

또 다른 사용 사례는 파일을 다른 위치에서 사용할 수 있도록 만드는 것입니다. 예를 들어, "개발" 위치에 유지되는 스크립트가 있는 경우 해당 경로의 어딘가에 하드링크할 수 있습니다. 이렇게 하면 개발 디렉터리에서 스크립트를 삭제하더라도 계속 사용할 수 있습니다. (그러나 이 경우에는 여러 가지 고려 사항이 있습니다. 경로에 특정 버전을 "설치"하거나 심볼릭 링크를 사용하는 것이 더 적절할 수 있습니다.)

답변3

개별 프로그램은 시작 이름에 따라 동작을 변경할 수 있습니다.

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

어느 것이 거기에 있습니까?원천그것은 다음과 같은 것에 의해 결정되었습니다.

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

구체적인 내용은 관련된 운영 체제 및 언어에 따라 다릅니다.

이렇게 하면 (대부분) 동일한 코드가 두 개의 (대부분) 동일한 바이너리로 컴파일될 필요가 없습니다. APUE 4장의 Stevens에 따르면, 하드 링크의 다양한 제한 사항을 대체하기 위해 BSD4.2(1983)에서 심볼릭 링크가 구현되었지만 유닉스의 디스크 공간은 매우 비쌉니다. 심볼릭 링크 이름이 프로그램 이름으로 사용되는지 확인하는 테스트 프로그램은 다음과 같습니다.

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

테스트를 통과합니다.

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$

답변4

파일 시스템은 파일을 구성하고 분류하는 간단하면서도 효과적인 방법입니다(파일이 존재하는 주된 이유입니다). 하드 링크는 이와 관련하여 더 높은 수준의 유연성을 허용합니다.

앞서 언급했듯이 하드 링크를 다룰 때 원본과 복사본의 개념이 없습니다. 모든 디렉터리 항목(하드 링크)은 파일 존재에 대한 참조일 뿐이며(해당 인덱스 노드를 가리킴) 우선순위가 없으므로 깨진 하드 링크가 없습니다. 연결. .

여기에 몇 가지 사용 사례가 있습니다.참여하기 위한 하드 링크하지만소프트링크가 없습니다:

  1. 영화, 음악 또는 기타 미디어 컬렉션이 있고 분기의 아티스트별 노래(각 아티스트는 다른 분기의 장르별 하위 카테고리가 있음)와 같은 다양한 분류 기준을 적용하려고 한다고 가정해 보겠습니다. 하위 디렉터리) 등 여전히 파일을 복사하고 싶지 않고 "원본 파일"을 저장할 위치를 결정하고 싶지 않아 파일이 손상되는 것을 방지하기 위해 파일을 이동할 때 "관리"하고 다시 링크할 필요 없이 자유롭게 재분류할 수 있습니다. 연결.

  2. 또 다른 이유는 시스템 호출이 "기본" 파일 시스템 루트(심볼릭 링크는 외부 파일을 참조할 수 없음)의 파일 하위 집합에서 이점을 얻을 수 있도록 허용하면서 동일한 파일의 여러 복사본을 갖는 데 필요한 저장 공간 낭비 chroot를 방지하는 것입니다 chroot. 상대 경로가 있습니다).

  3. 하드 링크가 존재하는 또 다른 매우 중요하지만 거의 언급되지 않는 이유는 ..하위 디렉토리입니다. 이러한 ..디렉토리는 실제로 (대부분의 unix fs 구현에서) 상위 디렉토리에 대한 하드 링크입니다. 하드 링크가 없으면 완전히 다른 방식으로 구현되어야 하며 하드 링크가 있으면 이를 쉽게 수행할 수 있습니다.

관련 정보