☰

배경

tag-icon • tag-icon io ntfs lsof
배경

배경

나는 뛰고있어뮤직 브레인 피커드USB를 통해 연결되고 autofs를 사용하여 마운트된 500GB NTFS 디스크(Transcend StoreJet)에서 ~11M ogg 파일을 업데이트했습니다. 도킹 스테이션을 통해 연결합니다. 나는 확신할 수 없다언제나제대로 제거하세요..

내 걱정은 작업이 너무 오래 걸릴 것이라는 점이었습니다. 전체 폴더가 몇 분 안에 처리될 것으로 예상했지만 몇 시간이 걸렸을 수도 있습니다. 내가 불 때아이오톱(1), 이는 ~25K/s의 디스크 쓰기를 보고하며, 그 중 ~99%는 picard 프로세스에 대한 것입니다. (Picard가 완전히 정지되지 않으며 GUI가 몇 분 내에 새로 고쳐지거나 응답합니다).

약간의 진전을 보기 위해 lsof를 계속 확인합니다. 전체 출력은 다음과 같습니다.

$ lsof /mnt/greeno-ntfs
COMMAND  PID    USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
picard  2885 amahdal  mem    REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg
picard  2885 amahdal   14u   REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg
picard  2885 amahdal   16u   REG   8,17 11121609 44661 /mnt/greeno-ntfs/path/to.ogg

그러나 나는 모든 관찰을 실제로 이해할 수는 없습니다. 단지 몇 가지 가정만 할 수 있을 뿐입니다. 그래서 여기에 물어볼까 하는 생각이 들었습니다.

질문

  • 파일에 FD가 3개 있는 것이 정상인가요? 하나의 "메모리"와 두 개의 "일반"?

    파일을 열고 업데이트하기 위한 간단한 스크립트를 작성해 보았지만(그 사이에 잠자기까지 오랜 시간이 걸림) 일반 FD( 5u)만 있으므로 일반 열기는 이와 같이 작동하지 않습니다.

    가설: 이는 Picard(또는 해당 라이브러리)가 의도적으로 해석한 잠재적으로 긴 파일 I/O를 처리하기 위한 (아마도 보편적인) 기술의 결과입니다. 그렇다면 누군가 설명해 줄 수 있습니까? (예를 들어 왜 2+1인가요?)

  • 내가 본 것처럼 SIZE/OFFSET 열은 실제로축소 시간이 지남에 따라.

    가설: 이는 Picard가 실제로 내부 파일을 찾아 업데이트하는 것과 일치합니다. 그렇죠?

무작위 가설 - 이 시점에서 가능한 원인으로 이해되는 가설이 있습니까?

  • Picard에는 버그가 있습니다(업데이트/축소 효율성은 매우 비효율적입니다).

  • 디스크에 오류가 발생했습니다(예5세 이상...),

  • 파일 시스템 마운트 오류(ntfs를 최적으로 마운트하는 방법을 아는 사람이 있습니까?)

  • 도킹 해제/도킹으로 인해 파일 시스템이 손상되었습니다(chkdsk가 없어서 확인할 수 없음)...

그럼 다음은 무엇입니까? 무슨 일이 일어나고 있는지 이해하기 위해 다음에 무엇을 볼 수 있습니까?

답변1

Picard에 문제가 있다는 사실을 제외하면 추측은 테스트하기 쉽습니다. 파일 크기가 실제로 11MB에 불과한 경우 간단히 /dev/shm(RAM) 또는 기본 파일 시스템에 복사하여 테스트하세요.

나는 확실히 NTFS가 훨씬 더 느리고 더 많은 CPU를 사용하기를 원하지만 일반적으로 몇 분에서 몇 시간으로 변하지는 않습니다. 가장 먼저 테스트해야 할 것은 ntfs를 피하는 것입니다.

lsof 출력은 매우 이상할 수 있습니다. 두 번째 출력이 해당 pid만 나열하더라도 "lsof -p $pid"도 "lsof /path"와 다른 출력을 갖는 경우가 있습니다. 그래서 나는 이것이 "정상"인지 알아내려고 노력하지 않을 것입니다.

파일 검색 및 쓰기를 이해하려면 lsof가 아닌 strace를 사용해야 합니다.

관련 정보