파일 시스템에 관해 읽고 있었는데 몇 가지 질문이 떠올랐습니다.
Q: 파일이 unix/linux의 필수 부분(즉, 프로세스 /proc
또는 장치 파일을 나타냄 /dev
)이라면 어떻게 될까요? "모든 것이 파일이다', 파일 시스템 컨텍스트 외부에 존재합니까? 일부 파일(예: 네트워크 소켓 파일 또는 블록 장치 파일)은 파일 시스템과 분리되어 있으며 운영 체제 자체의 일부처럼 느껴집니다.
후속 질문: unix/linux가 파일 시스템 없이 실행될 수 있습니까? 예를 들어, Linux 시스템에서 보조 스토리지에 대한 수동 액세스가 가능합니까?
답변1
예. 그리고 아니. 아마도.
모든 것이 아닌예파일, 분명히 하드 드라이브는 하드 드라이브 자체를 포함하는 파일 시스템을 포함하는 파티션을 포함할 수 없습니다. 그냥 많은 것들이 있어요접근성통과하다이름파일 시스템 트리를 통해 표시됩니다.
파일 시스템(논리 파일 시스템 또는 ext4와 같은 데이터 구조의 의미에서 특정 파일 시스템)에 관한 한 특정 파일은 특정 번호가 매겨진 장치의 "장치 노드"로 표시됩니다. 그러나 해당 기능은 별도의 드라이버에 의해 구현됩니다. 프로세스가 이에 액세스하면 운영 체제는 파일 시스템이 아닌 적절한 드라이버에 대한 액세스를 전송합니다. 참조, 포인터 등으로 생각하십시오.
이를 염두에 두면, 예를 /proc
들어 필수 사항은 아니라는 점을 쉽게 이해할 수 있습니다. 그것 없이도 시스템이 작동하고 프로세스를 실행할 수 있습니다. 당신은 그 과정을 볼 수있는 그런 방법이 없습니다. 그러나 fork()
, kill()
및 같은 것들은 wait*()
일부 파일 시스템 이름이 아닌 PID로 프로세스를 참조하기 때문에 계속 작동합니다. 일반적으로 네트워크 소켓도 명명된 파일로 표시되지 않습니다. Unix 도메인 소켓은 이를 수행할 수 있지만 IIRC는 그럴 필요가 없습니다. 예를 들어 TCP나 UDP 소켓의 경우에는 그렇지 않습니다. 그러나 웹 소켓은 다음과 같이 나타납니다.파일 설명자프로세스 및 read()
시스템 write()
호출은 파이프 또는 "실제" 파일과 동일하게 작동합니다. 따라서 어떤 의미에서 네트워크 소켓은 파일처럼 걷고 말하고 덜거덕거리지만, 네트워크 프로토콜은 디스크에 비트를 저장하는 것과 큰 관련이 없습니다.
그러나 내가 아는 한 실제로 명명된 장치 노드 없이 임의의 하드 드라이브를 참조할 수 있는 방법은 없습니다. 하드웨어는 그대로 있고 시스템에는 작동하는 데 필요한 SATA/USB/모든 드라이버가 여전히 있지만 그렇게 하라고 지시할 수는 없습니다. 파일 시스템을 마운트한 다음 파일 시스템이 있는 장치를 가리키는 장치 노드를 삭제할 수도 있습니다. 장치 노드는 단방향이므로 여기서는 문제가 없습니다.사용자 공간액세스 장치.
당신은 "파일 시스템 없이 유닉스/리눅스를 실행할 수 있습니까?"라고 묻습니다. 우선, Linux는 실행할 실행 파일(실행을 종료하는 파일 init
)을 찾아서 사용자 공간에서 시작하기 때문에 파일 시스템 없이는 실행할 수 없습니다. 그러나 이 파일 시스템은 일반 디스크 드라이브의 파일 시스템일 필요는 없으며 커널 이미지에 포함된 데이터를 기반으로 커널이 설정한 특수한 rootfs 파일 시스템일 수 있습니다. (그런데, rootfs를 제거할 수는 없습니다. 비어 있을 때에도 항상 존재하므로 커널은 아무것도 마운트되지 않은 파일 시스템에 대한 아이디어를 처리할 필요가 없습니다.)ramfs-rootfs-initramfs.txtrootfs에 대한 자세한 내용은 커널 설명서를 참조하세요.
일부 가상의 운영 체제는 파일 시스템 없이 실행될 수 있다고 가정할 수 있지만, 예를 들어 execve()
시스템 호출에는 파일 이름이 필요하므로 실행 중인 프로그램이 무엇이든 다른 프로그램을 시작할 수 없습니다. 실행 중인 프로그램은 다른 방법으로 로드해야 합니다. ), 지정된 장치 노드가 없으면 저장소에 액세스하는 것도 어렵습니다. 아무튼 다른 Unixen과 별반 다르지 않은 것 같습니다.
Linux에서는 부팅 시 rootfs에서 단일 사용자 공간 프로그램을 시작한 다음 rootfs를 지우고 다른 파일 시스템을 마운트하지 않는 이상한 단일 목적 시스템을 설계하는 것이 가능합니다. 이는 파일 시스템이 없는 상태에 최대한 가깝고 예를 들어 프로그램은 여전히 실행되고 네트워크에 액세스할 수 있습니다. 하지만 실용적인 용도가 있는지는 의심스럽습니다. 평소와 같이 열려 있는 파일은 닫힐 때까지 계속 존재하므로 해당 이름을 제거하는 것이 그다지 유용하지 않을 수 있습니다.
당신은 또한 볼 수 있습니다Linux 커널을 실행하려면 파일 시스템이 필요합니까?, 위에서 답변한 답변의 일부입니다. "모든 것은 파일이다"라는 주문에 대한 자세한 내용은 다음을 참조하세요.이 답변존재하다"모든 것이 파일이다"에 대한 일반인의 설명 - Windows와 어떻게 다른가요?.
답변2
실제로 "파일"이라는 컴퓨터 개념은파일 시스템보다 오래됨. 이는 데이터 모음입니다(예: 펀치 카드의 데이터).
다른 사람들이 이미 답변한 것처럼 현대 시스템은 실제로 파일을 파일 시스템의 일부로만 간주합니다. 파일 데이터의 일부가 아닌 소유권, 권한 등 파일과 관련된 메타데이터가 있습니다. 그러나 Wikipedia 페이지에서 볼 수 있듯이 항상 그런 것은 아닙니다.
또한 블록 장치문서그리고 소켓문서정의에 따라 파일 시스템이 필요한 운영 체제 개체를 나타내는 파일 시스템 구현입니다. 그들이 참조하는 운영 체제 개체에는 파일이 필요하지 않으며 파일은 개체에 대한 인터페이스일 뿐입니다. 모든 파일 시스템이 블록 장치와 소켓 파일을 지원하는 것은 아닙니다.
답변3
이 질문은 다소 철학적인 성격을 띠고 있습니다. 환경 없이는 아무것도 존재할 수 없나요?
덜 철학적인 관점에서 보면 "파일"의 정의에 따라 다릅니다. 장치는 분명히 파일 시스템 없이 존재합니다. 프로세스는 파일 시스템 없이 존재합니다. 네트워크 스트림은 파일 시스템 없이 존재합니다.
이러한 일이 작동하려면 일종의 표현이 있어야 합니다. 데이터 스트림을 열거하기 위해 장치 ID를 사용하는지 정수를 사용하는지 여부는 중요하지 않습니다.
"하드 디스크 블록 23865에 일부 데이터가 있습니다" 또는 "네트워크 스트림 3874" 메시지를 "파일"이라고 부르겠습니까? 그러면 파일 시스템 없이도 파일이 존재할 수 있다고 말할 수 있습니다.
이 정보를 저장, 액세스 및 관리할 수 있는 방법이 필요할 수 있습니다. 네트워크 흐름 또는 현재 활성 프로세스 목록이 표시됩니다. "파일"을 더 큰 데이터 구조에 저장합니다. 이것이 파일 시스템입니다. 이러한 데이터 구조는 어떤 형태의 영구 저장소에도 기록되지 않지만 여전히 파일을 관리하는 시스템입니다.
결론: 아니요, 파일 시스템 없이는 파일이 존재할 수 없습니다.