picard - Linux splice()+kernel AIO al escribir en el disco
musicbrainz picard (1)
Con el kernel AIO y O_DIRECT|O_SYNC , no hay copia en los buffers del kernel y es posible obtener una notificación detallada cuando los datos se descargan en el disco. Sin embargo, requiere que los datos se io_prep_pwrite() en buffers de espacio de usuario para io_prep_pwrite() .
Con splice() , es posible mover datos directamente al disco desde los buffers de espacio del núcleo (tuberías) sin tener que copiarlos nunca. Sin embargo, splice() devuelve inmediatamente después de que los datos se ponen en cola y no espera las escrituras reales en el disco.
El objetivo es mover los datos de los sockets al disco sin copiarlos mientras se obtiene la confirmación de que se ha vaciado. ¿Cómo combinar los dos enfoques anteriores?
Al combinar splice() con O_SYNC , espero que splice() bloquee y uno tiene que usar múltiples hilos para enmascarar la latencia. Alternativamente, se podría usar io_prep_fsync() / io_prep_fdsync() , pero esto espera a que se io_prep_fdsync() todos los datos, no a una escritura específica. Tampoco es perfecto.
Lo que se requeriría es una combinación de splice() con el núcleo AIO, que permita la copia cero y la confirmación asíncrona de las escrituras, de manera que un solo hilo controlado por eventos puede mover datos de los sockets al disco y obtener confirmaciones cuando sea necesario, pero esto no parecen ser apoyados ¿Hay una buena solución alternativa / enfoque alternativo?
Para obtener una confirmación de las escrituras, no puede usar splice ().
Hay cosas de aio en el espacio de usuario, pero si lo estuvieras haciendo en el kernel podría llegar a descubrir qué bio''s (bloque I / O) se generan y esperarlas:
Bloque de estructura de E / S:
Si desea utilizar AIO, deberá usar io_getevents ():
Aquí hay algunos ejemplos de cómo realizar AIO:
Si lo haces desde el espacio de usuario y usas msync , todavía está un poco en el aire si aún está en herrumbre.
msync () docs:
Es posible que deba suavizar las expectativas para hacerlo más robusto, ya que puede ser muy costoso estar realmente seguro de que las escrituras están escritas físicamente en el disco.
El estándar típico "más alto" para la garantía de escritura a la luz de algo como la eliminación de energía es una operación de registro de diario que modifica el almacenamiento. El diario en sí está solo adjunto y puede ver si las entradas están completas cuando lo reproduce. Es posible que la última entrada de diario no esté completa, por lo que es posible que aún se pierda algo.