Windows C: 드라이브를 WSL의 /mnt/c에 drvfs 파일 시스템으로 마운트하고 싶지만 drvfs를 파일 시스템 유형으로 지정하면 대신 9p 파일 시스템을 얻게 됩니다.
다음 명령을 입력했습니다.
$ sudo umount /mnt/c
$ sudo mount -t drvfs C: /mnt/c/
$ mount -l
...
C: on /mnt/c type 9p (rw,relatime,dirsync,aname=drvfs;path=C:;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=3,wfd=3)
보시다시피 유형은 지정된 drvfs 대신 9p입니다.
답변1
예, WSL 버전 2에서 Windows 드라이브를 탑재하면 9P 프로토콜을 사용합니다. 이는 drvfs를 사용했던 버전 1에 비해 큰 변화입니다. WSL 호스트는 WSL 인스턴스가 연결되는 9P 서버를 실행합니다.
이에 대해 논의하는 사이트가 꽤 많이 있지만 검색 엔진인 IMHO로는 찾기가 약간 어렵습니다. 9P에 관한 "더 큰" 뉴스는 각 WSL이사례(WSL1이든 WSL2이든) 자체 9P 서버도 호스팅합니다. 그러면 Windows/WSL 호스트가 클라이언트로 연결하여 경로에 있는 WSL 파일에 대한 액세스를 제공할 수 있습니다 \\wsl$\<distroname>.
여기 더 좋은 것 중 하나가 있습니다r/bashonubuntuonwindows에서 찾은 토론. WSL 개발자 중 한 명인 u/benhelioz의 인용문을 참고하세요(현재는 팀을 이끌고 있다고 생각합니다).
훌륭한 기사입니다. 이 점을 분명히 말씀드리고 싶습니다. 우리는 Windows 드라이브 파일 액세스 성능에 전혀 만족하지 않습니다. 이는 우리가 투자하고 있는 가장 큰 영역 중 하나이며 성과를 개선하기 위해 열심히 노력하고 있습니다. 제가 강조하고 싶은 점은 9p에는 Samba와 SMB가 제공하지 않는 몇 가지 이점이 있다는 것입니다. 훨씬 더 안전하고 관리자/비관리자를 지원하며 WSL1에서 DrvF를 사용하는 모든 것과 완벽하게 호환됩니다.
귀하의 질문에 대한 대답이 없는 부분은 드라이브를 drvfs로 직접 마운트할 수 없는 이유입니다. 이는 WSL 인스턴스가 하드웨어에 직접 액세스할 수 없기 때문입니다. 이는 WSL(LxssManager) 서비스 인터페이스를 사용하여 Windows 요소에 대한 API 액세스를 제공합니다. 따라서 우리는 WSL2 및 NTFS 드라이브의 경우 9P인 WSL의 액세스 제공 방법에 의존합니다.