hard link 생성이 EXDEV로 실패하지만 symbolic link는 됩니다. hard link가 filesystem 경계를 넘을 수 없는 이유를 inode와 dentry 관점에서 설명해 보세요?

hard link는 source inode의 내용을 복사하는 대신 새 directory entry가 같은 filesystem inode를 직접 가리키도록 만드는 연산입니다. 그래서 대상 inode와 새 이름을 관리하는 mounted filesystem 경계를 넘어 link를 만들 수 없고 Linux link()는 보통 EXDEV를 반환합니다. 주의할 점은 “서로 다른 mount = 반드시 서로 다른 superblock”이라고 말하면 너무 좁다는 것입니다. link(2)는 underlying filesystem이 같아도 separate mounts 사이의 link를 거부할 수 있으므로, 원인은 superblock 차이 하나가 아니라 mounted filesystem 경계와 link 정책의 조합으로 설명해야 합니다. /a/file과 /b/file에서 link 시도가 실패한 뒤 symlink("/a/file", "/b/ref")가 성공할 수 있는 이유는 symlink가 inode를 직접 소유하지 않고 target pathname을 저장하기 때문입니다. 이후 /b/ref를 열 때 pathname lookup이 /a 쪽 mount로 넘어가 target inode를 찾습니다. 그러나 symlink 생성 성공은 target 존재·read 권한·현재 mount 유지까지 보장하지 않습니다. dangling target, traversal 권한, unmount 상태를 open 시점에 다시 검사해야 합니다. “내용이 같으니 hard link도 가능하다”는 추론도 틀립니다. cp로 복사하면 새 inode가 생기고 두 파일의 이후 write가 분리됩니다. 검증은 source와 destination의 device·inode를 확인하고, 실제 Linux 환경에서 별도 mount와 같은 underlying filesystem의 separate mount를 각각 시험하는 방식입니다. 이 환경에는 Linux mount 실험을 실행할 수 없으므로 EXDEV 결과를 측정했다고 주장하지 않고 link(2) 문서의 범위로 한정합니다.