int ret; rather than uint*_t ret;
Thu, Dec 13
Wed, Dec 12
looking better. Next round of suggestions shouldn't be so bad.
Tue, Dec 11
Netflix doesn't use efi_system_reset() in our version of FreeBSD. Changing the signature is likely fine.
OK. That's all I have time for tonight. Should be enough to keep you going. Gotta go get some sleep.
Mon, Dec 10
This changes does what it says, but no clue why we need it.
Sun, Dec 9
Sat, Dec 8
Fri, Dec 7
Thu, Dec 6
LGTM. I still find the 'mirror' name confusing, but maybe that's a personal problem ;-).
updates per cem@
Wed, Dec 5
Tue, Dec 4
Update the pacing base that Kirk sent me to cope better with multiple workers.
Mon, Dec 3
I looked at this on my phone a few days ago and meant to stamp it with LGTM when I got back to my computer, but that fell through the cracks.
The code seems fine, other than the weird msi_tupelo which randomly seems to be the same as msi_enabled, but only some of the time. A comment is needed to explain why the oddity.
Sun, Dec 2
I'll do the ones I marked and call it good and do round 2 for the const changes and the dlopen feature.
I've updated to be close to the end game. All that remains is readdir(/libexec/nvmecontrol and /usr/local/libexec/nvmecontrol) for all the .so's at startup and we'll be to the point where Netflix can deploy the Sekret Soss modules we have from Vendor X w/o changing base or polluting base with NDA material.
Lots of cleanup, will be separate commits
Thanks for the feedback. I'll see how much I can include in my next round as some of them are asking for more structural changes beyond the scope of this set of changes (the suggestions are good, btw, just am keen to avoid too much scope creep).
Sat, Dec 1
There's a suggestion that the new trim program be named 'discard' to match linux's discard option on mount. Perhaps discard would be a better name. Though I hesitate to make such a bike-sheddy suggestion.
I'm pissed this was committed. It wasn't ready and in total breach of protocol.
This matter is *NOT* settled and you're lucky I don't just remove it from the tree.
Fri, Nov 30
Couple of minor nits, but otherwise looks OK.
My acceptance is provisional here.
This now looks reasonable to me.
At the moment during block shortages we request speedup of retiring TRIMs. But if there are no TRIMs (or we are on a disk that does not support TRIMs) then it seems to me that we should fall back to doing write speedup. Is this a change that we should make at the filesystem level, or should the drive recognize that if it is asked to speedup TRIMs and there are no TRIMs to speed up, then it should fall back to speeding up writes?
Thu, Nov 29
I like this, independent of a standalone utility.
Wed, Nov 28
a quick scan doesn't reveal anything major.
First pass at turning off write limiting when in speedup mode.
OK. I've updated this in a few ways:
Update based on Kirk's comments and some thinking about the problem.
Fold Kirk's suggestions in, but only his diff, not the one to remove one of my calls.
Kirk sent me this (patch has been removed, but integrated into next update, but I've not yet internalized it enough to comment tonight):
Tue, Nov 27
I never saw a situation where SU workitems were the cause of the memory shortage. I understand that slow trims can cause filesystem write hiccups and that the change would somewhat lessen this.
Since, as noted above, the SU workitems shortage does not cause system instability, only performance problems, I would prefer that the abort of requested trims was controlled by an option, perhaps even per-mount. For instance, on my w/s I never have low memory condition but often do large metadata-intensive ops and I do not want to loose the useful hints which manage the SSDs lifespan.
Again with the changes, this time including all the changes.