Date: Wed, 9 Sep 2015 11:09:13 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: Alexander Kabaev <kabaev@gmail.com>, Tom Curry <thomasrcurry@gmail.com> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: TRIM support (same bug as linux?) Message-ID: <55EFF739.5020608@digiware.nl> In-Reply-To: <20150908214221.7a1702e0@kan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55EFF739.5020608>