RFC Btrfs Direct I/O for .34 maybe
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest3 patches 3 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | Btrfs: Full direct I/O and AIO read implementation.fs/ | +1902 | 0 replies | |
| 2/3 | export use_mm and unuse_mm for filesystem modules.mm/ | +1 | 3 replies | |
| 3/3 | Btrfs: enable direct I/O read support.fs/ fs/ | +3 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 00/03] Btrfs Direct I/O for .34 maybe
This is the completed code for direct I/O read. It handles all extent types, validates checksums, and does retries.
I have tested all the paths (on X86-64) but it needs testing with automation in a larger setup. If this design is acceptable, Eric Whitney will run those tests.
The code supports 512-byte-device access, which is one of the reasons for it being complex. But I believe people expect that so we should not take the easy way out by limiting it to btrfs block size access.
All completion/checksum/decompression processing occurs in 1 thread rather than being spread out. This is intentional because that way directIO scales with multiple users and does not eat all resources.
The code requires use_mm() to permit 2 worker threads to make calls to get_user_pages_fast(). One worker is the completion reaper. The other worker is for aio submit so we return control immediately to the application before any I/O is initiated. The INFO PATCH 02 is what I sent to Andrew Morton so that btrfs can be built as a module. I hope the only reason it was not put in 33 is he is waiting for a caller (my code) that needs it.
All of my previous patches except the one I retracted are required to use this code if anyone wants to try it.
I'm ready for comments, questions, insults, whatever.
jim