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:
smime.p7s
Description: S/MIME cryptographic signature
