From Fedora Project Wiki

Implement nfs/fscache writeback cache

GSOC 2012/Student Application FedoraUsername

Proposal Description

Overview

Currently, the flashcache/bcache only serves for local file systems such as ext3 and reiserfs. For network file systems, NFS implements a disk cache based on fscache/cachefiles, but it has two limitations: a) It only supports read-only opened file. b) It only supports write-through cache but no write-back. These two limitations may confine the performance of some NFS clients which have intensive write operations. Our project is to implement such a write-back cache for NFS and deliver patches to Linux kernel, so that all write intensive clients deployed upon NFS such as backup server and distributed MySQL could benefit from it.

Benefit

All write intensive clients deployed upon NFS, especially with SSD or flash storage, would benefit from it. Such as backup server and distributed MySQL.

Relevant Experience

I implemented a route protocol in kernel space which covered TCP/IP protocol stack, netlink communication between user space and kernel space, /proc file system, timer and so on.

I used to develop Meego camera driver at Intel which covered multi-threads, IRQ handling, page manipulation, system calls implementation such as open() write() mmap() ioctl().

Implementation

  1. Enable fscache for read-write opened file.
  2. Cache pages which flushed by kernel flusher threads from page cache into fscache. Maybe implement a fscache_writepages() interface or other.
  3. At file closes, explicitly flush all dirty pages from fscache to server to meet NFS close-to-open semantic.
  4. Design a background thread mechanism in fscache to write back dirty pages to server periodically. This mechanism should transparent to netfs. The write-back cycle could be slightly adjusted from user space via /proc or /sys.
  5. Improve write performance of cachefiles to cooperate with fscache better.
  6. Design test case and verify the performance improvement.
  7. Generate patches and Documentation

Final Deliverable

Good pathes and document for this write-back fscache for nfs.

A rough timeline for your progress

Before April 20:

  • To read some documents of Linux NFS/fscache/cachefiles so that have a overview of these features.
  • To get some knowledge of cache mechanism which could refer to Linux page cache implementation.
  • To get familiar with the NFS code especially the call sequence, the interaction with sunrpc/VFS/page cache/fscache. To get familiar with fscache/cachefiles code especially the cache data structure and interaction between each other.


April 23 – May 21 (Before the official coding time, 27 days):

  • Set up git repository and prepare google doc spreadsheet to track my progress.
  • Try to modify some NFS/fscahce/cachefiles code and add some log to improve my further understanding of the code.
  • During this period I will remain in touch with my mentor and follow up the linux-nfs and fscache mailing list. I will send my mentor with my modifications so that he can help review and comment it.
  • With my mentor’s help, I will become absolutely clear about my future goals and the write-back cache implementation.


May 21 – June 16 (Official coding period starts, 26 days):

  • Define a mount option to control whether to enable write-back fscache.
  • Enable write-back cache for read-write opened file. Here should update fscache store limit before writing cache.
  • Cache pages flushed by kernel flushers into fscache except the fsync condition.
    • Design fscache_writepages interface or implement another write_cache_pages() callback, and then call it in nfs_writepages() to skip the write-back of dirty pages in page cache.
    • Design data structure in fscache to maintain dirty pages so that fscache can write back therm periodically and NFS can flush them at fsync. Maybe we can refer to the radix tree which is already used by fscache and add some tags of flags to implement this data structure.


June 16 – July 9 (24 days):

  • At file close or fsync, explicitly flush all dirty pages in fscache to meet NFS close-to-open semantic.
    • Define a new fscache interface to make NFS capable to do flush manually.
    • Here should notice the consistency with page cache.
  • Implement a background thread mechanism in fscache to write back dirty pages periodically
    • Control fscache to create a flush thread for the netfs(here is NFS) who has enabled write back fscache. Here we should modify data structure of fscache which maybe fscache_netfs.
    • Define write back operation interface for netfs to make netfs capable to write back pages with their own method.
    • Implement the /proc or /sys interface to make cache capable to adjust write-back period.


JULY 9th MID TERM EVALUATION

  • Implement the basic functions from implementation 1 to 4 above. This means we have made the write-back fscache works normally despite there maybe some bugs and code organization issues. These issues would be left to the second half part time to fix.


July 9 – July 18 (10 days):

  • Make further changes in the code to improve the Functionality such as write performance of cachefiles, Exception handling.
  • Design test case to reveal bugs and review them with my mentor.


July 18 – July 27 (10 days):

  • Keep in contact with my mentor and continue to follow up linux-nfs and fscache mailing list. Let the maintainers of nfs and fscache know our progress.
  • Most of time would be consumed to do bug fix.


July 27 – August 2 (7 days):

  • For patch generation and documentation.


Buffer two weeks to meet unpredictable delay.


AUGUST 20th FINAL EVALUATION

  • Generate good patches for our project. It's best if these patches could be accepted by Linux kernel.
  • Make out proper document for this new write-back fscache.

Have you communicated with a potential mentor? If so, who?

Yes, he is Peng Tao.

Retrieved from "https://fedoraproject.org/w/index.php?title=GSOC_2012/Student_Application_jiayi/Implement_nfs/fscache_writeback_cache&oldid=283305"