Re: strange corruptions found during btrfs check

[Christoph Anton Mitterer <calestyo@scientia.net>]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

On Tue, 2015-07-07 at 00:47 +0000, Duncan wrote:
> The interaction between send/receive and subvolumes/snapshots
> is also a problem, but again, not so much on the subvolume/snapshot 
> side, as on the send/receive side.

Well I haven't looked into any code, so the following is just
perception:
It seemed that send/receive itself has always worked correctly for me
so far.
I.e. I ran some complete diff -qr over the source and target of an
already incrementally (-p) sent/received snapshot.
That brought no error.

The aforementioned btrfs check errors only occurred after I had removed
older snapshots on the receiving side, i.e. snapshots that btrfs, via
the -p <same-old-snapshot-on-the-send-side>, used for building together
the more recent snapshot.

The error messages seem to imply that some of that got lost,... or at
least that would be my first wild guess... as if refs in the newer
snapshot on the receiving side point into the void, as the older
snapshot's objects, they were pointing to, have been removed (or some
of them lost).



Apart from that, I think it's quite an issue that the core developers
don't keep some well maintained list of working/experimental
features... that's nearly as problematic as the complete lack of good
and extensive end user (i.e. sysadmin) documentation.
btrfs is quite long around now, and people start using it... but when
they cannot really tell what's stable and what's not (respectively
which parts of e.g. raid56 still need polishing) and they then stumble
over problems, trust into btrfs is easily lost. :(

Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5313 bytes --]