AFP NAS 서버에 쓸 때 “커널 [0] : AFP_VFS afpfs_vnop_ioctl : afpfs_FindForkRef 실패 -1″이 MusicBrainz Picard에서 쏟아지는 이유는 무엇입니까? D. 759 “Unfinished”- I.

매우 이상한 실패가 있습니다. 수정 된 오디오 파일을 NAS (Network Attached Storage) 파일 서버에 쓸 때 MusicBrainz Picard 1.3.2 앱 이이 메시지를 수백 개씩 뿌릴 수 있습니다.

이 중단의 원인은 무엇입니까? 어떻게 방지 할 수 있습니까? 중단이 발생하면 컴퓨터 또는 파일 서버 또는 연결을 재설정하여 중단이 발생하지 않도록하려면 어떻게해야합니까?

나는 무엇을 afpfs_FindForkRef의미 하는지 밝힐 수있는 대답을지지 할 것이다. 어떤 이유로이 용어를 검색하면 Google 및 DuckDuckGo 검색 엔진에서 조회수가 없습니다. “afpfs”는 “Apple Filing Protocol File System”의 약자라고 생각합니다.

중단 된 앱을 강제 종료 할 때의 메시지 로그는 다음과 같습니다.

....
2016-09-03 23:38:15.000 kernel[0]: AFP_VFS afpfs_vnop_ioctl:  afpfs_FindForkRef failed -1
2016-09-03 23:38:15.000 kernel[0]: AFP_VFS afpfs_vnop_ioctl:  afpfs_FindForkRef failed -1
2016-09-03 23:38:15.000 kernel[0]: AFP_VFS afpfs_vnop_ioctl:  afpfs_FindForkRef failed -1
2016-09-03 23:38:15.000 kernel[0]: *** kernel exceeded 500 log message per second limit  -  remaining messages this second discarded ***
2016-09-03 23:38:15.881 com.apple.xpc.launchd[1]: (org.musicbrainz.picard.79268[5403]) Service exited due to signal: Killed: 9
2016-09-03 23:38:20.927 SystemUIServer[1443]: Attempt to use XPC with a MachService that has HideUntilCheckIn set. This will result in unpredictable behavior: com.apple.backupd.status.xpc
2016-09-03 23:38:38.069 spindump[1708]: Saved hang report for MusicBrainz Picard version 1.3.2 (Picard 1.3.2) to /Library/Logs/DiagnosticReports/MusicBrainz Picard_2016-09-03-233838_MyMac.hang

“커널이 초당 500 개의 로그 메시지를 초과했습니다”메시지에 유의하십시오. 이 응용 프로그램이 중단되면 내부 루프가 허용하는 한 빨리 로그 메시지를 생성하는 것처럼 보입니다.

이것은 다른 데이터에 대한 작업으로 오늘 일찍 발생하지 않았습니다. 지금 발생합니다. 이전 데이터와 함께 며칠 전에 발생했습니다. 그 사이에 무언가가 멈추었습니다.

다른 앱은 현재이 문제를 일으키지 않습니다. 이 앱을 NAS 파일 서버 대신 로컬 디스크에 쓰면 문제가 발생하지 않습니다. 파일 서버 연결을 끊었다가 다시 연결하면 문제가 다시 발생합니다. 과거에는 Mac과 파일 서버를 모두 다시 시작했을 때 문제가 다시 발생했지만 이번에는 시도하지 않았습니다.

내 컴퓨터 : MacBook Pro Retina, 2014 년 중반, OS X Yosemite 10.10.5 실행

앱 : MusicBrainz Picard 1.3.2- 오디오 파일에 메타 데이터를 추가하고 파일을 대상 디렉토리로 이동합니다.

소스 경로 : 파일 서버의 음악 파일 경로 u'/Volumes/Qmultimedia/Music/_inbox/_tracks/Vancouver Academy of Music Symphony Orchestra/VAM Mozart Requiem 2014/02 Symphony No. 8 D. 759 "Unfinished"- I. Allegro moderato.flac'( 예 : (175 자)

대상 경로 : 파일 서버에서 수정 된 음악 파일의 경로 u'/Volumes/Qmultimedia/Music/master_tagged_files/Mozart, Wolfgang Amadeus, Schubert, Franz; Vancouver Academy of Music Symphony Orchestra, Dala, Leslie, Wood, Caitlin, Froese, Laurelle Jade, Rupolo, Rocco, Read, Zachary, Vancouver Bach Choir/Mozart Requiem _ Schubert _Unfinished_ Symphony/02 Symphony No. 8 in B minor, D. 759 _Unfinished__ I. Allegro moderato.flac'( 예 : (363 자)

파일 서버 : 약 5 세 QNAP TS-219P

연결 : 서버 상자 이미지를 미리보기로 사용하여 Finder 창의 왼쪽 창 “myServer (AFP)”에있는 항목을 통해 연결 합니다. 이 아이콘을 마우스 오른쪽 버튼으로 클릭하고 팝업 메뉴에서 “정보 입수”를 선택하면 정보 창이 나타납니다. “일반 정보”에는 “종류 : Mac, 위치 : 네트워크”가 있습니다. “추가 정보”는 “Fetching …”메시지와 함께 (회전하는 아이콘)을 읽습니다.

볼륨 : NAS 서버에는 여러 파일 시스템 볼륨이 있습니다. 해당 볼륨의 이름은 “Qmultimedia”로, 디스크 인클로저 박스와 3 개의 휴머노이드 만화가 미리보기로 표시됩니다. 이 아이콘을 마우스 오른쪽 버튼으로 클릭하고 팝업 메뉴에서 “정보 입수”를 선택하면 정보 창이 나타납니다. “General”은 다음과 같이 읽습니다.

Server: afp://Gemini(AFP)._afpovertcp._tcp.local/Qmultimedia
Created: Sunday, 21. December, 2014 at 14:18
Modified: Today, 00:48
Format: AppleShare
Capacity: 2.95 TB
Available: 1.48 TB
Used: 1,474,284,388,352 bytes (1.47 TB on disk)

중단 보고서 : 중단 보고서 / Library / Logs / DiagnosticReports / MusicBrainz Picard_2016-09-03-233838_MyMac.hang에는 많은 내용이 있지만 다음과 같은 주요 내용이 있습니다.

Event:           hang
Duration:        4.70s (process was unresponsive for 31 seconds before sampling)
Steps:           48 (100ms sampling interval)

Heaviest stack for the main thread of the target process:
  48  start + 52 (MusicBrainz Picard + 3044) [0x100000be4]
  48  main + 650 (MusicBrainz Picard + 4474) [0x10000117a]
  48  py2app_main + 2683 (MusicBrainz Picard + 10075) [0x10000275b]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 943050) [0x1040353ca]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 942382) [0x10403512e]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 792742) [0x1040108a6]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 792454) [0x104010786]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 785344) [0x10400ebc0]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 792454) [0x104010786]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 789242) [0x10400fafa]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 792454) [0x104010786]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 785344) [0x10400ebc0]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 792454) [0x104010786]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 787402) [0x10400f3ca]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 784253) [0x10400e77d]
  48  ??? (<F57E8887-372A-E630-588B-1148CCA29919> + 3464844) [0x107efbe8c]
  48  ??? (<4172EABD-46BE-2722-C849-F7FB5632DED2> + 1324428) [0x10918158c]
  48  ??? (<4172EABD-46BE-2722-C849-F7FB5632DED2> + 1314468) [0x10917eea4]
  48  ??? (<4172EABD-46BE-2722-C849-F7FB5632DED2> + 1313524) [0x10917eaf4]
  48  ??? (<CD803C71-F94D-524C-1A39-07D1A339A0F0> + 272000) [0x108485680]
  48  -[NSApplication run] + 594 (AppKit + 551667) [0x7fff837caaf3]
  48  -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 346 (AppKit + 593496) [0x7fff837d4e58]
  48  _DPSNextEvent + 978 (AppKit + 596139) [0x7fff837d58ab]
  48  _BlockUntilNextEventMatchingListInModeWithFilter + 71 (HIToolbox + 205099) [0x7fff8f07812b]
  48  ReceiveNextEventCommon + 179 (HIToolbox + 205294) [0x7fff8f0781ee]
  48  RunCurrentEventLoopInMode + 235 (HIToolbox + 206191) [0x7fff8f07856f]
  48  CFRunLoopRunSpecific + 296 (CoreFoundation + 465880) [0x7fff887abbd8]
  48  __CFRunLoopRun + 927 (CoreFoundation + 467391) [0x7fff887ac1bf]
  48  __CFRunLoopDoSources0 + 269 (CoreFoundation + 469901) [0x7fff887acb8d]
  48  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 526849) [0x7fff887baa01]
  48  ??? (<4172EABD-46BE-2722-C849-F7FB5632DED2> + 1323008) [0x109181000]
  48  ??? (<4172EABD-46BE-2722-C849-F7FB5632DED2> + 1317852) [0x10917fbdc]
  48  ??? (<F57E8887-372A-E630-588B-1148CCA29919> + 3461518) [0x107efb18e]
  48  ??? (<CD803C71-F94D-524C-1A39-07D1A339A0F0> + 588900) [0x1084d2c64]
  48  ??? (<CD803C71-F94D-524C-1A39-07D1A339A0F0> + 562669) [0x1084cc5ed]
  48  ??? (<F57E8887-372A-E630-588B-1148CCA29919> + 3465277) [0x107efc03d]
  48  ??? (<CFFC31D5-41BF-BC16-2650-C745627427E7> + 26259) [0x104715693]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 933631) [0x104032eff]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 759914) [0x10400886a]
  48  ??? (<96E177D6-BA68-399D-7325-FAA0DD7247EB> + 1026148) [0x104049864]
  48  __psynch_cvwait + 10 (libsystem_kernel.dylib + 90422) [0x7fff8275b136]
 *48  psynch_cvcontinue + 0 (pthread + 26910) [0xffffff7f80f9991e]
....
  Thread 0x13ac3a     48 samples (1-48)   priority 31         cpu time 4.697s
  <thread QoS legacy, boosted, received importance donation from WindowServer [189], IO policy important>
  48  thread_start + 13 (libsystem_pthread.dylib + 5101) [0x7fff8dd113ed] 1-48
    48  _pthread_start + 176 (libsystem_pthread.dylib + 16343) [0x7fff8dd13fd7] 1-48
      48  _pthread_body + 131 (libsystem_pthread.dylib + 16474) [0x7fff8dd1405a] 1-48
        48  ??? (<4172EABD-46BE-2722-C849-F7FB5632DED2> + 161492) [0x1090656d4] 1-48
....
                                                                    48  __fcntl + 10 (libsystem_kernel.dylib + 88482) [0x7fff8275a9a2] 1-48
                                                                     *34  hndl_unix_scall64 + 22 (kernel + 2311718) [0xffffff8000434626] 1-34
....
                                                                     *1   hndl_unix_scall64 + 10 (kernel + 2311706) [0xffffff800043461a] (running) 35
                                                                     *13  hndl_unix_scall64 + 22 (kernel + 2311718) [0xffffff8000434626] 36-48
....

아래에 중첩 된 항목 hndl_unix_scall64은 로그 메시지와 관련이있는 것처럼 보이므로 메시지가 나온 곳이라고 생각합니다. 나는 그 기호 hndl_unix_scall64가 전화가 잘못되는 곳 근처에 있다고 생각합니다 .

2016-09-04 업데이트 : 원본 및 대상 경로의 예가 추가되었습니다. 또한이 진단 결과를 추가하십시오. Picard의 내부 스크립팅을 사용하여 경로 세그먼트의 길이를 160 자로 자르면 파일 저장이 성공합니다. 은 afpfs_FindForkRef failed -1여전히 수백 콘솔 로그에 부어 있지만 몇 초에 있습니다. 그런 다음 멈추고 Picard는 멈추지 않습니다. 따라서 경로의 전체 길이 또는 경로의 세그먼트 길이가 관련 될 수 있습니다.

답변

실험에서 해결 방법이 있습니다.

Picard의 스크립팅 을 사용 하여 음악 파일 이름을 바꿀 경로의 각 세그먼트 길이를 제한하십시오. 이것은 교수형이 오래 지속되는 것을 방지하여 질문 중 하나에 대답합니다.

에서 피카드의 파일 이름 지정 옵션 , 스크립트 기능을 사용하여 $truncate(field,length)각 경로 세그먼트의 크기를 제한 할 수 있습니다. 따라서 다음 대신

$if2(%albumartistsort%,%artist%)/%album/
$if($gt(%totaldiscs%,1),%discnumber%)$num(%tracknumber%,2) %title%

이것을 사용하십시오 (한도 160은 임의적입니다; 300 및 100도 작동하는 것 같습니다).

$truncate($if2(%albumartistsort%,%artist%),160)/$truncate(%album%,160)/
$truncate($if($gt(%totaldiscs%,1),%discnumber%)$num(%tracknumber%,2) %title%,160)

중단이 상태 문제라는 증거는 없습니다. 응용 프로그램의 동작에 의해 재현 가능한 것으로 보입니다. 따라서 Picard를 실행하는 스크립트를 변경하는 것 외에 컴퓨터 나 서버를 재설정 할 필요가 없습니다. 그것은 또 다른 질문에 대한 답입니다.

이것은 여전히이 중단의 원인과 근본 원인을 방지하는 방법에 대한 답변을 제공하지 않습니다.

답변