[illumos-Developer] Replay problems with new zvol_replay_truncate (was iSCSI UNMAP...)

[Dan McDonald]

On Tue, Mar 01, 2011 at 07:41:51AM -0800, George Wilson wrote:
> Dan,
> 
> What you're seeing makes sense since the breakpoint is after the log
> record is created in-core but before the zil_commit() which will sync
> it to disk. Now set a breakpoint after zil_commit() but before the
> txg_wait_synced() and let's see what happens (make sure you're zvol
> is big enough so that there's plenty of work to do).

I don't need all that much volume, actually.

The iSCSI client + FS combo I'm using (Linux kernel iSCSI client + EXT4 with
"-o discard") sends UNMAPs in mostly 8MB chunks.  A 4MB file is
perfect for single-chunk tests, and therefore single-ZIL-entry testing.

After I rebooted post-zil_commit(), things behaved better:  I intercepted
zvol_replay_truncate() with the 4MB range, and after I let it through the 4MB
was gone from the zvol's reference amount.

Time to proceed with your other two suggested experiments (interrupting
during zvol_replay_truncate(), presumably to show that it'll be called again
on a subsequent reboot).  I'll report back with results.

Oooh, while I've gotcha here... I'm currently calling zil_commit() if the
dmu_free_long_range() call fails, but there's still an itx assigned to the
zil.  Should that be freed somehow if dmu_free_long_range() fails?  A cursory
look at zfs POSIX-like ops, suggests that either stragglers are somehow
handled elsewhere (e.g. zfs_symlink() seems to log regardless) or that
nothing gets logged at all on failure (e.g. zfs_link() only logs if
zfs_link_create() succeeds).

Again, thanks for your time & patience,
Dan