[illumos-Developer] MUCH better --> zil for zvol TRUNCATE (and iSCSI UNMAP) working...
garrett at nexenta.com
Tue Mar 1 10:00:43 PST 2011
I'm not sure your code unmap review is up to date:
sbd.c: line 3845 & 3846... a residual #if 0 and the KEBE ASKS comment.
sbd.c: line 3757 -- I thought you were issuing these against /dev/zvol?
Can you please check to make sure your webrev is updated?
On Tue, 2011-03-01 at 12:31 -0500, Dan McDonald wrote:
> 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:
> 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.
> Developer mailing list
> Developer at lists.illumos.org
More information about the Developer