Weird behaviour of "tar --listed-incremental" on btrfs

[halfdog]

Hello list,

I am analyzing unexpected behaviour around incremental tar backups
which were so far only seen when

1) running --listed-incremental with copying indices (level N-1
to N as described in tar manpage) of "/home" directory.

2) creating such incremental backups of data from "/home" while
a btrfs "subvolid=0" mount was active for a completely unrelated
path other than "/home" but affecting the same file system similar
to bind mounts (mount -o subvolid=0 /dev/sda1 /mnt) and btrfs
snapshots being created/removed there. This btrfs related condition
is not proven yet as there was no way to cleanly reproduce the
issue yet but I could not think of anything else special going
on and affecting the file system around that time.


The outcome was that incremental backups started to be identical
to full backups in size while usually they are below 3% of full
backup size.


If the btrfs interaction is really the reason, the issue might
be due to btrfs breaking some (inofficial) API assumptions tar
is relying on, or maybe even the Linux kernel 5.10 file system API.


The reason for asking here is that the only hint to the underlying
reason so far is the structure of the tar index files, which
is completely different whenever the problem occured.

A sequence of "normal" indices would start like that

GNU tar-1.34-2
1630841185
9004864
1367129626
208105868
180302
./[dir-a]

GNU tar-1.34-2
1630941984
24586310
1367129626
208105868
180302
./[dir-a]

while when unknown event causes the messup the index starts with

GNU tar-1.34-2
1630739742
308717233
1531516583
605322568
178790
./[dir-b]

Both [dir-a] and [dir-b] were present from the first full backup
on and where never modified or changed since then, only the access
time was updated.


Does tar rely on a "constant" ordering of files and directories
from "readdir" to match them up against the index files? As btrfs
might have copy-on-write interaction for quite a lot of structures
(maybe also directory entries) the readdir order may magically
change due to snapshot processing due to internal restructuring.

Any other ideas that may cause such effects?

Kind regards,
hd