[illumos-Developer] MUCH better --> zil for zvol TRUNCATE (and iSCSI UNMAP) working...

Dan McDonald danmcd at nexenta.com
Tue Mar 1 09:31:30 PST 2011


George gave me a few things to try (which I've numbered and quoted):

> 1.) So I would recommend setting a breakpoint after zvol_log_truncate() and
>     forcing a panic.  Then make sure that we process this ioctl again on
>     bootup.

We talked about this already, and forcing the reboot after zil_commit()
causes the right thing to happen.

> 2.) Also do the same thing after dmu_free_long_range().

See above.

> 3.) But you'll want to add another reboot point in zvol_replay_truncate()
>     prior to calling dmu_free_long_range() and also after it. What we need
>     to see is that zvol_replay_truncate() is called after these reboot
>     points. If they are then we're still replaying the same log block on
>     disk and we can leave the code the same. Make sense?

Every time I rebooted in the *middle* of zvol_replay_truncate(), the
rebooting system (once COMSTAR starts and attmempts to open the zvol) would
drop into zvol_replay_truncate() again, no matter where I rebooted within the
function (including JUST before an otherwise successful return).

I think we're doing the right thing w.r.t. the zvol.  As I mentioned before,
my client UNMAPs in chunks of 8MB where possible, so for sufficiently large
files (like my original 128MB test tarball) I've only be able to catch the
first 8MB chunk.

So with that, I submit that this webrev:

	http://www.kebe.com/~danmcd/webrevs/unmap/

might be fit for consumption by Illumos.  I still defer to reviewers with
more ZFS clue than me, but this has been a good learning experience.

Thanks!
Dan



More information about the Developer mailing list