여기서 쓸 내용을 더 잘 설명하기 위해 제목을 편집하십시오.
예를 들어 큰 파일을 펜 드라이브에 복사하면 진행률 창에 대부분의 시간이 실시간 및 완료율을 표시하지 못하는 것으로 추정되지만 모든 것이 완료되었다고 표시되는 경우가 있습니다. 닫힙니다. 펜 드라이브를 추출하여 여전히 사용 중이라고 말합니다. 펜 드라이브를 확인한 후에도 여전히 파일을 복사하고 있지만 진행률 창이 표시되지 않습니다.
큰 파일뿐만 아니라 많은 작은 파일에서도 발생합니다. 복사하면 진행률 표시 줄이 예를 들어 15 초라고 말하고 그 시간에 완료되지만 실시간은 1 분이 될 수 있으며 다음 45 초 동안 실제로 펜 드라이브의 표시등을보고 펜 드라이브가 있는지 확인해야합니다 그것에 대한 실제 활동입니다.
이 문제에 대한 수정이 얼마나 깊은 지 읽었으므로 수정 방법을 알고 싶지 않습니다. 내가 알고 싶은 것은 진행률 창에 복사 프로세스와 일치하지 않는 견적이 표시되는 이유입니다.
외부 장치의 캐시에 종속됩니까?
파일 크기 및 파일 양이 올바른 추정에 영향을 미칩니 까? 예를 들어 4GB의 1 개 파일 또는 4MB의 1000 개 파일이 있습니다.
동작을 변경할 수있는 구성 옵션이 있습니까?
USB 스틱에 파일을 복사하는 것과 같은 다른 질문이 있지만 완료되지 않은 이유에 대한 역학에 더 중점을 둡니다.
답변
파일 관리자로 노틸러스를 사용하고 있다고 가정하면 오랫동안 버그가 있다고 가정합니다. 민트, 페도라, 레드햇 등에 영향을주는 것은 너무나도 미미합니다. 우분투에는 이와 같은 문제가 없습니다.
썸네일보기를 끄는 것이 좋습니다. 다른 사람들은 “최신 커널”에 희망을 두지 만 여전히 존재합니다.
문제 = 빠르게 시작한 다음 느리게 진행됨 이것은 비동기로 마운트 될 때 캐시에 기록하기 때문에 캐시가 가득 차면 “실제”기록 속도가 표시되기 때문입니다.
해결 방법은 sudo cp /filetobecopied /dev/nameofdevice
답변
이것은 또한 해결책으로 좋은 대답입니다 :
https://unix.stackexchange.com/a/181236
그것은 말합니다 :
그렇게하는 이유는 프로그램이 “이 데이터 쓰기”라고 말하고 리눅스 커널은이를 디스크에 대기하기 위해 대기중인 메모리 버퍼에 복사 한 다음 “ok, done”이라고 말합니다. 그래서 프로그램은 모든 것을 복사했다고 생각합니다. 그런 다음 프로그램이 파일을 닫지 만 갑자기 버퍼가 디스크로 푸시되는 동안 커널이 대기합니다.
따라서 불행히도 프로그램은 버퍼를 모르기 때문에 버퍼를 플러시하는 데 걸리는 시간을 알려줄 수 없습니다.
고급 사용자 트릭을 사용하려면 / proc / sys / vm / dirty_bytes를 15728640 (15MB)과 같이 설정하여 Linux에서 사용하는 버퍼 크기를 줄일 수 있습니다. 이는 응용 프로그램이 실제 진행보다 15MB를 초과 할 수 없음을 의미합니다.
부작용은이 설정으로 컴퓨터의 데이터 쓰기 처리량이 낮을 수 있지만 전체적으로 많은 데이터를 쓰는 동안 프로그램이 오래 실행되고 있음을 알면 혼란 스럽습니다. 프로그램은 작업으로 완료된 것으로 보이지만 커널이 실제 작업을 수행함에 따라 시스템이 심하게 지연됩니다. dirty_bytes를 상당히 작은 값으로 설정하면 여유 메모리가 부족하고 갑자기 많은 양의 데이터를 쓰는 프로그램을 실행할 때 시스템이 응답하지 않는 것을 방지 할 수 있습니다.
그러나 너무 작게 설정하지 마십시오! 커널이 1/4 초 이하의 시간에 일반 하드 드라이브로 버퍼를 플러시 할 수 있다고 대략 15MB를 사용합니다. 시스템이 “게으른”느낌이 들지 않게합니다.