- 'Tis the season for debugging
- Contract weekly report #56 - Media fixes and more!
- Contract weekly report #55 - GCI and more
- Contract weekly report #54
- Contract weekly report #53
- Report from the french far-west
- Contract weekly report #52 - On to beta1!
- WebKit weekly report #51 - back to normal schedule
- Ohio LinuxFest 2014 Report
- Jessica's Google Summer of Code
BFS Partition Resizer: Final Report
First of all, I apologize for the delay. I have now returned from my vacation, had a few days to settle in and explain to my neighbours that I'm not dead (!). Anyways, on to the interesting stuff.
On the surface, the status of things is mostly the same as in my last report, with a few bugs less. I thought I had dedicated more than enough time for bugfixing, but that turned out to not be the case. This is partly due to the slower development cycle when testing natively (compile, copy driver to image, boot virtual machine, test, repeat), and the bugs only showing up after doing several resizes with other IO going on. All the bugs of this kind that I know about have been eliminated.To summarize the things I have accomplished during the summer:
- Resize support in BFS driver, save for vnode mapping and growing a full file system.
- Getting the resizing "pipeline" from userspace to driver to a working state (still needs some checking to verify that it's robust).
It turned out toward the end of summer that the way I had been handling changed vnode ID's would not work out. The vnode ID is a number that refers to a specific file, and the current BFS code simply uses the block on the disk where the file is located for this purpose. This becomes a problem when a file is moved, as is necessary when resizing. My earlier solution was to "trick" the system to use the new file location as the ID instead, but this doesn't really work out. What needs to be done is to decouple the block number and vnode ID in the BFS module, so a file can be moved without changing the ID. I have started to work a little on this, and it's looking very promising.
The ability to grow a full file system, while not of absolutely critical importance, would be very nice to have. I have written a bit about this in the previous post, so I won't repeat myself. The same goes for resize support in DriveSetup.
My plan for the future is to continue working on this, at the very least until it can be merged. Would be a shame to do all that work for nothing :). It's hard to give a timeline for this, it depends on how the school situation turns out, but I hope it will be done fairly soon.
The code can be found in my github repository, in the 'production' branch. It needs to be merged with the 'fixes' branch (this is not conflict free...), as for some reason I got started on a strange git workflow. I intended to have this sorted out by the end of the coding period, but that didn't happen.
I'd like to give a big thank you to mentors and others for making this happen, all the help and the welcoming attitude. I've learned a great deal (I hear the job market is screaming for people with detailed knowledge of the Be File System :)). Seriously though, I've gained a lot of knowledge of file systems in general, how operating systems work on a lower level, concurrent programming and so on, both from my own work and reading mailing list posts.
Have a nice day