On Tue, Aug 01, 2017 at 12:42:18PM +1000, Dave Chinner wrote:
I've outlined other use cases in previous discussions. To repeat
myself, every so often we get someone with, say, a new high
speed camera that want to dma the camera frames direct to the
storage because they can't push 500,000 frames/s through the CPU
to storage. Hence they want to bypass the OS and DMA the data direct
to the storage. To do this they need a mechanism to freeze and unfreeze
the block map of the file so that nothing modifies the block map
while the camera hardware is dumping data direct to the storage.
Immutable extent maps provide the functionality they need to
implement this safely.
And we have such a mechanism already: it's called the iolock during
I/O, and dirct I/O. I've worked on plenty such schemes and the proper way
works perfectly fine. Just because people ask for stupid ways to
archives that doesn't mean they understand what they are doing.
There's also other similar use cases for RDMA targets on PMEM
(regardless of whether DAX is enabled or not), and I've come across
a couple of requests for mechanisms to allow fabric based nvme
storage to do direct data transfers between storage devices, too.
All of these use cases can be safely implemented if there is a
mechanism to mark extent maps as immutable for the duration of
the operation they need to perform.
As someone who spent most of them time on the last 2 years in this
area: we have a massive problem discoverability and addressing
(lack of struct page) for p2p devices. We have absolutely no problem
with the direct I/O model with them.
DAX isn't the driver of that functionality, it's the other
that need it, and why the proposed "only remove flag if len == 0"
API is a non-starter....
The other "use" cases are even more bullshit than the DAX one.