Re: Working on Discard for FFS

[Greg Troxel <gdt%lexort.com@localhost>]

Joshua Gillett <joshuagillett%college.harvard.edu@localhost> 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.