배경

나는 뛰고있어뮤직 브레인 피커드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가 없어서 확인할 수 없음)...

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