Perché "kernel [0]: AFP_VFS afpfs_vnop_ioctl: afpfs_FindForkRef fallito -1" si riversa da MusicBrainz Picard quando si scrive sul server AFP NAS?

1

Ho un fallimento molto strano. L'app MusicBrainz Picard 1.3.2 , quando si scrivono file audio modificati su un Network Attached Storage (file server NAS_, qualche volta sputerà centinaia di questo messaggio. Mentre vomita, si blocca con una pallina da spiaggia rotante finché I Force non lo spegne.

Che cosa sta causando questo blocco? Come posso impedirlo? Quando si verifica il blocco, cosa posso fare per ripristinare il mio computer o il file server o la connessione in modo che il blocco si interrompa?

Voterò le risposte che possono anche far luce su ciò che afpfs_FindForkRef fa riferimento a. Per qualche ragione, quando cerco questo termine, ottengo zero risultati su Google e sui motori di ricerca di DuckDuckGo. Suppongo che "afpfs" sia l'acronimo di "Apple Filing Protocol File System".

Questo è il registro dei messaggi intorno all'istante in cui I Force chiude l'app appesa:

....
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

Nota il messaggio "kernel ha superato 500 messaggi di log al secondo". Quando questa app si blocca, sembra che stia generando quel messaggio di registro il più velocemente possibile dal suo ciclo interno.

Questo non si è verificato prima, lavorando su altri dati. Si verifica ora. Si è verificato pochi giorni fa, con dati precedenti. Nel frattempo, qualcosa lo ha fermato.

Al momento altre app non provocano questo problema. Se ho questa app scrivere sul mio disco locale invece che sul server di file NAS, il problema non si verifica. Se disconnetto e ricollego il file server, il problema si ripresenta. In passato, quando riavviavo sia il mio Mac che il file server, il problema si ripresentava, ma non l'ho provato questa volta.

Il mio computer : MacBook Pro Retina, a metà 2014, con OS X Yosemite 10.10.5

L'app : MusicBrainz Picard 1.3.2 , che aggiunge metadati ai file audio e sposta i file in una directory di destinazione.

Il percorso di origine : percorso di un file musicale sul file server, ad es. 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 caratteri)

Il percorso di destinazione : percorso di un file musicale modificato sul file server, ad es. 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 caratteri)

Il server di file : a QNAP TS- 219P , circa 5 anni

La connessione : tramite una voce nel riquadro di sinistra di una finestra del Finder, "myServer (AFP)", con un'immagine della casella del server come anteprima. Quando faccio clic con il pulsante destro del mouse su questa icona e selezioni "Ottieni informazioni" dal menu a comparsa, viene visualizzata una finestra Informazioni. In esso, "Informazioni generali" riporta "Tipo: Mac, dove: rete". "Più informazioni" legge, (un'icona rotante) con il messaggio "Recupero ...".

Il volume : il server NAS ha diversi volumi di file system. Il volume in questione è chiamato "Qmultimedia", con una scatola di contenimento del disco e un cartone animato di tre umanoidi come anteprima. Quando faccio clic con il pulsante destro del mouse su questa icona e selezioni "Ottieni informazioni" dal menu a comparsa, viene visualizzata una finestra Informazioni. In esso, "Generale" legge:

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)

Il rapporto di blocco : c'è molto nel rapporto sull'hang, / Library / Logs / DiagnosticReports / MusicBrainz Picard_2016-09-03-233838_MyMac.hang, ma qui ci sono alcuni punti salienti:

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
....

Le voci annidate al di sotto di hndl_unix_scall64 sembrano avere a che fare con i messaggi di log, quindi suppongo che sia da lì che i messaggi provengono. Suppongo che il simbolo hndl_unix_scall64 sia vicino a dove le chiamate vanno male.

Aggiornato al 2016-09-04 : aggiunti esempi di percorsi originali e di destinazione. Inoltre, aggiungi questo risultato diagnostico. Quando uso gli script interni di Picard per troncare la lunghezza dei suoi segmenti di percorso a 160 caratteri, il salvataggio del file ha esito positivo. Il afpfs_FindForkRef failed -1 è ancora versato nel log della console a centinaia, ma solo per un paio di secondi. Poi si fermano e Picard non si blocca. Pertanto, la lunghezza complessiva del percorso o la lunghezza dei segmenti del percorso potrebbero essere pertinenti.

    
posta Jim DeLaHunt 04.09.2016 - 10:05
fonte

1 risposta

1

Dalla sperimentazione, ecco una soluzione alternativa.

Utilizza script di Picard per limitare la lunghezza di ogni segmento del percorso in cui rinomini i file musicali. Ciò impedisce al blocco di durare a lungo, il che risponde a una delle domande.

Nelle opzioni di denominazione dei file di Picard , utilizza la funzione di script $truncate(field,length) per limitare la dimensione di ogni percorso segmento. Quindi, invece di:

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

usa questo (e il limite 160 è arbitrario, anche 300 e 100 sembrano funzionare):

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

Non ci sono prove che il blocco sia un problema di stato. Sembra essere provocato in modo riproducibile dal comportamento dell'applicazione. Quindi, oltre a cambiare lo script su cui è eseguito Picard, non è necessario ripristinare il computer o il server. Questo risponde ad un'altra delle domande.

Questo ancora non risponde a cosa causa questo blocco e come prevenirlo per la causa principale.

    
risposta data 05.09.2016 - 00:38
fonte

Leggi altre domande sui tag