% 파일 / etc / mtab
/ etc / mtab : ../proc/self/mounts에 대한 심볼릭 링크
% 파일 / proc / mounts
/ proc / mounts : 자체 / 마운트에 대한 심볼릭 링크
%
/etc/mtab호환성 메커니즘입니다. 수십 년 전, 유닉스는 기존 마운트 정보를 읽는 시스템 호출이 없었습니다. 대신, 파일 시스템을 마운트 한 프로그램은 마운트 된 대상의 테이블을 협력적이고 자발적으로 유지해야합니다 /etc/mtab.
명백한 이유로, 이것은 이상적인 메커니즘이 아닙니다.
리눅스는 "procfs"라는 개념을 얻었고, 얻은 것들 중 하나는 mounts의사 정규 파일 형식의이 테이블의 커널 유지 버전이었습니다 . 커널에서 마운트 정보를 읽기위한 "시스템 호출"은 해당 파일에 대해 열린 읽기-닫기 시퀀스가되었으며, 결과는 사람이 읽을 수있는 형태에서 기계가 읽을 수있는 형태로 결과를 구문 분석합니다. 2 주 전부터 버그 보고서에서 볼 수 있습니다).
/etc/mtab따라서 /proc/mounts그 이름을 고정 배선 한 프로그램이 해당 파일에서 마운트 테이블을 계속 읽을 수있게 하는 기호 링크가 대중화되었습니다. 마운트 및 마운트 해제 된 파일 시스템이 더 이상 최신 상태를 유지하기 위해 명시 적으로 아무것도 할 필요가 없습니다. (그러나 일부는 여전히 /etc/mtab쓰기 가능한 일반 파일로 판명 될 경우 여전히 그렇습니다. mounts모든 비 커널 항목이없는 정규화 된 정보 가 필요한 것은 아닙니다 . 몇 가지 경우 가 있습니다. 와 관련된 일반적인 문제 /etc/mtab.)
각 프로세스는 현재 장착되어 무엇을 자신의 개인보기를 할 수 있습니다, 지금은 각각의 결과로서가 mountsprocfs의에서 각 프로세스에 대한 파일이 각 프로세스의 소유를 통해 액세스 할 수있는 테이블 self로 심볼릭 링크 self/mounts, 그리고 /proc/mounts이다 또한 지금 호환성 기구. ( 유사하게도 비슷한 의사 규칙 파일이 있지만 프로세스 당 mounts또는 형식은 mounts현재 Linux doco에 문서화되어 있지 않습니다 mountinfo.)
SunOS / Solaris는 유사한 메커니즘을 가지고 있습니다. /etc/mnttab파일은 실제로 단일 파일의 파일 시스템이고,과, 해당 파일에 대한 오픈 파일 디스크립터를 통해, 테이블을 판독 이외에도 read()시스템 호출 하나와 포인트 변경 마운트를 감시 할 수 poll()와 함께 다양한 정보를 더 조각을 얻었다 ioctl().
HP-UX /etc/mnttab에서 파일 이름도 비슷하지만 버전 11부터는 시스템 유틸리티 프로그램에서 해당 내용을 함께 유지 관리하는 일반 파일이었습니다.
AIX는 프로그램이 구문 분석해야하는 사람이 읽을 수있는 텍스트 테이블을 내 보내지 않으며 동등한 파일이 없습니다. 마찬가지로, BSD getfsstat()는 FreeBSD와 OpenBSD에서 사람이 읽을 수있는 중간 형식을 통해 마샬링하지 않고 기계에서 읽을 수있는 형식으로 커널에서 마운트 테이블을 얻는 프로그램에 대한 완전한 시스템 호출 을 가지고 있습니다.
추가 자료