One more while running a scrub dmesg logs showed this
[98761.912449] scrub_handle_errored_block: 22 callbacks suppressed
[98761.912472] BTRFS warning (device sda): checksum error at logical
5614914584576 on dev /dev/sda, sector 10979229344: metadata leaf (level 0)
in tree 7
[98761.912476] BTRFS wa
Output of one more command.
---
./btrfs inspect-internal dump-tree /dev/sda > dump.txt
parent transid verify failed on 15732050345984 wanted 73879 found 73881
parent transid verify failed on 15732050345984 wanted 73879 found 73881
parent transid verify failed on 15732050345984 wanted 73879 foun
It is a recent filesystem the data was written with kernel 4.10, today I
upgraded to 4.11rc8 to see if it helped anything which it did not.
On 4/30/17, 4:35 PM, "ch...@colorremedies.com on behalf of Chris Murphy"
wrote:
>On Sun, Apr 30, 2017 at 3:08 PM, Zach Aller wrote:
>
>> uname -a
>> Linux
On Sun, Apr 30, 2017 at 3:08 PM, Zach Aller wrote:
> uname -a
> Linux server 4.11.0-041100rc8-generic #201704232131 SMP Mon Apr 24
> 01:32:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> ./btrfs --version
> btrfs-progs v4.10
>
> ./btrfs fi show
> Label: none uuid: bdd89c26-038d-49fd-b895-52b8deb9
So I have been getting a lot of errors with a btrfs filesystem. I would
like to figure out how to fix them without losing data or having to redo
the data. Below I have the output of some of the requested command. I have
ran a btrfs check without the ‹repair option I wanted to check here first
to se
Thank you very much for your response.
I had just discovered exactly this a few hours ago. In sending an
original snapshot instead of using a duplicate already in place, I was
able to get around this problem.
As you mentioned, the error was coming from the receive side.
I am presently invest
On Sat, Apr 29, 2017 at 9:10 PM, J. Hart wrote:
> I am trying to do a "send -p src/snp1 src/snp2 dst/" and getting the
> following error:
>
> ERROR: cannot find parent subvolume
>
> The "src/snp1" is present in both "src/" and "dst/".
It's not merely that it must be present. The src/snp1 must hav
I am seeing the following error in one of a series of "btrfs send"
operations. The error is as follows:
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
It looks like it mig
Thank you very much for your thoughtful and thorough reply. I
appreciate this very much.
I have finally been able to work past the issue. It seems that
send/receive participates in maintaing some sort of "chain of
custody/ancestry". I had been using a pre-existing snapshot at the
destinat
J. Hart posted on Sat, 29 Apr 2017 23:10:48 -0400 as excerpted:
> I am trying to do a "send -p src/snp1 src/snp2 dst/" and getting the
> following error:
>
> ERROR: cannot find parent subvolume
>
> The "src/snp1" is present in both "src/" and "dst/". The "src/snp2" is
> present in "src/" .
> T
10 matches
Mail list logo
