그래픽 파일 검색 유틸리티와 비교하여 GNU가 왜 그렇게 빨리 찾습니까?

내 홈 디렉토리와 모든 하위 디렉토리에 존재 하지 않는 파일을 찾으려고합니다 .

find ~/ -name "bogus"몇 초 후에 정보를 제공하지만 KDE의 dolphin파일 관리자 는 거의 3 분이 걸렸습니다 . 이것은 그놈beagle 에 대한 나의 이전 경험과 일치 합니다.

find그래픽 검색 (명령 줄 매개 변수보다 사용하기가 더 직관적 임) 동안 어떻게 똑같이 빠른 속도로 작업을 수행합니까?

find performance dolphin

— 빨간
소스

"돌핀"이 무엇인지 모르지만 파일 내부 를 볼 수도 있습니까?

— Kusalananda

KDE의 그래픽 파일 관리자입니다. kde.org/applications/system/dolphin 파일 내부를 검색하는 기능이 있지만이 간단한 테스트 중에는 해당 옵션을 활성화하지 않았습니다.

— 레드

돌고래에서 두 번 이상 검색 했습니까? 첫 번째 "인덱싱"일 수 있습니다. 그리고 "찾기"도 느립니다. 찾기에 대한 데이터베이스가 마지막으로 색인화 된 시간보다 파일이 오래된 경우 "locate"를 시도하십시오 ;-)

— Rinzwind

나는 locate더 자주 사용 find하고 거대한 폴더에서 더 빠릅니다

— phuclv

동안은 locate: 그것은 완전히 다른 접근 방식 사용하기 때문에,이 조금 OT이다 파일을 찾기위한 정말 좋은 것입니다 find추천하고 GUI 도구를 Dolphin필요에 따라 파일 트리를 탐색하는을하면서, locate이전에 생성 된 인덱스 구조를 사용하고 있습니다.

— Michael Schaefers

Baloo를 사용하여 Dolphin을 구체적으로 살펴보면 간단한 파일 이름 검색을 수행하더라도 검색 도메인에있는 모든 파일의 메타 데이터를 찾는 것 같습니다. 나는 추적 할 때 file.so과정을, 나는 호출보고 lstat, getxattr그리고 getxattr다시 모든 파일에 대해, 심지어에 대한 ..항목을. 이러한 시스템 호출은 파일 이름과 다른 위치에 저장된 파일에 대한 메타 데이터를 검색합니다 (파일 이름은 디렉토리 내용에 저장되지만 메타 데이터는 inode에 있음 ). 데이터가 디스크 캐시에 있기 때문에 파일의 메타 데이터를 여러 번 쿼리하는 것이 저렴하지만 메타 데이터를 쿼리하는 것과 메타 데이터를 쿼리하지 않는 것 사이에는 상당한 차이가있을 수 있습니다.

find훨씬 더 영리합니다. 불필요한 시스템 호출을 피하려고 시도합니다. getxattr확장 된 속성을 기반으로 검색하지 않기 때문에 호출 되지 않습니다. 디렉토리를 순회하는 경우 lstat일치하지 않는 파일 이름 을 호출해야 할 수 있습니다. 이는 일치하는 하위 디렉토리 일 수 있기 때문입니다 ( lstat정규 / 디렉토리 / symlink /…와 같은 파일 유형을 포함하여 파일 메타 데이터를 리턴하는 시스템 호출입니다). 그러나 find최적화 기능이 있습니다. 디렉토리가 링크 수 에서 몇 개의 서브 디렉토리를 가지고 있는지 lstat알고 있으며 모든 서브 디렉토리를 순회하는 것으로 알게되면 호출을 중지 합니다. 특히 리프 디렉토리 (하위 디렉토리가없는 디렉토리)에서find메타 데이터가 아닌 이름 만 확인합니다. 또한 일부 파일 시스템은 파일 유형의 사본을 디렉토리 항목에 보관하므로 find필요한 lstat정보 만 있으면 호출 할 필요가 없습니다 .

find메타 데이터를 확인해야하는 옵션으로 실행 하는 경우 더 많은 lstat호출을 수행하지만 lstat정보가 필요하지 않은 경우 파일을 계속 호출하지 않습니다 (예 : 파일이 이전 조건에 의해 제외 되었기 때문에) 이름과 일치).

find휠 을 재발 명하는 다른 GUI 검색 도구가 수십 년 동안 최적화를 거친 명령 줄 유틸리티보다 덜 영리 하다고 생각합니다 . Dolphin은 "어디서나"(UI에서 결과가 최신이 아닐 수 있다는 한계가 있음)를 검색 할 경우 찾기 데이터베이스를 사용할 정도로 영리합니다.

— 질 'SO- 악마 그만해'
소스

GNU find는 매우 "영리한"파일 형식으로 일부 파일이 누락되었습니다. GNU find에서 잘 알려진 버그는 디렉토리의 링크 카운트가 불법이라고 가정한다는 것입니다. 2 + number of sub-directories.이것은 UNIX V7 파일 시스템에서 디자인 버그를 구현하는 파일 시스템에서는 작동하지만 POSIX 요구 사항이 아니기 때문에 모든 파일 시스템에서는 작동하지 않습니다. . GNU make에 유용한 성능 번호를 얻으려면 -noleafGNU make가 올바르게 동작하도록 지시 해야 합니다.

— schily

@schily, GNU find는 오래 전에 그 버그를 가지고 있었을 지 모르지만 -noleaf요즘 손 으로 지정 해야하는 경우를 찾지 못할 것 입니다. Linux에서 AFAICT getdents()( 적어도 readdir ())는 UDF, ISO-9660, btrfs 중 어떤 파일이 실제 파일 .이나 ..항목이없고 findOK로 작동하는지 알 수 있습니다. GNU find가 문제를 나타내는 경우를 알고 있습니까?

— Stéphane Chazelas

debian에서 썩은 genisoimage를 사용하여 "graft-points"를 사용하여 Rock Ridge 파일 시스템을 만들고 디렉토리의 링크 수는 임의의 값입니다. Rock Ridge는 링크 수와 ./ ..을 구현하므로 GNU find는 일반적으로 이러한 파일 시스템에서 모든 파일을 찾지는 않습니다.

— schily

@ StéphaneChazelas : 마지막으로 (내 석사 논문에 대해) 확인했을 때 버그는 <= 2가 아니라 정확히 2의 알려진 리프를 선언하여 수정되었습니다. 2+ 카운터를 구현하지 않는 파일 시스템은 모두 디렉토리 링크 수에 대해 1을 반환합니다. 모든 것이 좋다. 언젠가 누군가이 속성이없는 디렉토리에 하드 링크를하는 파일 시스템을 만들었다면 누군가 나쁜 날을 보낼 것입니다.

— Joshua

@schily, 데비안에서 genisoimage 1.1.11로 이식 점과 RR로 임의의 링크 수를 얻을 수 없었고 링크 수를 임의의 값으로 변경하기 위해 iso 이미지를 이진 편집해도 여전히 아무것도 보지 못했습니다. GNU 문제 find. 그리고 어떤 경우에, strace -v보여줍니다 getdents()GNU 찾기 링크 카운트 트릭을 사용하지 않도록 제대로 d_type = DT_DIR 디렉토리에 대한 반환합니다.

— Stéphane Chazelas 21:06에