파일에 대한 정보가 저장되어 있는지 알고 싶습니다.인덱스 노드디렉터리에 직접 저장하는 것보다 추가 오버헤드가 더 가치가 있습니다. 제가 오버헤드를 과대평가하고 있거나 중요한 것을 간과하고 있을지도 모르지만, 그래서 여쭤봅니다.
하드 링크에는 "inode"와 같은 것이 필요하다는 것을 알았습니다. 그러나 오버헤드가 실제로 생각한 것만큼 크다면,어떤 이유정당화하십시오:
- 백업에 하드 링크를 사용하는 것이 현명하지만 백업 효율성은 일반 작업의 효율성에 비해 충분히 중요하지 않습니다.
- 하드 링크의 속도나 크기에 대한 불이익이 없다는 것이 정말 중요합니다. 왜냐하면 이 이점은 오직 존재하기 때문입니다.여러 파일에 대해액세스 시 하드 링크 사용모든 파일간접비를 부담하라
- 동일한 이름(예:
bunzip2및 ) 을 가진 여러 바이너리에 대한 일부 공간을 절약하는bcat것은 무시할 수 있습니다.
inode/하드링크가 나쁘거나 쓸모없다고 말하는 것은 아니지만 이것이 추가 간접 참조 비용을 정당화합니까(캐싱은 확실히 많은 도움이 되지만 만병통치약은 아닙니다)?
답변1
하드 링크는 요점이 아닙니다. 이는 inode를 소유하는 이유가 아닙니다. 그것들은 부산물입니다. 기본적으로 합리적인 UNIX와 유사한 파일 시스템 디자인(이 시점에서는 NTFS도 충분히 가깝습니다)에는 무료 하드 링크가 있습니다.
inode는 수정 시간, 권한 등 파일의 모든 메타데이터가 저장되는 곳입니다. 또한 디스크의 파일 데이터가 저장되는 곳이기도 합니다. 이 데이터는 어딘가에 저장되어야 합니다.
inode 데이터를 디렉터리에 저장하면 약간의 오버헤드가 발생합니다. 디렉토리가 더 커지므로 디렉토리 목록이 느려집니다. 파일 액세스당 하나의 조회를 저장할 수 있지만 디렉터리 순회(파일 경로의 각 디렉터리마다 하나씩, 파일에 액세스하는 데 필요한 여러 순회)당 비용은 약간 더 높습니다. 가장 중요한 것은 이로 인해 한 디렉터리에서 다른 디렉터리로 파일을 이동하기가 더 어려워진다는 것입니다. 즉, inode에 대한 포인터뿐만 아니라 모든 메타데이터를 이동해야 합니다.
Unix 시스템에서는 프로세스에 파일이 열려 있더라도 항상 파일 이름을 바꾸거나 파일을 삭제할 수 있습니다. (일부 UNIX 변형에서는 거의 항상 수행됩니다.) 이는 실제로 매우 중요한 속성입니다. 이는 응용 프로그램이 파일을 "하이재킹"할 수 없음을 의미합니다. 파일 이름을 바꾸거나 삭제해도 애플리케이션에는 영향이 없으며 계속해서 파일을 읽고 쓸 수 있습니다. 파일이 삭제되면 프로세스가 파일을 다시 열 때까지 데이터는 유지됩니다. 이는 프로세스를 inode와 연결함으로써 촉진됩니다. 파일 이름은 언제든지 변경되거나 사라질 수 있으므로 프로세스를 파일 이름과 연결할 수 없습니다.
당신은 또한 볼 수 있습니다슈퍼블록, 아이노드, 디렉토리 항목 및 파일이란 무엇입니까?
답변2
당신이 놓칠 수 있는 몇 가지 다른 요소가 있습니다. 디렉토리의 파일 이름에서 inode를 분리하면 하드 링크가 가능해집니다. 그러나 하드 링크가 이러한 분리를 위한 유일한 동기 또는 원래 동기인지는 의심스럽습니다.
나는 1978년 7월부터 8월까지의 Bell System Technical Journal 사본을 가지고 있습니다. 이것은 그들의 특별한 이슈 중 하나입니다."유닉스 시간 공유 시스템". 이곳은 Thompson, Ritchie 및 회사가 Unix 버전 6 및 7에 대한 설명과 이를 통해 수행할 수 있는 작업을 게시하는 곳입니다.
inode와 파일 시스템에 대한 설명을 보았지만 디자인에 대한 동기는 없었습니다. Ritchie와 Thompson은 시스템 호출이 inode를 생성하고 값을 설정하며, 시스템 호출이 추가 파일 액세스 시 inode 데이터를 저장할 수 있는 운영 체제 테이블을 채운다는 점 create(BSTJ의 철자대로)에 주목합니다.open
주요 단락 중 하나에서는 i-list라고 하는 inode를 보유하는 디스크 블록에 대해 설명합니다.
i-list의 개념은 UNIX의 특이한 기능입니다. 실제로 이러한 파일 시스템 구성 방법은 매우 안정적이고 작업하기 쉬운 것으로 입증되었습니다. ...또한 매우 간단하고 빠른 알고리즘을 사용하여 파일 시스템 일관성을 검사할 수 있습니다. ...이는 선형적으로 구성된 i-목록만 스캔하면 되기 때문에 디렉토리 계층 구조와 독립적입니다.
—원천
원래 설계자는 데이터에서 inode를 분리하면 작업의 신뢰성이 더 높아진다는 사실을 발견했습니다.
저는 우리가 다년간의 경험을 통해 이를 달성할 수 있다고 믿습니다. 디렉터리 계층 구조와 할당(FAT)이 혼합된 MS-DOS 및 기타 파일 시스템은 매우 취약합니다. FAT의 한 섹터가 손상되면 복구가 어렵습니다. 그러나 Unix 디렉토리의 섹터가 불량해지면 디스크의 다른 곳에 있는 inode가 여전히 존재하고 디렉토리에 속함을 나타내는 링크 수가 있으므로 복구할 수 있습니다.
디렉토리에서 inode 번호를 찾은 다음 inode에서 권한이나 데이터를 찾는 명백한 오버헤드는 운영 체제의 파일 처리를 더 간단하게 하거나 안정성을 높임으로써 보상될 수 있는 것 같습니다.
답변3
1개의 실제 inode 예:
이름이 까다로운 파일(예: ~*)이 있어서 삭제해야 합니다.
ls
~*
rm -rf ~*$HOME이 손상되었으므로 다른 방법으로 삭제해야 합니다.
읽다여기inode별로 파일을 삭제하는 방법
inode를 통해 파일을 삭제합니다.
find . -type f -inum 1234 - exec rm -rf {} /;
글쎄요, 특수 문자를 이스케이프 처리하고 rm 으로 간단히 제거하거나 -- 트릭을 사용할 수 있다는 것을 알고 있습니다. 하지만 여전히 그렇습니다.
답변4
하드 링크는 파일만을 위한 것이 아닙니다. 은 파일 시스템의 실제 링크이므로 각 디렉토리에는 전체 경로 이름과 링크 .라는 최소한 두 개의 파일 시스템 링크가 있습니다 . 링크를 .추가하면 ..디렉토리에 여러 개의 하드 링크가 있을 수 있습니다.