개요

마운트 전파에 대해 공부를 하다가 리눅스의 마운팅에 대해서 직접 실습을 하고자 한다.
여기^[1]에서 바인딩과 링크를 거는 것의 차이를 이야기하길래 진짜 그런가 확인하고, 신기해하는 것이 목표이다.

하드 링크 복습

간단한 링크에 대한 개념^[2]을 오랜만에 복습했다.

심볼릭 링크는 연결 리스트 마냥 미리보기 파일을 만드는 것이고, 완전히 같은 inode를 바라보게 만드는 것은 하드 링크이기에 차이점을 비교하는 건 하드 링크가 적절하다.
근데 옵션만 봐도 알 수 있듯이, 하드 링크는 디렉토리를 링크하는 것이 사실 제한된다..

환경 세팅

단순하게 한쪽에서 다른 쪽으로 마운팅하거나, 하드 링크를 만드는 작업을 해볼 것이다.

파일 내용이 바뀌는지에 대해서도 확인해본다.

하드 링크의 경우

디렉토리 링크하기

일단 보다시피 기본적으로는 디렉터리를 하드 링크할 수는 없다.

네 그냥 그렇습니다.

파일 링크하기

이름이 같은 파일이 있다면 그냥은 안 되고, 기존 파일을 없애야만 하드 링크가 성공한다.

dt의 파일은 삭제되고 같은 inode인 1574275를 가리키는 파일이 dt에 들어가게 됐다.

바인딩의 경우

디렉토리 바인딩하기

바인딩을 하자 dt에 있던 파일들이 보이지 않게 됐다.
사실 마운팅 기본이 원래 경로의 파일시스템을 가리도록 만들어져 있어 당연하다.

언마운팅을 하자 안 보였던 dt1 파일이 다시 보이기 시작한다.

파일 바인딩하기

한 파일만 마운팅하는 것도 결국 똑같이 동작한다.

언마운팅하니 똑같이 원래 파일이 보인다.

번외 - 그냥 마운팅하기

참고로 --bind 옵션 없이 그냥 마운팅을 하려니 불가능했다.
하 지피티 형!! 또 그짓말이야..?
블록 디바이스가 아니라는 이유가 잘 납득이 되지 않는다.

이건 내가 파일시스템을 논리적 볼륨 위에 세팅해서 생기는 문제이려나?

일단 지피티 옹의 말을 빌리자면.. 원래 mount는 블록 장치를 얹을 때 사용하나 파일시스템 레벨에서도 동작하는 놈일 뿐이라고 한다.
파일시스템을 명시해서 마운팅을 한다고 해도 실제 내부 동작은 일단 파일시스템이 깔린 블록 디바이스를 검사하고 마운팅하는 작업을 한다고..
말은 어느 정도 또 납득은 가는 것 같다.

결론

실제 데이터를 바꾸지 않고, 파일의 경로를 노출하는 방식은 꽤나 유용한 구석이 있을 것 같다.
이런 건 어떨까, 내 애플리케이션이 굳이굳이 권한이 없는 디렉토리를 사용해야 한다.
그렇다고 함부로 대할 수 없는 디렉토리라 데이터에 건드리지 않으면서 디렉토리 경로를 사용하고자 한다면, 이런 방식으로 그냥 경로만 쓰윽 덮어서 사용할 수 있겠다.
아직까지는 더 엄청난 시나리오가 잘 떠오르진 않는다..

음.. 생각보다 신기하진 않다.
뭐랄까, 이미 내 시점에서는 그냥 당연히 알고 있는 거 다시금 확인한 느낌이긴 하다.

관련 문서

참고