1

For last two days I have been trying to create 2TB btrfs for my disk dumps. I forced compression zstd. I have it mounted like this: defaults,nofail,compress-force=zstd

Now this is my second time trying this, but both times I have tried to wrote like 1,5TB of my backup images, but both times btrfs failed.

Both times when copying large file, the filesystem changes to read-only. In syslog, I have the following:

Oct 25 18:59:20 omv kernel: [ 3452.595259] BTRFS error (device dm-2): bad tree block start, want 90110312448 have 9500881985411515836

Oct 25 18:59:20 omv kernel: [ 3452.595649] BTRFS error (device dm-2): bad tree block start, want 90110312448 have 9500881985411515836

Oct 25 18:59:20 omv kernel: [ 3452.612085] BTRFS error (device dm-2): bad tree block start, want 90110312448 have 10918816554937311883

Oct 25 18:59:30 omv kernel: [ 3462.509548] BTRFS error (device dm-2): bad tree block start, want 90110476288 have 18378735883139905718

Oct 25 18:59:30 omv kernel: [ 3462.517681] BTRFS error (device dm-2): bad tree block start, want 90110476288 have 16978710206724533460

Oct 25 18:59:30 omv kernel: [ 3462.517743] BTRFS: error (device dm-2) in __btrfs_run_delayed_items:1158: errno=-5 IO failure

Oct 25 18:59:30 omv kernel: [ 3462.517768] BTRFS info (device dm-2): forced readonly

Oct 25 18:59:30 omv kernel: [ 3462.517770] BTRFS warning (device dm-2): Skipping commit of aborted transaction.

Oct 25 18:59:30 omv kernel: [ 3462.517771] BTRFS: error (device dm-2) in cleanup_transaction:1846: errno=-5 IO failure

After unmount and reboot, I cannot mount it again, I get:

mount: wrong fs type, bad option, bad superblock on /dev/mapper/vdd-crypt,

missing codepage or helper program, or other error



In some cases useful info is found in syslog - try

dmesg | tail or so.

Running btrfsck get me this:

couldn't open because of unsupported option features (10).Couldn't open file system

Running zero-log gives me:couldn't open because of unsupported option features (10).

ERROR: could not open ctree

Dmesg gets filled with this:

[ 56.092845] BTRFS error (device dm-2): parent transid verify failed on 21037056 wanted 209 found 207

[ 56.104033] BTRFS error (device dm-2): parent transid verify failed on 21037056 wanted 209 found 207

[ 56.104203] BTRFS error (device dm-2): failed to read chunk root

[ 56.124933] BTRFS error (device dm-2): open_ctree failed

Is this normal? How to fix it? I was able to get to practically the same state, by using different hdd and different sata port on different sata controller.

Also in both cases, there were just single directory and four large files on the whole filesystem.

After btrfs-progs update to new version, I get:

root@omv:/# btrfsck --repair /dev/mapper/vdd-crypt 
enabling repair mode
Opening filesystem to check...
parent transid verify failed on 21037056 wanted 209 found 207
parent transid verify failed on 21037056 wanted 209 found 207
parent transid verify failed on 21037056 wanted 209 found 207
parent transid verify failed on 21037056 wanted 209 found 207
Ignoring transid failure
checksum verify failed on 90110214144 found E34B5BA0 wanted 97B68C5B
checksum verify failed on 90110214144 found E34B5BA0 wanted 97B68C5B
checksum verify failed on 90110214144 found 4287F9E2 wanted 2A67C9FF
checksum verify failed on 90110214144 found E34B5BA0 wanted 97B68C5B
bad tree block 90110214144, bytenr mismatch, want=90110214144, have=12064840543539481400
Couldn't read tree root
ERROR: cannot open file system
Alexander Weps
  • 11
  • 3
  • I want to understand your title question. So, without `compress-force=zstd` everything works fine? – rickhg12hs Oct 26 '19 at 07:25
  • @rickhg12hs I can't say anything for sure. This is a random problem which I was able able to reproduce for a second time. It is time exhausting to reproduce, only after copying around 1,5TB of data. But on the same machine I have large btrfs of 6TB and 8TB and there were no problem with those two. This is smaller btrfs of 2TB and only difference is "compress-force=zstd", the other two are not compressed. I have reproduced this on a different hard drive, on a different sata port on a different sata controller on the same system. – Alexander Weps Oct 26 '19 at 10:22
  • The problem may be zstd, or problem may be large file on zstd, on of the files is more than 1TB, I am not really sure. But, because it has happened twice, I think it is a real issue with btrfs. I am now more interested if btrfs is fixable, I happend when copying file. And my understanding would be, that anything but the file should be intact. This seems to me so far, that btfrs is highly unreliable and for more, it cannot fix itself with btrfs-progs. Any ideas appreciated. – Alexander Weps Oct 26 '19 at 10:22
  • Your frustration is understandable. Maybe try your distro bug-tracker or linux-btrfs@vger.kernel.org . I have only used `btrfs` with `compress-force=zstd` on smaller virtual machines and it has performed flawlessly. I also attach and mount with `discard` so after `btrfs balance` and `fstrim` my VM's virtual media files stay relatively small. – rickhg12hs Oct 26 '19 at 20:01

0 Answers0