Hi
As the fs in question is my root, I tried the following using a live usb
stick of a xubuntu 16.10:
Checking filesystem on /dev/sdb1
UUID: 122ecca7-9804-4c8a-b4ed-42fd6c6bbe7a
checking extents [o]
checking free space cache [.]
checking fs roots [o]
found 40577679360 bytes used err is 0
total csum bytes: 39027548
total tree bytes: 571277312
total fs tree bytes: 453001216
total extent tree bytes: 71745536
btree space waste bytes: 116244847
file data blocks allocated: 46952968192
referenced 44081487872
"err is 0" ... so I guess that means everything is fine?
Out of curiosity I retried the new_snap+send+receive on that same fs
using the live cd: same results (ERROR unlink ...)
Though I noticed that the exact file in question (reported by ERROR) is
somewhat random ...
For this test with the live usb, I mounted the root volume directly
instead of subvolumes via fstab. So that doesn't seam to have been the
problem either.
I did some further meditating on what happens here. From what I read and
understand of send/receive, the stream produced by send is about
replaying the fs events. If I give send a parent, it will just replay
the difference between the two snapshots and only produce a stream that
contains the changes needed to "transform" one (parent) snap into the
other (on the receiving end). Now I'm not sure how the receiving end
figures out what the parent is, and whether it has it, but I guess
that's where all those UUIDs come into play.
There are three UUIDs, if I compare them on sending ("lab") and
receiving ("server") side, I see:
## sender
# btrfs subv show /.back/last_snap_by_script
/.back/last_snap_by_script
UUID: b4634a8b-b74b-154a-9f17-1115f6d07524
Parent UUID: b5f9a301-69f7-0646-8cf1-ba29e0c24fac
Received UUID: 196a0866-cd05-d24e-bac6-84e8e5eb037a
## receiver
# btrfs subv show /media/bak/lab/root/last_snap_by_script
UUID: 89321ec1-2de6-0a4c-8f9f-cdd30fa3a7af
Parent UUID: -
Received UUID: 196a0866-cd05-d24e-bac6-84e8e5eb037a
So that does make sense to me, as neither "Parent UUID" nor "UUID" is
what would fit our needs (both are kind of local to one system). Instead
the "Received UUID" seams to be the link identifying snaps on both ends
to be "equal". But then why do both snaps on the sending side have the
same "Received UUID" for me:
## from my original post, on sender side, this is the "new" delta snapshot
# btrfs subv show /.back/new_snap
/.back/new_snap
Name: new_snap
UUID: fca51929-8101-db45-8df6-f25935c04f98
Parent UUID: b5f9a301-69f7-0646-8cf1-ba29e0c24fac
Received UUID: 196a0866-cd05-d24e-bac6-84e8e5eb037a
It would be great if some one could clear this up .. could this point to
the reason on why the "replay" stream is produced on a wrong basis?
Another thing I tried is the "--max-error 0" option of receive. That
lets it continue after error, but that produced an endless slur of more
of the same errors. Is that another indicator that the parent on the
sending or receiving side is identified wrongly or not at all?
In any case, thanks for the tip Giuseppe :-)
Regards
Rene
On 29.12.2016 16:31, Giuseppe Della Bianca wrote:
Hi.
In such cases, I have run btrfs check (not repair mode !!!) in every
file system/partition that is involved in creating, sending and
receiving snapshots.
Regards.
Gdb
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
