Temporary clones not destroyed on incremental snapshot receive

[Jason Hellenthal]

On Tue, Jul 12, 2011 at 03:23:36PM +0200, Martin Matuska wrote:
> In kern/157728, I describe a problem (with reproduction steps and a
> temporary workaround) of temporary clones not destroyed on incremental
> snapshot receive.
> This does apparently not happen on OpenIndiana or Solaris.
> 
> Does anyone have a clue what could cause this bug in our ZFS port?
> 
> URL:http://www.freebsd.org/cgi/query-pr.cgi?pr=157728
> 

This bug may be related to a very similiar one that was reported to me
last night.

The user was attempting to rename a populated dataset with less than ~50
snapshots (maybe far less) did not get an exact number but his steps to
reproduce this is listed below for reference.

zfs umount pool/(...)/dataset	# This fails, dataset somehow in use.
zfs umount -f pool/(...)/dataset	# This works, problem waiting here.
zfs rename pool/(...)/dataset pool/(...)/dataset2	# Live-Lock

There was no coredump at this point that could be obtained and the
backtrace information he had was shaky at best. So ...

I had him remove all the snapshots before dataset renaming...
zfs destroy pool/(...)/dataset@(...)
zfs umount pool/(...)/dataset		# Not clear if this worked
zfs umount -f pool/(...)/dataset	# Could have worked.
zfs rename pool/(...)/dataset pool/(...)/dataset2	# Worked.

He probably could have gone without the (umount) here but I suspect
thats why he was using it because the rename probably failed with EBUSY
or some error.

The backtrace he gave here: (pasted in IRC) translation needed.
25674 100871 zfs initial thread mi_switch+0x176 sleepq_wait+0x42
_cv_wait+0x129 txg_wait_synced+0x85 dsl_sync_task_group_wait+0x128
dsl_sync_task_do+0x5 4 dsl_dir_rename+0x8f dsl_dataset_rename+0x272
zfsdev_ioctl+0xe6 devfs_ioctl_f+0x7b kern_ioctl+0x102 ioctl+0xfd
syscallenter+0x1e5 syscall+0x4b Xfast_syscall+0xe2

By the way he explained it, this felt like a locking problem or
something not being free'd from something similiar to what we
experienced before from the .zfs/* directories causing panics.


Martin,

He also explained that he was using a version of mfsBSD image to create
this system too that he continued to run if its of any help. IIRC this
is the same thing that was MFC'd to stable/8.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 522 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/zfs-devel/attachments/20110714/9b96536a/attachment.pgp