Type: New Feature
Affects Version/s: None
Fix Version/s: None
Original PCC is able to accelerate data read/write, but not able to cache and accelerate metadata operations. In order to improve that, we are going to implement a new mode of PCC which can cache both data and metadata access/modification. Let's call it "directory mode".
Following is the design:
- An image will used to store all metadata and data of a virtual directory tree. Possible options could be tarball/ext4 file system image/qemu image, but tarball might be the simple choice to start with.
- The image will be saved in Lustre as a normal file.
- When the image is being fetched into PCC in directory mode, the image, instead of being copied into PCC, will be untar-ed into a subtree on PCC.
- A virtual directory inode will be created for the PCC attached image file. The directory name will have a special subfix, e.g. if the image file has a file name of "image", the virtual directory could have a name of "image.pcc_virtdir".
- The virtual directory is only a virtual inode on Lustre client side, no inode will be created on MDT.
- The image file on Lustre can not be modified any more on that Lustre client, since there is a cache of the image in PCC. Nobody is able to write/read directly from the image file, instead, they need to write/read from the virtual directory.
- The virtual directory points to PCC directory of the image.
- All access/modification under that virtual directory will be directed to PCC. All metadata or data operations will not go to Lustre servers.
- For RW-PCC. whenever another client tries to modify the image file, or try to detach the image file from PCC, the restore action will be trigerred.
- During restore action, a special kinds of copytool will be used. Instead of copying data between files, the copytool will tar the PCC directory of the image file and save the data into Lustre.
Everything else should be very straightfoward, except of implementing a virtual directory. And what would be even better is, we do not create new virtual inode on Lustre client, instead, we change the type of the image file of the image into directory. This has some advanges:
1) This prevents potential conflict beteen existing file that happens to have a subffix of ".pcc_virtdir", which is not likely to happen, but still possible.
2) This simplify the interface and enables transparent virtual directory. If all clients have PCC and accessing it always triggers the prefetch of the image into PCC, users/applications do not need to be aware that this image is a regular file. The image will look like directory all the time for all applications/users.
But of course, this increases implementation complexity and has higher possibility of causing other problems. So, we need to balance the pros and cons here.