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 _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
