Date: Wed, 9 Sep 2015 10:20:31 +0100 From: Steven Hartland <killing@multiplay.co.uk> To: freebsd-fs@freebsd.org Subject: Re: TRIM support (same bug as linux?) Message-ID: <55EFF9DF.2020201@multiplay.co.uk> In-Reply-To: <55EFF739.5020608@digiware.nl> References: <CAD=tpedAx2XLtQe6Nn%2BHvXWZ0X=TekmkpTruxCndYqpBXPFaFA@mail.gmail.com> <55EF7265.2050309@multiplay.co.uk> <1BCC8B97-6C79-4864-8405-BA687577808A@longcount.org> <CAGtEZUBgbufc2W%2BiFg_7XVWyF4_mcfd8mj1=UMyTHM-RCWWR_g@mail.gmail.com> <20150908214221.7a1702e0@kan> <55EFF739.5020608@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@longcount.org> >>> wrote: >>> >>>> >>>> >>>>> On Sep 8, 2015, at 7:42 PM, Steven Hartland >>>>> <killing@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@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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55EFF9DF.2020201>