A little work with dtrace, please be kind, this is my first post and first
dtrace work
PRESENTATION
root at fsbu ~# uname -a
SunOS fsbu 5.10 Generic_142901-06 i86pc i386 i86pc
root at fsbu ~# zfs list -r fsbu01-zp/mailboxes
NAME USED AVAIL REFER
MOUNTPOINT
fsbu01-zp/mailboxes 30.6G 6.02T 30.6G
/fsbu01-zp/mailboxes
fsbu01-zp/mailboxes at zfs-auto-snap:daily-2010-04-14-00:00:00 0 -
30.6G -
root at fsbu ~# zfs destroy fsbu01-zp/mailboxes at
zfs-auto-snap:daily-2010-04-14-00:00:00
cannot destroy ''fsbu01-zp/mailboxes at
zfs-auto-snap:daily-2010-04-14-00:00:00'': dataset already exists
DTRACE SCRIPT
root at fsbu ~# cat zfs-2.d
#pragma D option flowindent
fbt:zfs:$1:entry
{
self->follow=1;
}
fbt:zfs:$1:return
/self->follow/
{
trace(arg1);
self->follow=0;
exit(0);
}
fbt:::entry
/self->follow/
{ }
fbt:::return
/self->follow/
{
trace(arg1);
}
WORKING:
root at fsbu ~# dtrace -s ./zfs-2.d dsl_sync_task_group_wait
dtrace: script ''./zfs-2.d'' matched 68892 probes
CPU FUNCTION
0 -> dsl_sync_task_group_wait
0 -> dmu_tx_create_dd
0 -> kmem_zalloc
0 -> kmem_cache_alloc
0 <- kmem_cache_alloc -1617915766592
0 <- kmem_zalloc -1617915766592
0 <- dmu_tx_create_dd -1617915766592
0 -> dmu_tx_assign
0 -> dmu_tx_try_assign
0 -> txg_hold_open
0 <- txg_hold_open 420219
0 <- dmu_tx_try_assign 0
0 -> txg_rele_to_quiesce
0 <- txg_rele_to_quiesce 0
0 <- dmu_tx_assign 0
0 -> dmu_tx_commit
0 -> txg_rele_to_sync
0 -> cv_broadcast
0 <- cv_broadcast 0
0 <- txg_rele_to_sync 0
0 -> kmem_free
0 -> kmem_cache_free
0 <- kmem_cache_free 6
<---------- #define ENXIO 6 /* No such device or address */
0 <- kmem_free 6
0 <- dmu_tx_commit 6
0 <- dsl_sync_task_group_wait 17
<---------- #define EEXIST 17 /* File exists */
Looks like the problem is on the address given to kmem_cache_free
GOOD example
In the case of a working destroy the script execution is way longer:
root at fsbu ~# dtrace -s ./zfs-2.d dsl_sync_task_group_wait
dtrace: script ''./zfs-2.d'' matched 67886 probes
CPU FUNCTION
1 -> dsl_sync_task_group_wait
1 -> dmu_tx_create_dd
1 -> kmem_zalloc
1 -> kmem_cache_alloc
1 <- kmem_cache_alloc -1618874920704
1 <- kmem_zalloc -1618874920704
1 <- dmu_tx_create_dd -1618874920704
1 -> dmu_tx_assign
1 -> dmu_tx_try_assign
1 -> txg_hold_open
1 <- txg_hold_open 420229
1 <- dmu_tx_try_assign 0
1 -> txg_rele_to_quiesce
1 <- txg_rele_to_quiesce 0
1 <- dmu_tx_assign 0
1 -> txg_list_add
1 <- txg_list_add 0
1 -> dmu_tx_commit
1 -> txg_rele_to_sync
1 -> cv_broadcast
1 <- cv_broadcast 0
1 <- txg_rele_to_sync 0
1 -> kmem_free
1 -> kmem_cache_free
1 <- kmem_cache_free 0
1 <- kmem_free 0
1 <- dmu_tx_commit 0
1 -> txg_wait_synced
1 -> cv_broadcast
1 <- cv_broadcast 0
......
root at fsbu ~# dtrace -s ./zfs-2.d dsl_sync_task_group_wait
dtrace: script ''./zfs-2.d'' matched 67886 probes
CPU FUNCTION
1 -> dsl_sync_task_group_wait
1 -> dmu_tx_create_dd
1 -> kmem_zalloc
1 -> kmem_cache_alloc
1 <- kmem_cache_alloc -1618874920704
1 <- kmem_zalloc -1618874920704
1 <- dmu_tx_create_dd -1618874920704
1 -> dmu_tx_assign
1 -> dmu_tx_try_assign
1 -> txg_hold_open
1 <- txg_hold_open 420229
1 <- dmu_tx_try_assign 0
1 -> txg_rele_to_quiesce
1 <- txg_rele_to_quiesce 0
1 <- dmu_tx_assign 0
1 -> txg_list_add
1 <- txg_list_add 0
1 -> dmu_tx_commit
1 -> txg_rele_to_sync
1 -> cv_broadcast
1 <- cv_broadcast 0
1 <- txg_rele_to_sync 0
1 -> kmem_free
1 -> kmem_cache_free
1 <- kmem_cache_free 0
1 <- kmem_free 0
1 <- dmu_tx_commit 0
1 -> txg_wait_synced
1 -> cv_broadcast
1 <- cv_broadcast 0
Hope this help
Frank Contrepois
Coblan srl
__________ Informazioni da ESET NOD32 Antivirus, versione del database delle
firme digitali 5044 (20100420) __________
Il messaggio ? stato controllato da ESET NOD32 Antivirus.
www.nod32.it
> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss- > bounces at opensolaris.org] On Behalf Of Frank Contrepois > > root at fsbu ~# zfs destroy fsbu01-zp/mailboxes at zfs-auto-snap:daily-2010- > 04-14-00:00:00 > cannot destroy ''fsbu01-zp/mailboxes at zfs-auto-snap:daily-2010-04-14- > 00:00:00'': dataset already existsThis issue has now been answered, courtesy of Cindy Swearingen (cindys) here: http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0 Summary: If you do incremental receives, this might be CR 6860996: A temporary clone is created for an incremental receive and in some cases, is not removed automatically. 1. Determine clone names: # zdb -d <poolname> | grep % 2. Destroy identified clones: # zfs destroy <clone-with-%-in-the-name> It will complain that ''dataset does not exist'', but you can check again(see 1) 3. Destroy snapshot(s) that could not be destroyed previously