Bug #7570
tunable to allow zvol SCSI unmap to return on commit of txn to ZIL
100%
Description
Based on the discovery that every unmap waits for the commit of the txn to the ZIL, introducing a very high latency to unmap commands, this behavior was made into a tunable zvol_unmap_sync_enabled and set to false. The net impact of this change is that by default SCSI unmap commands will result in space being freed within the zvol (today they are ignored and returned with good status). However, unlike the code today, instead of 18+ms per unmap, they take about 30us.
With the testing done on NTFS against a Win2k12 target, the new behavior should work seamlessly. Files on the zvol that have already been set with the zfree application will continue to write 0's when deleted, and any new files created since zvol creation will send unmap commands when deleted. This behavior exists today, but with this change the unmap commands will be processed and result in reclaim of space.
History
Updated by Electric Monk about 3 years ago
Updated by - % Done changed from 0 to 100
- Status changed from New to Closed
git commit 1c9272b861cd640a8342f4407da026ed98615517
commit 1c9272b861cd640a8342f4407da026ed98615517
Author: Stephen Blinick <stephen.blinick@delphix.com>
Date: 2016-11-19T04:49:33.000Z
7570 tunable to allow zvol SCSI unmap to return on commit of txn to ZIL
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Matt Ahrens <mahrens@delphix.com>
Reviewed by: Steve Gonczi <steve.gonczi@delphix.com>
Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed by: Saso Kiselkov <saso.kiselkov@nexenta.com>
Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
Approved by: Robert Mustacchi <rm@joyent.com>