> Hopefully I will get some attention from those that are responsible for
[ many days later, I find this amongst the lkml noise. ]
Yeah. This is used for performing concurrent asynchronous O_DIRECT
operations.
*nod*
Do you have any suggestions for locking constructs that RT would prefer?
The core problem is that async IO is in flight while no process holds
the usual locks in system calls. We don't want the blocks referenced by
IOs to be freed and realocated some where else while the IO is in
flight. Hence the i_alloc_sem acquiry in the file block modification
paths: vmtruncate - free, notify_change - a proxy for allocating writes.
The agents are:
- many tasks issuing concurrent async IO and exiting from system calls
while the IO is still in flight
- operations completed in interrupt handlers from storage devices
- tasks changing file block mapping via system calls
There's some long-term work to integrate the locking between the
buffered and O_DIRECT paths, but it's not close to ready.
- z
-
