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