Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
srd424 opened this issue Jun 14, 2020 · 1 comment

Comments

@srd424
Copy link
Contributor

srd424 commented Jun 14, 2020

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
Copy link

thkukuk commented Mar 22, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants