linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org
Subject: Re: [4.9] btrfs check --repair looping over file extent discount errors
Date: Sat, 22 Apr 2017 12:42:41 +0200	[thread overview]
Message-ID: <1788861.vXu7xdroFy@merkaba> (raw)
In-Reply-To: <1603810.ePCDQapENk@merkaba>

Hello.

I am planning to copy of important data on the disk with the broken filesystem 
to the disk with the good filesystem and then reformatitting the disk with the 
broken filesystem soon, probably in the course of the day… so in case you want 
any debug information before that, let me know ASAP.

Thanks,
Martin

Martin Steigerwald - 14.04.17, 21:35:
> Hello,
> 
> backup harddisk connected via eSATA. Hard kernel hang, mouse pointer
> freezing two times seemingly after finishing /home backup and creating new
> snapshot on source BTRFS SSD RAID 1 for / in order to backup it. I did
> scrubbed / and it appears to be okay, but I didn´t run btrfs check on it.
> Anyway deleting that subvolume works and I as I suspected an issue with the
> backup disk I started with that one.
> 
> I got
> 
> merkaba:~> btrfs --version
> btrfs-progs v4.9.1
> 
> merkaba:~> cat /proc/version
> Linux version 4.9.20-tp520-btrfstrim+ (martin@merkaba) (gcc version 6.3.0
> 20170321 (Debian 6.3.0-11) ) #6 SMP PREEMPT Mon Apr 3 11:42:17 CEST 2017
> 
> merkaba:~> btrfs fi sh feenwald
> Label: 'feenwald'  uuid: […]
>         Total devices 1 FS bytes used 1.26TiB
>         devid    1 size 2.73TiB used 1.27TiB path /dev/sdc1
> 
> on Debian unstable on ThinkPad T520 connected via eSATA port on Minidock.
> 
> 
> I am now running btrfs check --repair on it after without --repair the
> command reported file extent discount errors and it appears to loop on the
> same file extent discount errors for ages. Any advice?
> 
> I do have another backup harddisk with BTRFS that worked fine today, so I do
> not need to recover that drive immediately. I may let it run for a little
> more time, but then will abort the repair process as I really think its
> looping just over and over and over the same issues again. At some time I
> may just copy all the stuff that is on that harddisk, but not on the other
> one over to the other one and mkfs.btrfs the filesystem again, but I´d
> rather like to know whats happening here.
> 
> Here is output:
> 
> merkaba:~> btrfs check --repair /dev/sdc1
> enabling repair mode
> Checking filesystem on /dev/sdc1
> [… UUID ommited …]
> checking extents
> Fixed 0 roots.
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> root 257 inode 4979842 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 78798848
> root 257 inode 4980212 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 143360
> root 257 inode 4980214 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4227072
> root 257 inode 4979842 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 78798848
> root 257 inode 4980212 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 143360
> root 257 inode 4980214 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4227072
> root 257 inode 4979842 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 78798848
> root 257 inode 4980212 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 143360
> root 257 inode 4980214 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4227072
> root 257 inode 4979842 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 78798848
> root 257 inode 4980212 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 143360
> root 257 inode 4980214 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4227072
> [… hours later …]
> root 257 inode 4979842 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 78798848
> root 257 inode 4980212 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 143360
> root 257 inode 4980214 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4227072
> root 257 inode 4979842 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 78798848
> root 257 inode 4980212 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 143360
> root 257 inode 4980214 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4227072
> root 257 inode 4979842 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 78798848
> root 257 inode 4980212 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 143360
> root 257 inode 4980214 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4227072
> 
> This basically seems to go on like this forever.
> 
> Thanks,


-- 
Martin

  reply	other threads:[~2017-04-22 10:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-14 19:35 [4.9] btrfs check --repair looping over file extent discount errors Martin Steigerwald
2017-04-22 10:42 ` Martin Steigerwald [this message]
2017-04-22 15:31 ` Chris Murphy
2017-04-22 18:01   ` Martin Steigerwald
2017-04-22 19:35     ` Martin Steigerwald

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=1788861.vXu7xdroFy@merkaba \
    --to=martin@lichtvoll.de \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).