TRIM support (same bug as linux?)

[Willem Jan Withagen]

On 9-9-2015 03:42, Alexander Kabaev wrote:
> On Tue, 8 Sep 2015 21:28:01 -0400
> Tom Curry <thomasrcurry at gmail.com> wrote:
>
>> I'm no expert but if memory serves the issue had to do with concurrent
>> and/or queued trim which is not implemented in FreeBSD.
>>
>> On Tue, Sep 8, 2015 at 9:11 PM, Mark Saad <nonesuch at longcount.org>
>> wrote:
>>
>>>
>>>
>>>> On Sep 8, 2015, at 7:42 PM, Steven Hartland
>>>> <killing at multiplay.co.uk>
>>> wrote:
>>>>
>>>> Nope FreeBSD is not affected by this.
>>>>
>>>>> On 09/09/2015 00:15, FF wrote:
>>>>> I'm asking a pretty vague question and I apologize in advance,
>>>>> not
>>> trying
>>>>> to troll.
>>>>>
>>>>> The question has to do with whether FreeBSD is using TRIM the
>>>>> same way
>>> as
>>>>> recent Linux kernels.
>>>>>
>>>>> https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/
>>> seems
>>>>> to imply that there are instabilities that can occur. Trying to
>>>>> avoid duplicating effort if this has already been addressed or
>>>>> if its a
>>> complete
>>>>> dead alley because there isn't a commonality.
>>>>>
>>>>> Thanks in advance!
>>>>
>>>
>>> It would be interesting if anyone could explain the reasons why
>>> ufs/ffs and zfs  and FreeBSD are not effected by this issue .  My
>>> rudimentary understanding of the issue was that it's wasn't just a
>>> software glitch in the ext filesystem and bad firmware but a
>>> combination of that and Linux poorly supporting a ata modes that
>>> are not supported at all on FreeBSD . Is that correct ?
>>>
>>>
>>> ---
>>> Mark Saad | nonesuch at longcount.org
>
> 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