On Wed, Aug 9, 2017 at 12:36 AM, <siranee...@tpc.co.th> wrote: > 488 btrfs sub snap mysql_201707230830 mysql > 489 systemctl start mariadb > 490 btrfs sub list . > 491 cat /var/log/mariadb/mariadb.log
OK so mysql_201707230830 once on machine B is inconsistent somehow. So the questions I have are: Is mysql_201707230830 on machine A really identical to mysql_201707230830 on machine B? You can do an rsync -anc (double check those options) which should independently check whether those two subvolumes are in fact identical. The -n is a no op, which doesn't really matter much because as read only subvolumes any attempt to sync will just result in noisy messages. The -c causes rsync to do its own checksum verification on both sides. If the subvolumes are different, we need to find out why. If the subvolumes are the same, then I wonder if you can reproduce the mariadb complaint on machine A merely by making a rw snapshot of mysql_201707230830 and trying to start it. If so, then it's not a send receive problem, it sounds like the snapshot itself is inconsistent, maybe mariadb hasn't actually completely closed out the database at the time the read only snapshot was taken? I'm not sure. If the subvolumes are different, I'm going to recommend updating at least the btrfs-progs because 4.4 is kinda old at this point. The kernel code is what's mainly responsible for the send stream, and the user space code is mainly responsible for receiving. And I don't off hand know or want to look up all the send receive changes between 4.4 and 4.12 to speculate on whether this is has already been fixed. What's the kernel version? -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
