☰

최근 배포판에 왜 그렇게 많은 파일 시스템이 설치되어 있습니까?

tag-icon • tag-icon linux filesystems mount
최근 배포판에 왜 그렇게 많은 파일 시스템이 설치되어 있습니까?

나는 1996년경부터 서버에서 Linux를 사용해 왔으며 다음과 같은 상황을 보는 데 익숙합니다.

$ mount
proc on /proc type proc
/dev/sda1 on / type ext3
/dev/sda2 on /usr type ext3
/dev/sdb1 on /home type ext3

(여기서는 관련이 없으므로 "옵션"을 제거했습니다.)

최근에 나는 다음을 보기 시작했습니다.

$ mount
proc on /proc type proc
/dev/sda1 on / type ext3
/dev/sda2 on /usr type ext3
/dev/sdb1 on /home type ext3
devtmpfs on /dev type devtmpfs 
tmpfs on /run type tmpfs 
tmpfs on /run/lock type tmpfs 
sysfs on /sys type sysfs
tmpfs on /run/shm type tmpfs 
devpts on /dev/pts type devpts

이 추가 항목 중 일부는 모두 중복될 수 있지만 일부는 이해할 수 있다고 생각합니다 proc...

나는 최근에 데스크톱 배포판(이 경우 Linux Mint, Debian, Kali 및 기타 배포판에서 본 적이 있음)의 라이브 ISO 이미지를 얻었고이것미친:

$ mount
sysfs on /sys type sysfs 
proc on /proc type proc 
udev on /dev type devtmpfs 
devpts on /dev/pts type devpts 
tmpfs on /run type tmpfs 
/dev/sda1 on / type ext4 
securityfs on /sys/kernel/security type securityfs 
tmpfs on /dev/shm type tmpfs 
tmpfs on /run/lock type tmpfs 
tmpfs on /sys/fs/cgroup type tmpfs 
cgroup on /sys/fs/cgroup/systemd type cgroup 
pstore on /sys/fs/pstore type pstore 
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup 
cgroup on /sys/fs/cgroup/pids type cgroup 
cgroup on /sys/fs/cgroup/hugetlb type cgroup 
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup 
cgroup on /sys/fs/cgroup/blkio type cgroup 
cgroup on /sys/fs/cgroup/freezer type cgroup 
cgroup on /sys/fs/cgroup/perf_event type cgroup 
cgroup on /sys/fs/cgroup/cpuset type cgroup 
cgroup on /sys/fs/cgroup/memory type cgroup 
cgroup on /sys/fs/cgroup/devices type cgroup 
systemd-1 on /proc/sys/fs/binfmt_misc type autofs 
mqueue on /dev/mqueue type mqueue 
debugfs on /sys/kernel/debug type debugfs 
hugetlbfs on /dev/hugepages type hugetlbfs 
fusectl on /sys/fs/fuse/connections type fusectl 
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
cgmfs on /run/cgmanager/fs type tmpfs 
tmpfs on /run/user/1000 type tmpfs 
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse

'마운트'가 급증하는 이유는 무엇일까? 이와 같은 것을 cgroups프로그래밍 API 등을 통해 액세스하는 대신 "마운트된" 파일 시스템으로 처리하는 것이 특히 편리한가요 ?

답변1

API 유형을 선택하는 것입니다.

이전 시스템에서는 해당 장치에서 장치 및 IOCTL을 사용하는 것이 일반적입니다(예: 가상 터미널 생성). 문제는 특정 서비스에 접속하기 위해 숫자를 사용해야 하기 때문에 개선/업그레이드가 쉽지 않다는 점이다. 또한 동일한 요청 번호가 다른 장치에서는 완전히 다른 의미를 가질 수 있으므로 장치 이름을 바꿀 때(더 설명적, 가상 시스템 등) 잘못된 명령이 실행될 수 있습니다(예: 프로그램에 어떤 장치를 제공해야 하는지 혼동하는 경우) ) .

그래서 다른 옵션이 있습니다. 때로는 새로운 시스템 호출이 생성되기도 하지만 이는 대부분 일반적인 경우에 해당하며, 새로운 시스템 호출을 많이 생성하는 것도 이상적이지 않습니다. /proc또한 범용 인터페이스가 되지만 이 파일 시스템(커널 측)에 대한 인터페이스가 모든 서비스에서 동일하기 때문에 몇 가지 문제가 있습니다. APCI와 네트워킹은 이러한 인터페이스를 광범위하게 사용합니다. 다른 프로그램이 proc의 파일에 액세스할 수 있는 경우 모듈을 제거하는 데 몇 가지 문제가 있습니다. 이제 모듈(메모리 확보를 위해 제거)은 더 이상 문제가 되지 않습니다.

웹 소켓은 거의 시도되지 않지만 일회용으로는 덜 편리합니다.

따라서 이제 새 파일 시스템을 생성하는 것이 더 쉬워지고 드라이버/서비스에 이를 구현할 수 있는 더 많은 자유가 제공됩니다. 또 다른 장점은 데이터를 얻고 추출하는 데 사용할 cat수 있다는 것입니다. echo새로운 기능을 더 쉽게 테스트하고 사용할 수 있습니다.

관련 정보