이로 인해 노틸러스 및 GVFS를 포함한 기타 프로젝트의 수석 개발자 인 Alexander Larsson 과 의 대화를 떠올 렸습니다.

Giles 의 대답 , 특히 파일 내용을 살펴 보는 Nautilus에 관한 내용은 Nautilus가 “느린”주요 원인에 대해 설명합니다. 그러나 Giles는 왜 이것이 느린 지 설명하지 않습니다. 어떤 사람들에게는 분명하지만 다른 사람들에게는 그렇지 않을 수 있습니다. Alex가 말한 내용은 다음과 같습니다.

빈 슬레이트로 시작한다고 가정하십시오. 즉, 파일 시스템에 전혀 액세스하지 않았습니다. 이제 stat (“/ some / dir / file”)을 실행한다고하자. 먼저 커널은 파일을 찾아야합니다. 기술적 용어로 inode라고합니다. 루트 디렉토리의 inode를 저장하는 파일 시스템 수퍼 블록을 살펴 보는 것으로 시작합니다. 그런 다음 루트 디렉토리를 열고 “some”을 찾은 다음 “dir”을 찾은 다음 결국 파일의 inode를 찾습니다.

그런 다음 실제로 inode 데이터를 읽어야합니다. 처음 읽은 후에도 RAM에 캐시됩니다. 따라서 읽기는 한 번만 발생해야합니다.

HD를 구식 레코드 플레이어로 생각하십시오. 바늘로 올바른 위치에 있으면 물건을 회전하면서 빠르게 읽을 수 있습니다. 그러나 일단“탐색”이라는 다른 장소로 옮겨야 할 때는 매우 다른 일을하고 있습니다. 팔을 물리적으로 움직 인 다음 올바른 장소가 바늘 아래에 올 때까지 플래터가 회전 할 때까지 기다려야합니다. 이러한 종류의 물리적 동작은 본질적으로 느리기 때문에 디스크 탐색 시간이 상당히 길다.

그래서 언제 찾아야합니까? 물론 파일 시스템 레이아웃에 따라 다릅니다. 파일 시스템은 읽기 성능을 높이기 위해 파일을 연속적으로 저장하려고 시도하며 일반적으로 서로 가까운 디렉토리에 대한 inode를 저장하려고 시도하지만 파일 작성 시점, 파일 시스템 조각화 등과 같은 사항에 따라 달라집니다. 이 경우 파일의 각 통계는 탐색을 유발하고 파일을 열 때마다 두 번째 탐색이 발생합니다. 따라서 아무것도 캐시되지 않을 때 시간이 오래 걸리는 이유입니다.

일부 파일 시스템은 다른 파일 시스템보다 낫습니다. 조각 모음이 도움이 될 수 있습니다. 앱에서 몇 가지 작업을 수행 할 수 있습니다. 예를 들어, GIO는 inode 번호가 디스크 순서 (일반적으로 가지고 있음)와 관계가 있기 때문에 무작위 검색을 최소화하기를 기대하기 전에 readdir ()에서 수신 된 inode를 정렬합니다.

중요한 것은 검색을 최소화하기 위해 데이터 스토리지 및 앱을 설계하는 것입니다. 예를 들어, 이것이 노틸러스가 / usr / bin을 읽는 속도가 느린 이유입니다. 일반적으로 파일의 확장자가 없기 때문에 각각에 대해 마법 스니핑을 수행해야합니다. 따라서 각 파일을 열어야합니다. => 파일 당 하나의 탐색 => slooooow. 또 다른 예는 gconf와 같이 많은 작은 파일에 정보를 저장하는 앱도 나쁜 생각입니다. 어쨌든 실제로 지연 시간을 숨기려고 시도하는 것 외에는 할 수있는 일이 많이 없다고 생각합니다.

그는 다음과 같은 메모로 끝났습니다.

이 딜레마에 대한 진정한 해결책은 회전하는 매체에서 멀어지게하는 것입니다. 인텔 SSD가 굉장하다고 들었습니다. 리누스는 그들에게 맹세합니다.

🙂

답변