☰

ls -f의 요점은 무엇입니까(또는 왜 멈추나요?)

tag-icon • tag-icon linux ls gnu coreutils
ls -f의 요점은 무엇입니까(또는 왜 멈추나요?)

약 100,000개의 파일이 있는 디렉토리가 있습니다. ls -f가 1분 넘게 중단됩니다. 나는 strace를 실행하고 즉시 getdent를 보기 시작했기 때문에 디렉토리를 명확하게 읽었습니다. 또한 brk에 대한 호출이 많이 있으므로 ls가 메모리에 버퍼링하는 것이 분명합니다. 나는 readdir을 호출하고 파일 이름을 출력하는 간단한 프로그램을 작성했으며 즉시 응답합니다. 그러나 ls -f는 출력을 제공하지 않습니다. 무엇을 제공합니까? 내 생각에 -f의 요점은 ls가 readdir만 수행하게 한다는 것입니다. 디렉토리의 내용을 나열하는 이식 가능하고 안정적인 방법이 있습니까? (참고로 이는 Linux의 gnu coreutils에 있는 ls입니다.)

-편집하다-

별칭도 있는데 "/bin/ls -1f > /dev/null"은 8~15초 걸리고, "/bin/ls -1fx > /dev/null"은 4~11초 걸리지만 간단한 프로그램 readdir만 가능 0.011초가 소요됩니다. gnu ls를 덜 끔찍하게 만들려면 어떻게 해야 합니까?

답변1

요점 -f은 각 파일 항목을 계산할 필요가 없도록 하고 항목을 표시하기 전에 모든 파일 항목을 읽을 필요가 없도록 하는 것입니다. 다른 옵션을 비활성화하는 "메타" 옵션입니다.

그렇습니다. 여러분의 기대에 부응해야 합니다. 왜 그렇지 않은지 대답할 수는 없지만 쉘 별칭이나 명령에 추가 옵션을 삽입하는 것이 있을 수 있다고 추측합니다. 이는 기능을 비활성화하는 것이 아니라 다시 활성화할 수 -f있으며 "보다 구체적인" 것으로 간주되므로 우선순위를 부여하십시오.

답변2

coreutils 7.0에 추가된 최적화(8d974b00fbbc2025de63e1e6d54827648fefa1c4 커밋):

2008-08-01  Kamil Dudka  <[email protected]>
    ls -U1 now uses constant memory
    When printing one name per line and not sorting, ls now uses
    constant memory per directory, no matter how many files are in
    the directory.
    * ls.c (print_dir): Print each file name immediately, when possible.
    * NEWS: Mention the improvement.

가장 먼저 떠오르는 설명은 이전 버전의 coreutils를 실행하고 있다는 것입니다. 업그레이드해야 합니다.

관련 정보