All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Wimmer <telefonchris@icloud.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>, Qu WenRuo <wqu@suse.com>,
	Anand Jain <anand.jain@oracle.com>,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: 12 TB btrfs file system on virtual machine broke again
Date: Sun, 5 Jan 2020 10:40:29 -0300	[thread overview]
Message-ID: <CE5FDD33-F072-40EE-9ED7-66D5F7F2A5FA@icloud.com> (raw)
In-Reply-To: <CAJCQCtQmvHS8+Z7=B_8panSzo=Bfo0ymVU+cr_tR5z1uw+Ejug@mail.gmail.com>

Hi Chris,



> On 5. Jan 2020, at 01:03, Chris Murphy <lists@colorremedies.com> wrote:
> 
> On Sat, Jan 4, 2020 at 10:07 AM Christian Wimmer
> <telefonchris@icloud.com> wrote:
>> 
>> Hi guys,
>> 
>> I run again in a problem with my btrfs files system.
>> I start wondering if this filesystem type is right for my needs.
>> Could you please help me in recovering my 12TB partition?
> 
> If you're having recurring problems, there's a decent chance it's
> hardware related and not Btrfs, because Btrfs is pretty stable on
> stable hardware. Btrfs is actually fussier than other file systems
> because everything is checksummed.
> 

I think I can exclude hardware problems. Everything is brand new and well tested.
The biggest chance for being the source of errors is the Parallels Virtual machine where Linux (Suse 15.1) is running in.
In this Virtual Machine I specify a “growing hard disc" that is actually a file on my 32 TB Promise Pegasus Storage.
I just can not understand why it runs fine for almost 1 month (and actually more for other growing hard discs of smaller size) and then shows this behaviour.
As soon as you “are sure" that btrfs is not the problem I will switch to different kind of hard discs.


> 
>> What happened?
>> -> This time I was just rebooting normally my virtual machine. I discovered during the past days that the system hangs for some seconds so I thought it would be a good idea to reboot my SUSE Linux after 14 days of working. The machine powered off normally but when starting it run into messages like the pasted ones.
> 
> A complete dmesg leading up to the problem would be useful. Kernel
> messages at the last moments it was working, and also messages for the
> first mount attempt that failed. And kernel versions for both (sounds
> like 5.4 series).

I have one System with Suse 15.1 where the error happened. The btrfs-progs is of version 4.19.1.
The other system is 5.3.12-1-MANJARO with btrfs-progs version 5.4. Here I try to repair the broken file system.

> 
> And also `btrfs check` output, no repair.

Here the output:

btrfs-progs-5.4]# ./btrfs check /dev/sdb1
Opening filesystem to check...
checksum verify failed on 3181912915968 found 000000A9 wanted 00000064
checksum verify failed on 3181912915968 found 00000071 wanted 00000066
checksum verify failed on 3181912915968 found 000000A9 wanted 00000064
bad tree block 3181912915968, bytenr mismatch, want=3181912915968, have=4908658797358025935
checksum verify failed on 2688623902720 found 00000029 wanted 00000026
checksum verify failed on 2688623902720 found 000000E4 wanted 0000006F
checksum verify failed on 2688623902720 found 00000029 wanted 00000026
bad tree block 2688623902720, bytenr mismatch, want=2688623902720, have=256465382155451
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system
btrfs-progs-5.4]# 


Chris


  reply	other threads:[~2020-01-05 13:42 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06  3:44 [PATCH] btrfs-progs: Skip device tree when we failed to read it Qu Wenruo
2019-12-06  6:12 ` Anand Jain
2019-12-06 15:50   ` Christian Wimmer
2019-12-06 16:34   ` Christian Wimmer
     [not found]   ` <762365A0-8BDF-454B-ABA9-AB2F0C958106@icloud.com>
2019-12-07  1:16     ` Qu WenRuo
2019-12-07  3:47       ` Christian Wimmer
2019-12-07  4:31         ` Qu Wenruo
2019-12-07 13:03           ` Christian Wimmer
2019-12-07 14:10             ` Qu Wenruo
2019-12-07 14:25               ` Christian Wimmer
2019-12-07 16:44               ` Christian Wimmer
2019-12-08  1:21                 ` Qu WenRuo
2019-12-10 21:25                   ` Christian Wimmer
2019-12-11  0:36                     ` Qu Wenruo
2019-12-11 15:57                       ` Christian Wimmer
     [not found]           ` <9FB359ED-EAD4-41DD-B846-1422F2DC4242@icloud.com>
2020-01-04 17:07             ` 12 TB btrfs file system on virtual machine broke again Christian Wimmer
2020-01-05  4:03               ` Chris Murphy
2020-01-05 13:40                 ` Christian Wimmer [this message]
2020-01-05 14:07                   ` Martin Raiber
2020-01-05 14:14                     ` Christian Wimmer
2020-01-05 14:23                       ` Christian Wimmer
2020-01-05  4:25               ` Qu Wenruo
2020-01-05 14:17                 ` Christian Wimmer
2020-01-05 18:50                   ` Chris Murphy
2020-01-05 19:18                     ` Christian Wimmer
2020-01-05 19:36                       ` Chris Murphy
2020-01-05 19:49                         ` Christian Wimmer
2020-01-05 19:52                         ` Christian Wimmer
2020-01-05 20:34                           ` Chris Murphy
2020-01-05 20:36                             ` Chris Murphy
     [not found]                         ` <3F43DDB8-0372-4CDE-B143-D2727D3447BC@icloud.com>
2020-01-05 20:30                           ` Chris Murphy
2020-01-05 20:36                             ` Christian Wimmer
2020-01-05 21:13                               ` Chris Murphy
2020-01-05 21:58                                 ` Christian Wimmer
2020-01-05 22:28                                   ` Chris Murphy
2020-01-06  1:31                                     ` Christian Wimmer
2020-01-06  1:33                                     ` Christian Wimmer
2020-01-11 17:04                                     ` 12 TB btrfs file system on virtual machine broke again (third time) Christian Wimmer
2020-01-11 17:23                                     ` Christian Wimmer
2020-01-11 19:46                                       ` Chris Murphy
2020-01-13 19:41                                         ` 12 TB btrfs file system on virtual machine broke again (fourth time) Christian Wimmer
2020-01-13 20:03                                           ` Chris Murphy
2020-01-31 16:35                                             ` btrfs not booting any more Christian Wimmer
2020-05-08 12:20                                             ` btrfs reports bad key ordering after out of memory situation Christian Wimmer
2020-01-05 23:50                   ` 12 TB btrfs file system on virtual machine broke again Qu Wenruo
2020-01-06  1:32                     ` Christian Wimmer
2020-01-11  7:25                     ` Andrei Borzenkov
2021-10-15 21:01                     ` need help in a broken 2TB BTRFS partition Christian Wimmer
2021-10-16 10:08                       ` Qu Wenruo
2021-10-16 17:29                         ` Christian Wimmer
2021-10-16 22:55                           ` Qu Wenruo
2021-10-16 17:35                         ` Christian Wimmer
2021-10-16 23:27                           ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CE5FDD33-F072-40EE-9ED7-66D5F7F2A5FA@icloud.com \
    --to=telefonchris@icloud.com \
    --cc=anand.jain@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=quwenruo.btrfs@gmx.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.