장치와 마운트 관계

data를 디스크 이름이 아닌 경로에서 찾습니다

이전 모듈에서 실습 클라이언트는 웹 앱의 /items를 조회했습니다. 이제 요청은 도착하지만 저장이 실패하는 상황을 다룹니다. 담당자는 서버에 디스크가 몇 개 있는지보다 앱이 실제로 여는 파일이 어디에 저장되는지 먼저 확인해야 합니다. 환경 파일의 DATA_FILE은 /srv/bootcamp-m02/lab-root/data/items.json입니다. 이 경로와 실행 계정 bcweb을 출발점으로 잡으면 다른 파일시스템의 여유를 보고 안심하는 실수를 줄일 수 있습니다.

이번 모듈의 시스템 명령은 앞에서 준비한 Linux VM에서 실행합니다. Python 3만 쓰는 판정·로그 사본 검사는 맥에서도 가능합니다. 각 실습 ZIP을 별도 폴더에 풀고 그 폴더에서 bash check.sh를 실행합니다. starter의 미완성 함수만 고치며 solution은 비교용입니다. external 표시는 실제 VM 검증이 남았다는 뜻입니다. VM 명령의 output은 비워 두었으므로 본인 환경의 시각·원문·종료 코드를 기록합니다. 서비스는 앞 모듈의 20초 자연 종료와 계정·데이터를 유지합니다.

장치·파일시스템·마운트 위치를 구분합니다

블록 장치는 데이터를 블록 단위로 읽고 쓰는 저장 장치 인터페이스입니다. 파일시스템은 이름·디렉터리·내용·권한을 연결하는 관리 구조이며 마운트는 그 구조를 현재 경로 공간에 연결하는 작업입니다. /dev/vda라는 장치 이름, ext4라는 파일시스템 종류, /srv라는 경로는 서로 다른 정보를 말합니다. 장치가 연결되어 있어도 앱 경로에 마운트되지 않았을 수 있고, 마운트된 저장소가 꼭 일반 디스크일 필요도 없습니다.

lsblk는 블록 장치의 부모·자식 관계를 읽는 데 사용합니다. NAME과 TYPE으로 디스크·파티션·loop 장치를 구분하고 SIZE는 장치의 크기로 읽습니다. FSTYPE은 식별된 파일시스템 종류이며 MOUNTPOINT는 보이는 마운트 위치의 단서입니다. SIZE가 크다고 현재 앱이 쓸 수 있는 용량이 그만큼 남았다는 뜻은 아닙니다. 파일시스템 용량은 다음 레슨의 df에서 같은 data 경로를 지정해 따로 확인합니다.

하나의 파일시스템이 여러 경로에서 보일 수 있고 저장 구조에 여러 장치가 참여할 수도 있습니다. 이번 운영 실습실은 단순한 VM의 루트 파일시스템을 기준으로 관찰하지만 그 모델을 모든 시스템에 일반화하지 않습니다. tmpfs처럼 메모리를 활용하는 파일시스템은 lsblk에 디스크로 나타나지 않을 수 있습니다. 목록에 장치가 없다는 이유로 경로가 저장 불가능하다고 결론 내리지 말고 실제 경로를 findmnt로 조회합니다.

findmnt로 앱 경로에 해당하는 항목을 선택합니다

findmnt -T는 지정한 파일이나 디렉터리가 속한 마운트를 찾습니다. data 디렉터리가 마운트 지점 자체가 아니어도 상위 경로를 거슬러 해당 항목을 보여 줍니다. SOURCE는 연결된 저장 원천, TARGET은 마운트 위치, FSTYPE은 종류, OPTIONS는 적용 옵션입니다. 기본 출력 형태에 의존하지 않고 -o로 이 네 열을 명시합니다. 실제 파일을 지정하면 /srv 전체를 막연히 조회할 때보다 앱의 저장 위치를 정확히 좁힐 수 있습니다. findmnt 매뉴얼에서 옵션 정의를 확인할 수 있습니다.

경로 /srv/lab/cache/x에 대해 /, /srv/lab, /srv/lab/cache가 관측되었다면 가장 구체적인 /srv/lab/cache를 선택합니다. 문자열 길이만 비교하거나 startswith로 찾으면 /srv/lab-old도 /srv/lab 아래라고 잘못 판단할 수 있습니다. 로컬 실습 함수 locate는 경로 요소를 기준으로 포함 여부를 계산합니다. 상대 경로나 ..가 들어간 경로는 계약 밖 입력으로 거부하며 관측 후보가 없으면 ValueError를 반환합니다.

실제 VM에서는 심볼릭 링크를 먼저 해석한 경로도 기록합니다. data가 다른 저장소를 가리키는 링크일 수 있기 때문입니다. 로컬 함수는 관측 모델이며 링크 해석이나 마운트 네임스페이스까지 구현하지 않습니다. 서비스가 다른 경로 공간에서 실행된다면 관리 셸의 findmnt와 서비스가 보는 경로가 다를 수 있습니다. 이번 유닛의 파일 접근 제한을 확인하고 동일 VM의 기존 data 위치를 유지한 채 증거를 모읍니다.

rw와 실제 쓰기 가능성을 나눕니다

OPTIONS의 ro는 읽기 전용 마운트 상태를 뜻하고 rw는 마운트 차원에서 쓰기를 허용하는 상태를 뜻합니다. rw라고 bcweb이 파일을 만들 수 있다는 보장은 없습니다. 디렉터리 탐색 권한·쓰기 권한·파일 소유자·접근 제어·서비스 격리 설정이 별도로 영향을 줍니다. 권한이 없는 계정에 관리자 권한으로 쓰기를 성공시켜 놓고 서비스도 정상이라고 보고하면 실제 장애를 숨기게 됩니다.

Permission denied는 권한 검토의 단서이고 Read-only file system은 마운트 상태 검토의 단서입니다. 두 메시지를 같은 해결 방법으로 처리하지 않습니다. 이름이 비슷한 경로를 잘못 지정했거나 실행 계정이 달라진 가능성도 함께 확인합니다. 이번 레슨은 상태 조회만 하므로 chmod로 모두 열거나 remount로 상태를 바꾸지 않습니다. 관측을 먼저 남겨야 다음 레슨의 용량·inode 결과와 같은 조건에서 비교할 수 있습니다.

마운트 지점의 경로가 존재한다는 사실도 예상 저장소가 연결되어 있다는 증거는 아닙니다. 별도 저장소가 빠지면 같은 디렉터리가 루트 파일시스템 안의 빈 경로로 보일 수 있습니다. 예상 SOURCE와 TARGET을 운영 구성도에 적어 두고 실제 값과 비교합니다. 잘못된 위치에 새 데이터를 쓰면 마운트 복구 뒤 기존 데이터가 가려져 보일 수 있으므로 경로 존재 확인 다음에 마운트 원천 확인을 이어갑니다.

변경 없이 증거를 인계합니다

실습에서는 lsblk의 장치 구조와 findmnt의 경로 항목을 나란히 기록합니다. 명령이 성공했는지뿐 아니라 어느 VM·계정·시각에서 실행했는지 적습니다. findmnt가 항목을 반환하지 않으면 빈 결과를 정상 마운트로 바꾸지 않습니다. lsblk의 unknown column 오류는 설치된 도구에서 해당 열을 지원하는지 --help로 확인할 단서입니다. 도구 오류와 저장 장애를 혼동하지 않고 원문을 보관합니다.

장치를 다시 포맷하면 해결될 것 같다는 판단은 이 단계에서 하지 않습니다. 파일시스템 종류를 만드는 mkfs는 기존 내용을 잃게 하는 작업이므로 다음 레슨에서도 새로 만든 작은 일반 이미지에만 사용합니다. 기존 VM 디스크 이름을 예제에 대입하지 않습니다. 운영 담당자는 자료를 파괴하기 전에 요청 경로·저장 원천·권한·여유 공간의 연결을 설명할 수 있어야 합니다.

레슨을 마치면 구성도에 DATA_FILE에서 TARGET·SOURCE까지 이어지는 선을 그립니다. ro 또는 rw 판정과 실제 계정 쓰기 검사는 서로 다른 칸으로 남깁니다. 마운트 관측이 없는 상태를 정상이라고 반환하지 않는 로컬 테스트를 통과시키고, 본인 VM의 명령 원문을 별도로 제출합니다. 명령의 자세한 옵션 목록과 장치 계층 사례는 더 읽기의 lsblk 원고에서 찾아봅니다.