ERROR: rename o3528-7220-0 -> usr failed: Directory not empty
I've got more information on the following error :
At subvol /mnt/ArchPri/backup/primary/thinkcentre/root/backup.0.2 At snapshot backup.0.2017.04.21.03.11.40
ERROR: rename o3528-7220-0 -> usr failed: Directory not empty
I've filed a bug report with additional details at:
https://bugzilla.kernel.org/show_bug.cgi?id=195619
This error occurs during a series of "btrfs send" invocations. It does not occur on all of them, but always at the same point in the operation, and so appears to be specific to (dependent on) the data being sent.
I have a test case down to the following:
su -
btrfs send --no-data temp/backup.0.2017.04.17.07.57.17 | btrfs rec temp/test
sync
btrfs send --no-data -p temp/backup.0.2017.04.17.07.57.17 temp/backup.0.2017.04.21.03.11.40 | btrfs rec temp/test
The error should be something like:
At subvol temp/backup.0.2017.04.21.03.11.40
At snapshot backup.0.2017.04.21.03.11.40
ERROR: rename o3528-7220-0 -> usr failed: Directory not empty
I will probably need to provide the data somehow, or at least the output from "btrfs send". The original data is several GB in size.
J. Hart
Quoted 22 lines · J. Hart
I've got more information on the following error :
At subvol
/mnt/ArchPri/backup/primary/thinkcentre/root/backup.0.2At snapshot backup.0.2017.04.21.03.11.40
ERROR: rename o3528-7220-0 -> usr failed: Directory not emptyI've filed a bug report with additional details at:
https://bugzilla.kernel.org/show_bug.cgi?id=195619
This error occurs during a series of "btrfs send" invocations. It does not occur on all of them, but always at the same point in the operation, and so appears to be specific to (dependent on) the data being sent.
I have a test case down to the following:
su -
btrfs send --no-data temp/backup.0.2017.04.17.07.57.17 | btrfs rec temp/test sync
btrfs send --no-data -p temp/backup.0.2017.04.17.07.57.17 temp/backup.0.2017.04.21.03.11.40 | btrfs rec temp/test
Quoted 7 lines
The error should be something like:
At subvol temp/backup.0.2017.04.21.03.11.40
At snapshot backup.0.2017.04.21.03.11.40
ERROR: rename o3528-7220-0 -> usr failed: Directory not emptyI will probably need to provide the data somehow, or at least the output from "btrfs send". The original data is several GB in size.
Just use "btrfs-image -c 9 /dev/whatever image_file", it will create a compressed image where the data is replaced with zeroes (not needed to debug this problem anyway). Then uploaded it anywhere convenient for you.
Thanks.
Quoted 8 lines
J. Hart
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 2 lines · Filipe Manana
On Mon, May 1, 2017 at 4:17 PM, J. Hart <[email protected]> wrote:
Just use "btrfs-image -c 9/dev/whateverimage_file", it will create a compressed image where the data is replaced with zeroes (not needed to debug this problem anyway). Then uploaded it anywhere convenient for you.
I have prepared the image as per your instructions. It is 27 Mb in size. I have no way to confirm whether or not it is correct, as the documentation on how that might be done is unclear on that point. It was also not clear whether or not the btrfs filesystem should be unmounted as the documentation does not specify. A warning appears if it is mounted, so I unmounted it to make the image.
I have at present no convenient location to upload it to. Can you suggest one ?
If you can manage to load the image on to a btrfs filesystem, cd to the mount point and do the following:
btrfs se --no-data snp1 | btrfs rec temp
btrfs se --no-data -p snp1 snp2 | btrfs rec temp # failure here
The error should be something like:
-su-3.2# btrfs se --no-data -p snp1 snp2 | btrfs rec temp # failure here At subvol snp2
At snapshot snp2
ERROR: rename o3528-12-0 -> usr failed: Directory not empty
I have been able to get the requisite data from the original filesystem to a completely different one, and recreate the error on the new filesystem, so the error seems to follow along with the data involved.
Quoted 24 lines · J. Hart
Quoted 5 lines · Filipe Manana
On Mon, May 1, 2017 at 4:17 PM, J. Hart <[email protected]> wrote:
Just use "btrfs-image -c 9/dev/whateverimage_file", it will create a compressed image where the data is replaced with zeroes (not needed to debug this problem anyway). Then uploaded it anywhere convenient for you.I have prepared the image as per your instructions. It is 27 Mb in size. I have no way to confirm whether or not it is correct, as the documentation on how that might be done is unclear on that point. It was also not clear whether or not the btrfs filesystem should be unmounted as the documentation
does not specify. A warning appears if it is mounted, so I unmounted it to
make the image.I have at present no convenient location to upload it to. Can you suggest
one ?If you can manage to load the image on to a btrfs filesystem, cd to the mount point and do the following:
btrfs se --no-data snp1 | btrfs rec temp
btrfs se --no-data -p snp1 snp2 | btrfs rec temp # failure here
Quoted 6 lines
The error should be something like:
-su-3.2# btrfs se --no-data -p snp1 snp2 | btrfs rec temp # failure here At subvol snp2
At snapshot snp2
ERROR: rename o3528-12-0 -> usr failed: Directory not empty
So I managed to use the image and try it myself with the 4.11 kernel codebase. No problems found sending those snapshots. Please try a 4.11 kernel, as there's a few send fixes in there that should fix the issue.
Thanks!
Quoted 6 lines
I have been able to get the requisite data from the original filesystem to a completely different one, and recreate the error on the new filesystem, so the error seems to follow along with the data involved.