Joshua Gillett <joshuagill...@college.harvard.edu> writes: > I want to inquire about working on the "Discard for FFS" project listed on > the wiki over the next couple of months. > > I just finished a semester-length OS course (working on teaching operating > system, ChickadeeOS) where I wrote block-bitmap allocators, extent-based > truncate/extend, journalling, and a write-back cache, so the topic should > be familiar to me. > > With that said, I wanted to know if there was anyone working on this. I'd > also welcome any mentorship or advice in regards to working on this project.
I have not heard that anyone is working on this. It sounds like your coursework is good background. Generally people are happy to comment when there's something to comment on. I personally refrain from helping with GSoC, not wanting to volunteer to help google recruiting, but it sounds like you are not talking about that. >From a really high level, it would be good to articulate if this is about freeing blocks to allow storing more files, or if it's about interacting with TRIM. Personally, my first step would be a survey of other implementations. The semantics of fdiscard(2) are a bit messy, with TRIM and undefined contents. That's surprising to me, as I see telling the hardware that blocks are no longer needed seems separable from a file no longer referencing those blocks. It looks like fdiscard(2) isn't part of POSIX, which raises the question of where it came from and what the bulk of practice is. That's sort of "were it to be standardized, what would the standard say?", leaning to "what should it say really, if we didn't insist on allowing UB for a few outliers that are doing things they probably shouldn't." In looking at other implementations, there is understanding/summarizing the guarantees that other systems make at the syscall level, and there is the actual implemented behavior of foo FS under bar OS. Definitely look at zfs. I would then survey how TRIM support is or isn't implemented in NetBSD. Then, I'd write down how fdiscard on ffs is supposed to behave (as in external specification), both at the VOP layer, and if it interacts with block devices specially. Next, read and understand the code, which is a pretty big job. I'd document invariants and improve comments, assuming that this hasn't been done already. BSD has a history of code having critical invariants that aren't really written down; I don't know about the current state of ffs. You'll also have to understand wapbl. My impression is that most people use wapbl, and thus discard on ffs w/o wapbl isn't so interesting. Then, a written design of how the code is going to change, both in the base case and wapbl case. This is probably "change the list of blocks to have holes" but it's all about ordering of writes and invariants. Finally, tests and code/doc changes. I would suggest writing things up and posting them somewhere for review by others.
