fuse: An attempt to implement a write-back cache policy
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest6 of 10 patches 32 repliesIn review
6 of 10 patches are in this archive. The cover letter announces 10.
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/10 | fuse: Linking file to inode helperfs/ | +19 | 0 replies | |
| 2/10 | fuse: Getting file for writeback helperfs/ | +15 | 0 replies | |
| 3/10 | fuse: Prepare to handle short readsfs/ | +12 | 0 replies | |
| 4/10 | fuse: Prepare to handle multiple pages in writebackfs/ | +14 | 2 replies | |
| 6/10 | fuse: Trust kernel i_size onlyfs/ fs/ fs/ | +31 | 9 replies | |
| 10/10 | mm: Account for WRITEBACK_TEMP in balance_dirty_pagesmm/ | +2 | 5 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/10] fuse: An attempt to implement a write-back cache policy
Hi everyone.
One of the problems with the existing FUSE implementation is that it uses the write-through cache policy which results in performance problems on certain workloads. E.g. when copying a big file into a FUSE file the cp pushes every 128k to the userspace synchronously. This becomes a problem when the userspace back-end uses networking for storing the data.
A good solution of this is switching the FUSE page cache into a write-back policy. With this file data are pushed to the userspace with big chunks (depending on the dirty memory limits, but this is much more than 128k) which lets the FUSE daemons handle the size updates in a more efficient manner.
The writeback feature is per-connection and is explicitly configurable at the init stage (is it worth making it CAP_SOMETHING protected?) When the writeback is turned ON:
* still copy writeback pages to temporary buffer when sending a writeback request and finish the page writeback immediately
* make kernel maintain the inode's i_size to avoid frequent i_size synchronization with the user space
* take NR_WRITEBACK_TEMP into account when makeing balance_dirty_pages decision. This protects us from having too many dirty pages on FUSE
The provided patchset survives the fsx test. Performance measurements are not yet all finished, but the mentioned copying of a huge file becomes noticeably faster even on machines with few RAM and doesn't make the system stuck (the dirty pages balancer does its work OK). Applies on top of v3.5-rc4.
We are currently exploring this with our own distributed storage implementation which is heavily oriented on storing big blobs of data with extremely rare meta-data updates (virtual machines' and containers' disk images). With the existing cache policy a typical usage scenario -- copying a big VM disk into a cloud -- takes way too much time to proceed, much longer than if it was simply scp-ed over the same network. The write-back policy (as I mentioned) noticeably improves this scenario. Kirill (in Cc) can share more details about the performance and the storage concepts details if required.
Thanks,
Pavel