TRIM support (same bug as linux?)

[Kirk McKusick]

> To: Alexander Kabaev <kabaev at gmail.com>, Tom Curry <thomasrcurry at gmail.com>
> From: Willem Jan Withagen <wjw at digiware.nl>
> Subject: Re: TRIM support (same bug as linux?)
> Date: Wed, 9 Sep 2015 11:09:13 +0200
> 
> On 9-9-2015 03:42, Alexander Kabaev wrote:
>> Wasn't the root cause the improper bio splitting code in md/raid0 code
>> and nothing special in firmware? FreeBSD shares no such code and as
>> such is not affected.
> 
> More or less,
> 
> What happened as a consequence of the split in the code is that there 
> was a possibility that 2 threads would run parallel:
>    one executing a trim
>    and a second one that already executed under the assumption that the
>    trim was completed.
> 
> And what I believe to be the case is that due to not correct ordering 
> the second thread sometimes could write in space that was going to be 
> trimmed. And thus that data would be lost, causing corruption.
> 
> Perhaps this typical code is not present in FreeBSD. But it is just
> a matter of code enginering/refactoring/.... in complex code to
> make these kind of mistakes happen.  Being careful, use may eyes
> on critial code, tools are all ways to prevent this. But then still:
> code is written by humans.
> 
> --WjW

I cannot speak to ZFS in FreeBSD, but the TRIM support if UFS/FFS
implements TRIM as follows:

	filesystem frees block
	TRIM command is dispatched to disk via GEOM
	callback from GEOM that disk has reported TRIM command complete
	block is released to filesystem freelist

The block cannot be reallocated until it has been placed on the freelist.
So, unless the disk reports that it has acted on the TRIM before it has
actually done so, it should not be possible to allocate prematurely.

	Kirk McKusick