On Mon, Aug 30, 2021 at 11:51 AM Filipe Manana wrote: > > On Fri, Aug 27, 2021 at 10:05 PM Darrell Enns wrote: > > > > Inode number of places.sqlite is 400698. It's the same in both > > snapshots, as well as the current active subvolume. > > > > From 2nd snapshot (id 977): > > Size: 83886080 Blocks: 163840 IO Block: 4096 regular file > > Device: 5fh/95d Inode: 400698 Links: 1 > > Access: (0640/-rw-r-----) Uid: ( 1000/ denns) Gid: ( 1000/ denns) > > Access: 2021-08-27 09:59:01.619570401 -0700 > > Modify: 2021-08-27 10:06:43.952629419 -0700 > > Change: 2021-08-27 10:06:43.952629419 -0700 > > Birth: 2021-08-07 20:16:37.080012116 -0700 > > Thanks. > A quick first look shows me that the cause is not what I initially > suspected - the clone operation that fails is not from the inode at > the send snapshot to the same inode at the send snapshot (cloning from > itself), but instead from the parent snapshot to the send snapshot. > The clone offset and length seem valid at first glance, as clone range > is within the eof of the inode in the parent snapshot and it's > properly aligned. So I'll have to recreate the same extent layout and > see if it fails, which will take a while. > > Can you please keep those snapshots (IDs 977 and 881) for a few days, > in case of the need to get more debug information or to try a patch? > > Also, I forgot to ask before, but you are not passing any clone roots > to "btrfs send" (-c command line argument), right? > > Thanks, I'll get back to you later. Ok, so I tried a test using the same file extent layout that you have for the parent and send snapshots, but it didn't fail: (...) write foobar - offset=79036416 length=32768 write foobar - offset=79069184 length=32768 write foobar - offset=79101952 length=32768 clone foobar - source=foobar source offset=79134720 offset=79134720 length=4751360 utimes foobar (...) Apart from the file name (which is irrelevant), the offsets, lengths and operations match the ones you pasted before. So this is really weird, and it's a different case from the last fixes you found, since in this case the clone operation is from the parent to the send snapshot, and not from the send snapshot to the send snapshot (and same inode) - which should work just fine since the range is within the EOF limit of the file and it's properly aligned. If you still have those snapshots, with IDs of 881 (parent) and 977 (send), can you apply the attached debug patch, run the incremental send with those two snapshots and paste the messages from dmesg/syslog? I also pasted the debug patch at: https://pastebin.com/raw/RnZRDhD0 Thanks, that would help a lot. > > > -- > Filipe David Manana, > > “Whether you think you can, or you think you can't — you're right.” -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”