Linux splice() + kernel AIO quando si scrive su disco

Question

Con il kernel AIO e O_DIRECT|O_SYNC, non c'è copia nei buffer del kernel ed è possibile ottenere una notifica a grana fine quando i dati vengono effettivamente scaricati sul disco. Tuttavia, richiede che i dati vengano conservati nei buffer dello spazio utente per io_prep_pwrite().

Con splice(), è possibile spostare i dati direttamente sul disco dai buffer di spazio del kernel (pipe) senza doverli mai copiare. Tuttavia, splice() restituisce immediatamente dopo l'accodamento dei dati e non attende la scrittura effettiva sul disco.

L'obiettivo è spostare i dati da socket a disco senza copiarli mentre si riceve la conferma che è stato eliminato. Come combinare entrambi gli approcci precedenti?

Combinando splice() con O_SYNC, mi aspetto che splice() blocchi e si debbano utilizzare più thread per mascherare la latenza. In alternativa, è possibile utilizzare lo standard asincrono io_prep_fsync()/io_prep_fdsync(), ma questo attende che tutti i dati vengano svuotati, non per una scrittura specifica. Nessuno dei due è perfetto

Ciò che sarebbe necessario è una combinazione di splice() con kernel AIO, che consente la copia zero e la conferma asincrona delle scritture, in modo che un singolo thread guidato da eventi possa spostare i dati dai socket al disco e ottenere le conferme quando richiesto, ma ciò non sembra essere supportato C'è un buon approccio alternativo/alternativo?

Answer 1

Per ottenere una conferma delle scritture, non è possibile utilizzare splice().

C'è roba aio in userspace, ma se si stesse facendo nel kernel si potrebbe venire a scoprire (blocco I/O), che di bio sono generati e in attesa di quelli:

Block struttura di I/O :

• http://www.makelinux.net/books/lkd2/ch13lev1sec3

Se si desidera utilizzare AIO, è necessario utilizzare io_getevents():

• http://man7.org/linux/man-pages/man2/io_getevents.2.html

Ecco alcuni esempi su come eseguire AIO:

• http://www.fsl.cs.sunysb.edu/~vass/linux-aio.txt

Se lo si fa da userspace e utilizzare msync è ancora un po nell'aria se in realtà è ancora in rotazione.

msync() docs:

• http://man7.org/linux/man-pages/man2/msync.2.html

Potrebbe essere necessario ammorbidire le aspettative al fine di renderlo più robusto, perché potrebbe essere molto costoso per essere davvero sicuri che il le scritture sono fisicamente scritte su disco.

Lo standard tipico "più alto" per la garanzia di scrittura alla luce di qualcosa come l'eliminazione dell'alimentazione è un'operazione di registrazione su giornale che modifica lo spazio di archiviazione. Il diario stesso è solo append e puoi vedere se le voci sono complete quando la riproduci. L'ultimo diario potrebbe non essere completo, quindi qualcosa potrebbe essere potenzialmente perso.