I am seeing a zfs recv bug on FreeBSD and am wondering if someone could test this in the Solaris code. If it fails there then I guess a bug report into Solaris is needed. This is a perverse case of filesystem renaming between snapshots. kraken:/root# cat zt zpool create rec1 da3 zpool create rec2 da4 zfs create rec1/a zfs create rec1/a/b zfs snapshot -r rec1 at s1 zfs send -R rec1 at s1 | zfs recv -dvuF rec2 zfs rename rec1/a/b rec1/c zfs destroy -r rec1/a zfs create rec1/a zfs rename rec1/c rec1/a/b # if the rename target is anything other than rec1/a/b the "zfs recv" result is right zfs snapshot -r rec1 at s2 zfs send -R -I @s1 rec1 at s2 | zfs recv -dvuF rec2 kraken:/root# sh -x zt + zpool create rec1 da3 + zpool create rec2 da4 + zfs create rec1/a + zfs create rec1/a/b + zfs snapshot -r rec1 at s1 + zfs send -R rec1 at s1 + zfs recv -dvuF rec2 receiving full stream of rec1 at s1 into rec2 at s1 received 47.4KB stream in 2 seconds (23.7KB/sec) receiving full stream of rec1/a at s1 into rec2/a at s1 received 47.9KB stream in 1 seconds (47.9KB/sec) receiving full stream of rec1/a/b at s1 into rec2/a/b at s1 received 46.3KB stream in 1 seconds (46.3KB/sec) + zfs rename rec1/a/b rec1/c + zfs destroy -r rec1/a + zfs create rec1/a + zfs rename rec1/c rec1/a/b + zfs snapshot -r rec1 at s2 + zfs send -R -I @s1 rec1 at s2 + zfs recv -dvuF rec2 attempting destroy rec2/a at s1 success attempting destroy rec2/a failed - trying rename rec2/a to rec2/recv-2176-1 local fs rec2/a/b new parent not found cannot open ''rec2/a/b'': dataset does not exist another pass: attempting destroy rec2/recv-2176-1 failed (0) receiving incremental stream of rec1 at s2 into rec2 at s2 received 10.8KB stream in 2 seconds (5.41KB/sec) receiving full stream of rec1/a at s2 into rec2/a at s2 received 47.9KB stream in 1 seconds (47.9KB/sec) receiving incremental stream of rec1/a/b at s2 into rec2/recv-2176-1/b at s2 received 312B stream in 2 seconds (156B/sec) local fs rec2/a does not have fromsnap (s1 in stream); must have been deleted locally; ignoring attempting destroy rec2/recv-2176-1 failed (0) kraken:/root# zfs list | grep rec1 rec1 238K 1.78T 32K /rec1 rec1/a 63K 1.78T 32K /rec1/a rec1/a/b 31K 1.78T 31K /rec1/a/b kraken:/root# zfs list | grep rec2 rec2 293K 1.78T 32K /rec2 rec2/a 32K 1.78T 32K /rec2/a rec2/recv-2176-1 64K 1.78T 32K /rec2/recv-2176-1 rec2/recv-2176-1/b 32K 1.78T 31K /rec2/recv-2176-1/b kraken:/root# -- This message posted from opensolaris.org
I verified that this bug exists in OpenSolaris as well. The problem is that
we can''t destroy the old filesystem "a" (which has been
renamed to
"rec2/recv-2176-1"
in this case). We can''t destroy it because it has a child,
"b". We need to
rename "b" to be under the new "a". However, we are not
renaming it, which
is the root cause of the problem.
This code in recv_incremental_replication() should detect that we should
rename "b":
if ((stream_parent_fromsnap_guid != 0 &&
parent_fromsnap_guid != 0 &&
stream_parent_fromsnap_guid != parent_fromsnap_guid) ||
...
But this will not trigger because we have already destroyed the snapshots of
b''s parent (the old "a", now "rec2/recv-2176-1"),
so parent_fromsnap_guid
will be 0. I believe that the fix for bug 6921421 introduced this code in
build 135, it used to read:
if ((stream_parent_fromsnap_guid != 0 &&
stream_parent_fromsnap_guid != parent_fromsnap_guid) ||
...
So we will have to investigate and see why the "&&
parent_fromsnap_guid !0" is now needed.
--matt
On Tue, Nov 23, 2010 at 6:16 AM, James Van Artsdalen <
james-opensolaris at jrv.org> wrote:
> I am seeing a zfs recv bug on FreeBSD and am wondering if someone could
> test this in the Solaris code. If it fails there then I guess a bug report
> into Solaris is needed.
>
> This is a perverse case of filesystem renaming between snapshots.
>
> kraken:/root# cat zt
>
> zpool create rec1 da3
> zpool create rec2 da4
>
> zfs create rec1/a
> zfs create rec1/a/b
>
> zfs snapshot -r rec1 at s1
> zfs send -R rec1 at s1 | zfs recv -dvuF rec2
>
> zfs rename rec1/a/b rec1/c
> zfs destroy -r rec1/a
> zfs create rec1/a
> zfs rename rec1/c rec1/a/b # if the rename target is anything other than
> rec1/a/b the "zfs recv" result is right
>
> zfs snapshot -r rec1 at s2
> zfs send -R -I @s1 rec1 at s2 | zfs recv -dvuF rec2
> kraken:/root# sh -x zt
> + zpool create rec1 da3
> + zpool create rec2 da4
> + zfs create rec1/a
> + zfs create rec1/a/b
> + zfs snapshot -r rec1 at s1
> + zfs send -R rec1 at s1
> + zfs recv -dvuF rec2
> receiving full stream of rec1 at s1 into rec2 at s1
> received 47.4KB stream in 2 seconds (23.7KB/sec)
> receiving full stream of rec1/a at s1 into rec2/a at s1
> received 47.9KB stream in 1 seconds (47.9KB/sec)
> receiving full stream of rec1/a/b at s1 into rec2/a/b at s1
> received 46.3KB stream in 1 seconds (46.3KB/sec)
> + zfs rename rec1/a/b rec1/c
> + zfs destroy -r rec1/a
> + zfs create rec1/a
> + zfs rename rec1/c rec1/a/b
> + zfs snapshot -r rec1 at s2
> + zfs send -R -I @s1 rec1 at s2
> + zfs recv -dvuF rec2
> attempting destroy rec2/a at s1
> success
> attempting destroy rec2/a
> failed - trying rename rec2/a to rec2/recv-2176-1
> local fs rec2/a/b new parent not found
> cannot open ''rec2/a/b'': dataset does not exist
> another pass:
> attempting destroy rec2/recv-2176-1
> failed (0)
> receiving incremental stream of rec1 at s2 into rec2 at s2
> received 10.8KB stream in 2 seconds (5.41KB/sec)
> receiving full stream of rec1/a at s2 into rec2/a at s2
> received 47.9KB stream in 1 seconds (47.9KB/sec)
> receiving incremental stream of rec1/a/b at s2 into rec2/recv-2176-1/b at
s2
> received 312B stream in 2 seconds (156B/sec)
> local fs rec2/a does not have fromsnap (s1 in stream); must have been
> deleted locally; ignoring
> attempting destroy rec2/recv-2176-1
> failed (0)
> kraken:/root# zfs list | grep rec1
> rec1 238K
> 1.78T 32K /rec1
> rec1/a 63K
> 1.78T 32K /rec1/a
> rec1/a/b 31K
> 1.78T 31K /rec1/a/b
> kraken:/root# zfs list | grep rec2
> rec2 293K
> 1.78T 32K /rec2
> rec2/a 32K
> 1.78T 32K /rec2/a
> rec2/recv-2176-1 64K
> 1.78T 32K /rec2/recv-2176-1
> rec2/recv-2176-1/b 32K
> 1.78T 31K /rec2/recv-2176-1/b
> kraken:/root#
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101123/a7fa1d68/attachment-0001.html>
I verified that this bug exists in OpenSolaris as well. The problem is that
we can''t destroy the old filesystem "a" (which has been
renamed to
"rec2/recv-2176-1" in this case). We can''t destroy it
because it has a
child, "b". We need to rename "b" to be under the new
"a". However, we are
not renaming it, which is the root cause of the problem.
This code in recv_incremental_replication() should detect that we should
rename "b":
if ((stream_parent_fromsnap_guid != 0 &&
parent_fromsnap_guid != 0 &&
stream_parent_fromsnap_guid != parent_fromsnap_guid) ||
...
But this will not trigger because we have already destroyed the snapshots of
b''s parent (the old "a", now "rec2/recv-2176-1"),
so parent_fromsnap_guid
will be 0. I believe that the fix for bug 6921421 introduced this code in
build 135, it used to read:
if ((stream_parent_fromsnap_guid != 0 &&
stream_parent_fromsnap_guid != parent_fromsnap_guid) ||
...
So we will have to investigate and see why the "&&
parent_fromsnap_guid !0" is now needed.
--matt
On Tue, Nov 23, 2010 at 6:16 AM, James Van Artsdalen <
james-opensolaris at jrv.org> wrote:
> I am seeing a zfs recv bug on FreeBSD and am wondering if someone could
> test this in the Solaris code. If it fails there then I guess a bug report
> into Solaris is needed.
>
> This is a perverse case of filesystem renaming between snapshots.
>
> kraken:/root# cat zt
>
> zpool create rec1 da3
> zpool create rec2 da4
>
> zfs create rec1/a
> zfs create rec1/a/b
>
> zfs snapshot -r rec1 at s1
> zfs send -R rec1 at s1 | zfs recv -dvuF rec2
>
> zfs rename rec1/a/b rec1/c
> zfs destroy -r rec1/a
> zfs create rec1/a
> zfs rename rec1/c rec1/a/b # if the rename target is anything other than
> rec1/a/b the "zfs recv" result is right
>
> zfs snapshot -r rec1 at s2
> zfs send -R -I @s1 rec1 at s2 | zfs recv -dvuF rec2
> kraken:/root# sh -x zt
> + zpool create rec1 da3
> + zpool create rec2 da4
> + zfs create rec1/a
> + zfs create rec1/a/b
> + zfs snapshot -r rec1 at s1
> + zfs send -R rec1 at s1
> + zfs recv -dvuF rec2
> receiving full stream of rec1 at s1 into rec2 at s1
> received 47.4KB stream in 2 seconds (23.7KB/sec)
> receiving full stream of rec1/a at s1 into rec2/a at s1
> received 47.9KB stream in 1 seconds (47.9KB/sec)
> receiving full stream of rec1/a/b at s1 into rec2/a/b at s1
> received 46.3KB stream in 1 seconds (46.3KB/sec)
> + zfs rename rec1/a/b rec1/c
> + zfs destroy -r rec1/a
> + zfs create rec1/a
> + zfs rename rec1/c rec1/a/b
> + zfs snapshot -r rec1 at s2
> + zfs send -R -I @s1 rec1 at s2
> + zfs recv -dvuF rec2
> attempting destroy rec2/a at s1
> success
> attempting destroy rec2/a
> failed - trying rename rec2/a to rec2/recv-2176-1
> local fs rec2/a/b new parent not found
> cannot open ''rec2/a/b'': dataset does not exist
> another pass:
> attempting destroy rec2/recv-2176-1
> failed (0)
> receiving incremental stream of rec1 at s2 into rec2 at s2
> received 10.8KB stream in 2 seconds (5.41KB/sec)
> receiving full stream of rec1/a at s2 into rec2/a at s2
> received 47.9KB stream in 1 seconds (47.9KB/sec)
> receiving incremental stream of rec1/a/b at s2 into rec2/recv-2176-1/b at
s2
> received 312B stream in 2 seconds (156B/sec)
> local fs rec2/a does not have fromsnap (s1 in stream); must have been
> deleted locally; ignoring
> attempting destroy rec2/recv-2176-1
> failed (0)
> kraken:/root# zfs list | grep rec1
> rec1 238K
> 1.78T 32K /rec1
> rec1/a 63K
> 1.78T 32K /rec1/a
> rec1/a/b 31K
> 1.78T 31K /rec1/a/b
> kraken:/root# zfs list | grep rec2
> rec2 293K
> 1.78T 32K /rec2
> rec2/a 32K
> 1.78T 32K /rec2/a
> rec2/recv-2176-1 64K
> 1.78T 32K /rec2/recv-2176-1
> rec2/recv-2176-1/b 32K
> 1.78T 31K /rec2/recv-2176-1/b
> kraken:/root#
> --
> This message posted from opensolaris.org
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20101123/2e5a4bfd/attachment.html>
Thanks, James, for reporting this, and thanks, Matt, for the analysis. I filed 7002362 to track this. Tom On 11/23/10 10:43 AM, Matthew Ahrens wrote:> I verified that this bug exists in OpenSolaris as well. The problem is that we > can''t destroy the old filesystem "a" (which has been renamed to > "rec2/recv-2176-1" in this case). We can''t destroy it because it has a child, > "b". We need to rename "b" to be under the new "a". However, we are not > renaming it, which is the root cause of the problem. > > This code in recv_incremental_replication() should detect that we should rename "b": > > if ((stream_parent_fromsnap_guid != 0 && > parent_fromsnap_guid != 0 && > stream_parent_fromsnap_guid != parent_fromsnap_guid) || ... > > But this will not trigger because we have already destroyed the snapshots of b''s > parent (the old "a", now "rec2/recv-2176-1"), so parent_fromsnap_guid will be 0. > I believe that the fix for bug 6921421 introduced this code in build 135, it > used to read: > > if ((stream_parent_fromsnap_guid != 0 && > stream_parent_fromsnap_guid != parent_fromsnap_guid) || ... > > So we will have to investigate and see why the "&& parent_fromsnap_guid != 0" is > now needed. > > --matt > > On Tue, Nov 23, 2010 at 6:16 AM, James Van Artsdalen <james-opensolaris at jrv.org > <mailto:james-opensolaris at jrv.org>> wrote: > > I am seeing a zfs recv bug on FreeBSD and am wondering if someone could test > this in the Solaris code. If it fails there then I guess a bug report into > Solaris is needed. > > This is a perverse case of filesystem renaming between snapshots. > > kraken:/root# cat zt > > zpool create rec1 da3 > zpool create rec2 da4 > > zfs create rec1/a > zfs create rec1/a/b > > zfs snapshot -r rec1 at s1 > zfs send -R rec1 at s1 | zfs recv -dvuF rec2 > > zfs rename rec1/a/b rec1/c > zfs destroy -r rec1/a > zfs create rec1/a > zfs rename rec1/c rec1/a/b # if the rename target is anything other than > rec1/a/b the "zfs recv" result is right > > zfs snapshot -r rec1 at s2 > zfs send -R -I @s1 rec1 at s2 | zfs recv -dvuF rec2 > kraken:/root# sh -x zt > + zpool create rec1 da3 > + zpool create rec2 da4 > + zfs create rec1/a > + zfs create rec1/a/b > + zfs snapshot -r rec1 at s1 > + zfs send -R rec1 at s1 > + zfs recv -dvuF rec2 > receiving full stream of rec1 at s1 into rec2 at s1 > received 47.4KB stream in 2 seconds (23.7KB/sec) > receiving full stream of rec1/a at s1 into rec2/a at s1 > received 47.9KB stream in 1 seconds (47.9KB/sec) > receiving full stream of rec1/a/b at s1 into rec2/a/b at s1 > received 46.3KB stream in 1 seconds (46.3KB/sec) > + zfs rename rec1/a/b rec1/c > + zfs destroy -r rec1/a > + zfs create rec1/a > + zfs rename rec1/c rec1/a/b > + zfs snapshot -r rec1 at s2 > + zfs send -R -I @s1 rec1 at s2 > + zfs recv -dvuF rec2 > attempting destroy rec2/a at s1 > success > attempting destroy rec2/a > failed - trying rename rec2/a to rec2/recv-2176-1 > local fs rec2/a/b new parent not found > cannot open ''rec2/a/b'': dataset does not exist > another pass: > attempting destroy rec2/recv-2176-1 > failed (0) > receiving incremental stream of rec1 at s2 into rec2 at s2 > received 10.8KB stream in 2 seconds (5.41KB/sec) > receiving full stream of rec1/a at s2 into rec2/a at s2 > received 47.9KB stream in 1 seconds (47.9KB/sec) > receiving incremental stream of rec1/a/b at s2 into rec2/recv-2176-1/b at s2 > received 312B stream in 2 seconds (156B/sec) > local fs rec2/a does not have fromsnap (s1 in stream); must have been > deleted locally; ignoring > attempting destroy rec2/recv-2176-1 > failed (0) > kraken:/root# zfs list | grep rec1 > rec1 238K > 1.78T 32K /rec1 > rec1/a 63K > 1.78T 32K /rec1/a > rec1/a/b 31K > 1.78T 31K /rec1/a/b > kraken:/root# zfs list | grep rec2 > rec2 293K > 1.78T 32K /rec2 > rec2/a 32K > 1.78T 32K /rec2/a > rec2/recv-2176-1 64K > 1.78T 32K /rec2/recv-2176-1 > rec2/recv-2176-1/b 32K > 1.78T 31K /rec2/recv-2176-1/b > kraken:/root# > -- > This message posted from opensolaris.org <http://opensolaris.org> > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org <mailto:zfs-discuss at opensolaris.org> > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss