systemd / casync

Content-Addressable Data Synchronization Tool
1.51k stars 117 forks source link

Implicit seed of pre-existing output breaks with 'Stale file handle' error when reflinking #240

Open srd424 opened 4 years ago

srd424 commented 4 years ago

Hitting a problem reflinking on btrfs when using the implicit seeding of pre-existing files in the output directory.

In this example, the error is returned from calocation.c:583; open fds are:

lrwx------ 1 root root 64 Jun 14 22:22 0 -> /dev/pts/3
lrwx------ 1 root root 64 Jun 14 22:22 1 -> /dev/pts/3
lr-x------ 1 root root 64 Jun 14 22:22 10 -> /vol/contpool/fs2-usrsvcs-20.04/bin/btrfs
lr-x------ 1 root root 64 Jun 14 22:22 11 -> /vol/contpool/fs2-usrsvcs-20.04/bin
lrwx------ 1 root root 64 Jun 14 22:22 2 -> /dev/pts/3
lr-x------ 1 root root 64 Jun 14 22:22 3 -> /vol/contpool/fs2-usrsvcs-20.04
lr-x------ 1 root root 64 Jun 14 22:22 4 -> /vol/contpool/fs2-usrsvcs-20.04
lr-x------ 1 root root 64 Jun 14 22:22 5 -> /mnt/fs2-usrsvcs-20.04.caidx
lr-x------ 1 root root 64 Jun 14 22:22 6 -> /mnt/tmp/75c8d84c44b80b94.cased
lr-x------ 1 root root 64 Jun 14 22:22 7 -> /vol/contpool/fs2-usrsvcs-20.04/bin
lr-x------ 1 root root 64 Jun 14 22:22 8 -> '/vol/contpool/fs2-usrsvcs-20.04/bin/btrfs (deleted)'
l-wx------ 1 root root 64 Jun 14 22:22 9 -> /vol/contpool/fs2-usrsvcs-20.04/bin/.#btrfs-convert40c3877d649e88ec

The pre-existing 'bin/btrfs' had a chunk which is shared with the new btrfs-convert, but in the meantime it has been overwritten with a new version, and so when ca_location_open() tries to validate that inode numbers have not changed, it fails.

#0  ca_location_open (l=0x493458) at ../src/calocation.c:583
#1  0x00436cdc in ca_decoder_node_reflink (d=0x46c838, n=0x46ca10) at ../src/cadecoder.c:3299
#2  0x004374d6 in ca_decoder_finalize_child (d=0x46c838, n=0x46c938, child=0x46ca10) at ../src/cadecoder.c:3539
#3  0x0043963e in ca_decoder_step_node (d=0x46c838, n=0x46c938) at ../src/cadecoder.c:4231
#4  0x00439e20 in ca_decoder_step (d=0x46c838) at ../src/cadecoder.c:4463
#5  0x0041ec1c in ca_sync_step_decode (s=0x46c3e0) at ../src/casync.c:2613
#6  0x0041fb1e in ca_sync_step (s=0x46c3e0) at ../src/casync.c:3209
#7  0x004079ec in verb_extract (argc=3, argv=0xbefff65c) at ../src/casync-tool.c:1705
#8  0x0040c9ee in dispatch_verb (argc=3, argv=0xbefff65c) at ../src/casync-tool.c:3971
#9  0x0040cbd0 in main (argc=5, argv=0xbefff654) at ../src/casync-tool.c:4008

Workaround seems to be to make a snapshot of the subvolume elsewhere, then casync --seed-output=no --seed=<snapshot> ..

thkukuk commented 3 years ago

I run into the same problems when updating a btrfs based system.