[zfs-discuss] Important: 0.6.5 zvol data loss regression on unaligned discard operations
ryao at gentoo.org
Fri Sep 18 18:35:58 EDT 2015
On Fri, Sep 18, 2015 at 10:34:31PM +0000, Richard Yao via zfs-discuss wrote:
> On Fri, Sep 18, 2015 at 09:17:54PM +0000, Grant Albitz wrote:
> > Does anyone know if this would impact a zvol that is being presented via scst_vdisk (fileio not blockio) to an esxi 6 cluster as a datastore (which inturn runs windows virtual machines)? I have patched this, but I had about 15 vms running for most of the day unpatched. I havent noticed anything yet though.
> If my cursory read of the code is correct, this configuration should be immune:
> Hole punching via fallocate() is needed to translate SCSI UNMAP into hole
> punching on files. def_blk_fops does not implement ->fallocate (although it
> could) while scst disables hole punching on files when ->fallocate is not
> implemented (because under ordinary circumstances, there is no way to deal with
> that). It could detect that the device is really a block device and do discard
> commands, but it does do that.
To be clear, I meant to say that it does not do that.
> That being said, doing discard on zvols in this configuration would
> simultaneously require ESXi to emulate a controller that supports UNMAP/TRIM,
> successfully pass that to stgt, run stgt on Linux 2.6.38 or later and use
> This bug is also accompanied by RMW overhead when it strikes, although the
> reverse is not true when the alignment is only problematic at the end of the
> discard IO (i.e. that case is fine). Consequently, anyone who has not noticed a
> severe performance drop under a moderate workload has a good chance of being
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
More information about the zfs-discuss