Ext 2:GNU/Linux 시스템 에서 표준 적 인 파일 시스템 으로 파일 에 액세스 하 는 성능 이 매우 좋 고 중 소형 파일 에 더욱 장점 을 나타 내 는 것 이 특징 이다.이것 은 주로 클 러 스 터 의 우수한 디자인 에 유리 하 다.단일 파일 크기 는 파일 시스템 자체 의 용량 상한 과 파일 시스템 자체 의 클 러 스 터 크기 와 관련 이 있 으 며,일반적으로 흔히 볼 수 있 는 x86 컴퓨터 시스템 에 서 는 클 러 스 터 가 최대 4KB 이면 단일 파일 크기 상한 은 2048GB 이 고 파일 시스템 의 용량 상한 은 16384GB 이다.그러나 현재 핵심 2.4 에서 사용 할 수 있 는 단일 분할 구역 은 최대 2048 GB 에 불과 하기 때문에 실제로 사용 할 수 있 는 파일 시스템 용량 도 최대 2048 GB 에 불과 하 다.Ext 3:말 그대로 ext 2 의 다음 세대 입 니 다.즉,현재 ext 2 의 형식 을 가지 고 로그 기능 을 추가 하 는 것 입 니 다.현재 그것 은 실 용적 인 단계 에서 아직 거리 가 있어 서 아마도 다음 판 의 핵심 에서 출발 할 수 있 을 것 이다.ext 3 는 로그 파일 시스템 입 니 다.로그 파일 시스템 의 우수 성 은 파일 시스템 이 빠 른 층 으로 작 동 하기 때문에 사용 하지 않 을 때 빠 른 층 의 자 료 를 디스크 에 쓸 수 있 도록 파일 시스템 을 내 려 야 한 다 는 것 이다.따라서 시스템 이 꺼 질 때마다 모든 파일 시스템 을 내 려 야 꺼 질 수 있다.파일 시스템 이 해제 되 기 전에 꺼 져 있 을 때(예 를 들 어 정전)다음 에 다시 켜 면 파일 시스템 의 자료 가 일치 하지 않 기 때문에 파일 시스템 의 재 조정 작업 을 해 야 합 니 다.일치 하지 않 고 잘못된 곳 을 복구 해 야 합 니 다.그러나 이 재정 비 작업 은 상당히 시간 이 걸 리 고 특히 용량 이 큰 파일 시스템 이 며 모든 자료 가 유실 되 지 않 을 것 이 라 고 100%보장 할 수 는 없다.따라서 대형 서버 에 문제 가 생 길 수 있 습 니 다.이 를 극복 하기 위해 업 계 는 오 랜 개발 끝 에 이른바'로그 파일 시스템(Journal File System)'을 완성 했다.이 파일 시스템 의 가장 큰 특징 은 필요 할 때 추적 할 수 있 도록 디스크 전체 기록 동작 을 디스크 의 한 영역 에 완전 하 게 기록 하 는 것 이다.자료 의 기록 동작 은 파일 헤더 자 료 를 바 꾸 거나 디스크 를 찾 아 기록 할 수 있 는 공간,하나하나 기록 할 수 있 는 자료 구간 등 많은 세부 사항 을 포함 하기 때문에 모든 세부 사항 이 절반 까지 진행 되 고 중단 되면 파일 시스템 이 일치 하지 않 기 때문에 재정 비 해 야 한다.그러나 로그 식 파일 시스템 에 서 는 모든 세부 사항 을 상세 하 게 기록 하기 때문에 특정한 과정 에서 중단 되 었 을 때 시스템 은 이러한 기록 에 따라 중 단 된 부분 을 직접 삭제 하고 재 조정 할 수 있 으 며 다른 부분 을 검사 하 는 데 시간 이 걸 리 지 않 아 도 되 기 때문에 재 조정 작업 속도 가 상당히 빠 르 고 시간 이 거의 걸 리 지 않 습 니 다.또한 리 눅 스 에는 파 티 션 을 교환 하 는 swap 파일 시스템 도 있 습 니 다.리 눅 스 는 전체 파 티 션 을 교환 공간 으로 사용 하고 Windows 처럼 교환 파일 을 사용 하지 않 습 니 다.일반적으로 이 SWAP 형식의 교환 파 티 션 은 주 메모리 의 2 배 입 니 다.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
