Date: Wed, 10 Apr 2019 16:45:39 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Karl Denninger <karl@denninger.net>, freebsd-stable@freebsd.org Subject: Re: Concern: ZFS Mirror issues (12.STABLE and firmware 19 .v. 20) Message-ID: <3d2ad225-b223-e9db-cce8-8250571b92c9@FreeBSD.org> In-Reply-To: <1866e238-e2a1-ef4e-bee5-5a2f14e35b22@denninger.net> References: <f87f32f2-b8c5-75d3-4105-856d9f4752ef@denninger.net> <c96e31ad-6731-332e-5d2d-7be4889716e1@FreeBSD.org> <9a96b1b5-9337-fcae-1a2a-69d7bb24a5b3@denninger.net> <CACpH0MdLNQ_dqH%2Bto=amJbUuWprx3LYrOLO0rQi7eKw-ZcqWJw@mail.gmail.com> <1866e238-e2a1-ef4e-bee5-5a2f14e35b22@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/04/2019 04:09, Karl Denninger wrote: > Specifically, I *explicitly* OFFLINE the disk in question, which is a > controlled operation and *should* result in a cache flush out of the ZFS > code into the drive before it is OFFLINE'd. > > This should result in the "last written" TXG that the remaining online > members have, and the one in the offline member, being consistent. > > Then I "camcontrol standby" the involved drive, which forces a writeback > cache flush and a spindown; in other words, re-ordered or not, the > on-platter data *should* be consistent with what the system thinks > happened before I yank the physical device. This may not be enough for a specific [RAID] controller and a specific configuration. It should be enough for a dumb HBA. But, for example, mrsas(9) can simply ignore the synchronize cache command (meaning neither the on-board cache is flushed nor the command is propagated to a disk). So, if you use some advanced controller it would make sense to use its own management tool to offline a disk before pulling it. I do not preclude a possibility of an issue in ZFS. But it's not the only possibility either. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3d2ad225-b223-e9db-cce8-8250571b92c9>