SquashFS port final report
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 25 Aug 2023 16:37:02 UTC
Hello! The last 3 weeks have been amazing for our SquashFS port. We completed directories, files, and symlinks support. I completed xattrs support too but implementing vnops() hooks for them is remaining as I was spending this last week on testing our driver. A more detailed report for each feature: * Directories - SquashFS directories are simple, we have a header for the current directory which keeps the count of the number of entries and offset of block in the Directory table. Since I was done implementing their traversing functions most of the work remaining was of implementing VOP_LOOKUP() and VOP_READDIR() hooks. I spent some time understanding those hooks and implemented them completing directories read support. * Files - Now this was a little special, SquashFS files are in fragments which in turn are in the Fragment table. Since there wasn't much documentation available I tried to make sense of SquashFuse source code to understand files. Once I got its design I began porting them. However, I got stuck while testing due to constant page faults that occurred while reading files. After a lot of debugging, I realized that we cannot use uio vectors directly for reading and should use uio helper functions like uiomove(), uiomove_frombuf(), etc... to handle those operations. Once I used them the issue was resolved. * Symlinks - This was simple, the symlink target was specified in inode metadata and all we needed to do was read it. I quickly implemented the VOP_READLINK() hook and symlinks support was done as well. * Extended Attributes - I spent some time understanding SquashFuse's implementation of them, and after that I ported all necessary functions for operations like getting extended attributes, getting their value, etc... The work for implementing VOP_() hooks for them remains since I spent this last week testing more of our driver. I am glad I did a lot of testing where I encountered two issues: 1. We can't list the first entry of the root inode. 2. The inode data leaks memory, I don't know how to free that data once we are not using that inode. I think the second issue could be resolved soon once I see which function gets called for freeing inode data. This is it for this final report. Thanks a lot for reading it this far. --Raghav