Date: Mon, 11 Jul 2011 12:25:41 +0100 From: Luke Marsden <luke-lists@hybrid-logic.co.uk> To: freebsd-fs@freebsd.org Cc: tech@hybrid-logic.co.uk Subject: ZFS bug in v28 - temporary clones are not automatically destroyed on error Message-ID: <1310383541.30844.73.camel@behemoth>
next in thread | raw e-mail | index | archive | help
Hi all, I'm experiencing this bug on mm's ZFS v28 image from 19.06.2011 r222557M: cannot destroy 'hpool/hcfs/fs@snapshot': dataset already exists That is on a v4 formatted zfs filesystem on a v28 formatted pool, if I zfs upgrade the filesystem to v5 the error changes to "snapshot has dependent clones" (from memory) which is more informative but otherwise behaves the same. See: http://serverfault.com/questions/66414 http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0 FreeBSD dev1.demo 8.2-RELEASE-p2 FreeBSD 8.2-RELEASE-p2 #3 r222557M: Thu Jun 16 23:58:02 CEST 2011 root@neo.vx.sk:/usr/obj/releng_8_2/sys/GENERIC amd64 I found this email relating to a fix pushed to OpenSolaris in 2009. http://mail.opensolaris.org/pipermail/onnv-notify/2009-August/010064.html Did this fix ever get merged into the FreeBSD source tree, or is this a more recent regression unrelated to the fix from 2009? Unfortunately the OpenSolaris bug database seems to have disappeared so I can't find the actual patch. The workaround - zdb -d poolname |grep % - followed by manually zfs destroying the offending stray clones, works apart from that zdb on a busy pool (one with active zfs replication happening on it) gives EIO about 90% of the time, and that is the case in our application, which makes the workaround time consuming and temporary. We are resorting to attempting to predict and destroy all the possible stray clone names whenever a zfs replication event completes (either a failure or a success) to stop later destroys of snapshots failing with "cannot destroy [snapshot]: dataset already exists". In our application we do occasionally abort replication events if they appear to not be making any progress by sending SIGTERM to the corresponding zfs send/recv processes. FWIW, we didn't see this in v14 or v15 (8.1 or 8.2 respectively). Does anyone know better how to predict what the clone names will be, so that I can refine our workaround until we have a patch for 8-STABLE? Currently we are predicting that all the snapshot names included in an incremental receive are potential "stray clones", but this does not seem to catch all of them. Also, the clones corresponding to a snapshot do not have the same name as the snapshot, it seems that perhaps it is the "parent" snapshot (i.e. the previous snapshot on which the next snapshot is based upon) that becomes the name of the stray clone. This is fine but we lose this information by "pruning" intermediate snapshots. Is there any way to interrogate ZFS for the names of any such clones prior to attempting the destroy of the snapshot so that we can automatically clean them up more efficiently? Thank you all for your excellent work :-) -- Best Regards, Luke Marsden CTO, Hybrid Logic Ltd. Mobile: +447791750420 www.hybrid-cluster.com - Cloud web hosting platform
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1310383541.30844.73.camel>