TRIM support (same bug as linux?)

[Steven Hartland]

That was the original theory wasn't that in the end

On 09/09/2015 10:09, Willem Jan Withagen wrote:
> 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
>
>
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"