¿Por qué “kernel [0]: AFP_VFS afpfs_vnop_ioctl: afpfs_FindForkRef falló -1” desde MusicBrainz Picard al escribir en mi servidor AFP NAS?

1

Tengo un fallo muy extraño. La aplicación MusicBrainz Picard 1.3.2 , al escribir archivos de audio modificados en un almacenamiento conectado a la red (servidor de archivos NAS_, a veces arrojará cientos de estos Mientras se escupe, se cuelga con una pelota de playa giratoria hasta que la fuerza la dejo.

¿Qué está causando este bloqueo? ¿Cómo puedo prevenirlo? Cuando se produce el bloqueo, ¿qué puedo hacer para restablecer mi computadora o servidor de archivos o conexión para que el bloqueo deje de suceder?

Aumentaré las respuestas que incluso pueden aclarar a qué se refiere afpfs_FindForkRef . Por alguna razón, cuando busco este término, obtengo cero resultados en los motores de búsqueda Google y DuckDuckGo. Supongo que "afpfs" significa "Sistema de archivos de protocolo de archivo de Apple".

Aquí está el registro de mensajes alrededor del momento en que Forzé Salir de la aplicación bloqueada:

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

Tenga en cuenta que el mensaje "el kernel superó los 500 mensajes de registro por segundo". Cuando esta aplicación se cuelga, parece que está generando ese mensaje de registro tan rápido como su bucle interno lo permitirá.

Esto no ocurrió antes hoy, trabajando en otros datos. Ocurre ahora. Ocurrió hace unos días, con datos anteriores. Mientras tanto, algo lo hizo detenerse.

Otras aplicaciones no provocan este problema en este momento. Si tengo esta aplicación, escriba en mi disco local en lugar de en el servidor de archivos NAS, el problema no se produce. Si desconecto y vuelvo a conectar el servidor de archivos, el problema vuelve a ocurrir. En el pasado, cuando reinicié tanto mi Mac como el servidor de archivos, el problema volvió a surgir, pero esta vez no lo he intentado.

Mi computadora : MacBook Pro Retina, a mediados de 2014, con OS X Yosemite 10.10.5

La aplicación : MusicBrainz Picard 1.3.2 , que agrega metadatos a los archivos de audio y mueve los archivos a un directorio de destino.

La ruta de origen : ruta de un archivo de música en el servidor de archivos, por ejemplo. 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 caracteres)

La ruta de destino : ruta de un archivo de música modificado en el servidor de archivos, por ejemplo. 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 caracteres)

El servidor de archivos : un QNAP TS- 219P , alrededor de 5 años

La conexión : a través de una entrada en el panel izquierdo de una ventana del Finder, "myServer (AFP)", con una imagen de la casilla del servidor como vista previa. Cuando hago un clic derecho en este ícono y selecciono "Obtener información" en el menú emergente, aparece una ventana de información. En él, la "Información general" dice: "Tipo: Mac, Dónde: Red". Se lee "Más información", (un ícono giratorio) con el mensaje, "Obteniendo ...".

El volumen : el servidor NAS tiene varios volúmenes de sistema de archivos. El volumen en cuestión se llama "Qmultimedia", con una caja de disco y una caricatura de tres humanoides como vista previa. Cuando hago un clic derecho en este ícono y selecciono "Obtener información" en el menú emergente, aparece una ventana de información. En él, lee "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)

El informe de bloqueo : hay mucho en el informe de bloqueo, / Library / Logs / DiagnosticReports / MusicBrainz Picard_2016-09-03-233838_MyMac.hang, pero aquí hay algunos aspectos destacados:

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

Las entradas anidadas por debajo de hndl_unix_scall64 parecen tener que ver con los mensajes de registro, así que supongo que de ahí provienen los mensajes. Supongo que el símbolo hndl_unix_scall64 está cerca de donde las llamadas salen mal.

Actualizado el 2016-09-04 : se agregaron ejemplos de rutas originales y de destino. Además, añade este hallazgo diagnóstico. Cuando uso el script interno de Picard para truncar la longitud de sus segmentos de ruta a 160 caracteres, el archivo se guarda correctamente. Los afpfs_FindForkRef failed -1 todavía se vierten en el registro de la consola por cientos, pero solo por un par de segundos. Luego se detienen, y Picard no se cuelga. Por lo tanto, la longitud total de la ruta, o la longitud de los segmentos de la ruta, puede ser relevante.

    
pregunta Jim DeLaHunt 04.09.2016 - 10:05

1 respuesta

1

De la experimentación, aquí hay una solución.

Utilice secuencias de comandos de Picard para limitar la longitud de cada segmento de la ruta a la que cambia el nombre de los archivos de música. Esto evita que la caída dure mucho tiempo, lo que responde a una de las preguntas.

En Opciones de nombre de archivo de Picard , use la función de script $truncate(field,length) para limitar el tamaño de cada ruta segmento. Así, en lugar de:

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

use esto (y el límite 160 es arbitrario; 300 y 100 también parecen funcionar):

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

No hay evidencia de que el bloqueo sea un problema de estado. Parece estar provocada de forma reproducible por el comportamiento de la aplicación. Por lo tanto, aparte de cambiar el script que ejecuta Picard, no es necesario reiniciar la computadora o el servidor. Eso responde a otra de las preguntas.

Esto todavía no responde a las causas de este bloqueo y cómo evitarlo en la causa raíz.

    
respondido por el Jim DeLaHunt 05.09.2016 - 00:38

Lea otras preguntas en las etiquetas