On Sat, Aug 12, 2017 at 4:49 PM, Hugo Mills <h...@carfax.org.uk> wrote:
> On Sat, Aug 12, 2017 at 03:34:01PM -0600, Chris Murphy wrote:
>> On Fri, Aug 11, 2017 at 11:08 PM, <siranee...@tpc.co.th> wrote:
>> > The backup script has the btrfs sync command since Aug 3
>> From your script:
>> > system btrfs sub snap -r $basepath $snappath
>> > system btrfs sub sync $basepath
>> From the man page: sync <path> [subvolid...]
>> Wait until given subvolume(s) are completely removed from the
>> filesystem after deletion.
>> This 'subvolume sync' command, per the man page, is only about
>> subvolume deletion. I suggest replacing it with a regular sync
>> I think the problem is that the script does things so fast that the
>> snapshot is not always consistent on disk before btrfs send starts.
>> It's just a guess though. If I'm right, this means the rsync mismaches
>> mean the destination snapshots are bad. Here's what I would do:
> I don't see how that can happen. Snapshots are atomic -- they're
> either there or not there. It's not a matter even of copying the
> metadata part of the subvol. It's literally just adding a pointer to
> point at an existing FS tree.
Do snapshots come with sync and flush to disk? Or does it just set a
checkpoint and the extents that are as yet uncommitted prior to the
snapshot aren't for sure on disk yet until the next commit time or
Nevertheless the wiki explicitly says to do sync after taking a
snapshot in the context of send/receive.
And people on the list have had this "stale NFS file handle" error .
I have no idea if it's still a problem with current kernels, or if it
applies to 4.4 kernel.
Anyway, the OP does appear to be having a real problem. rync is very
clearly showing a given snapshot with incremental send/receive differ
by *a lot* on source and destination machines.
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