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

[George Wilson]

On 3/1/11 8:26 AM, Dan McDonald wrote:
> 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

No need to worry about these as they should get cleaned up automatically.

- George

> zfs_link_create() succeeds).
>
> Again, thanks for your time&  patience,
> Dan
>
> _______________________________________________
> Developer mailing list
> Developer at lists.illumos.org
> http://lists.illumos.org/m/listinfo/developer