| 34 | | The `rsync` process running in the guest (copying data from one vdisk to another) doesn't seem to notice though and is still running, I wonder about data integrity though. |
| | 34 | The `rsync` process running in the guest (copying data from one vdisk to another) doesn't seem to notice though and is still running, ~~I wonder about data integrity though~~. OK, so the `rsync` process in the guest ended w/o errors (RC 0) and copied ~70 GB from one disk to another. But seeing these device errors in the guest I'm running now a [https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub btrfs scrub] on the disk and here the errors are indeed visible: |
| | 35 | |
| | 36 | {{{ |
| | 37 | $ btrfs scrub status /mnt |
| | 38 | scrub status for 044722df-de28-4604-a48d-92779769f47c |
| | 39 | scrub started at Tue Oct 23 14:37:33 2018, running for 00:25:32 |
| | 40 | total bytes scrubbed: 45.30GiB with 192 errors |
| | 41 | error details: csum=192 |
| | 42 | corrected errors: 0, uncorrectable errors: 192, unverified errors: 0 |
| | 43 | }}} |
| | 44 | |
| | 45 | And while scrubbing, the guest's syslog tell me which inodes (and files) have these checksum errors - all Git `.pack` files. That's exactly the reason why I copied these files from an `xfs` to a `btrfs` disk within this guest because `git` failed to read its objects before and now I know why :-\ |
