Well, I would have, except there weren't that many viable alternatives that don't involve one of: 1. Writing a lot of code that runs in the kernel, which is to

Well, I would have, except there weren't that many viable alternatives that don't involve one of: 1. Writing a lot of code that runs in the kernel, which is too expensive to be viable, in my estimation. 2. Combining existing kernel features together and living without making medium-sized adjustment for quite a while This was actually my back-up proposal if our experience with SPDK was bad. e.g., get deep into lvmthin and importing/exporting snapshots, but not having a graceful way to add, say, demand paging from an external data store. At some point we'd have to exercise option #1 or jack-knife to something more-like SPDK, which inevitably would be something of a discontinuity in our experience level and the customer experience of the product. I decided we could try to avoid jack-knifing and try to have continuity on SPDK. 3. Paying for extra context switches from user space to kernel space to user space again, at least once, and, sometimes, even additional times, if you need to add a bit of functionality and then use some mature kernel routines. A series of sandwiches. The polling is wasteful if the server is not doing much, and not bad at all if there's a lot of I/O going on. We'll probably enable and get into tweaking adaptive hybrid polling option in SPDK to quiet things down on machines not running full-bore I/O. SPDK has a lot in there, getting the logical volume and encryption features, as well as the plumbing for vfio-user, is significant. There are not many options that have this programming, and a programming model to add more. I also found the code and changes to it fairly readable, and the size of the code, e.g. in lvol, approachable.