From: Austin S Hemmelgarn <ahferroin7@gmail.com>
To: "Vackář František" <vackarf@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Btrfs check dont repair
Date: Wed, 23 Sep 2015 13:41:07 -0400 [thread overview]
Message-ID: <5602E433.6070407@gmail.com> (raw)
In-Reply-To: <CAMH1C+r4yYU8hYfcZpFRyN1UWY8OPTs5Md7MdE=bm2RW9udREQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4749 bytes --]
On 2015-09-23 10:39, Vackář František wrote:
> Hello,
>
> i have problem with my btrfs, can you help me, please? Its on my
> notebook. Sometimes it exhausted battery during sleep and died. But
> everytime FS was ok. But ones mount fail.
>
> Do you have any idea how repair it?
First off, the fact that you are on a relatively recent kernel and have
an up-to-date copy of btrfs-progs is a very good thing :). Secondly,
I'm not certain if you did this or not, but always run btrfs check
without the --repair option first, it can't fix everything yet, and
there are still cases from time to time that it actually makes thing
worse when you use the --repair option. As for the kernel messages,
those particular errors are not anything I've ever seen before. Based
on my limited knowledge of the BTRFS internals, I would agree with Hugo
(and ironically, I got your response to his e-mail right as I finished
this one...).
>
> Sorry for my english. :)
Don't feel bad, it's one of the hardest to learn languages for
non-native speakers in the world (and even a lot of people who grew up
speaking it don't consistently use correct grammar). If only Esperanto
or Interlingua had actually caught on...
>
> Frantisek Vackar
> ========================================
> [root@rak ~]# btrfs check --repair /dev/sdb2
> enabling repair mode
> Checking filesystem on /dev/sdb2
> UUID: 754a3186-c0ae-4680-ab28-864c8bdad8b5
> checking extents
> bad key ordering 0 1
> bad block 3242450944
> Errors found in extent allocation tree or chunk allocation
> Fixed 0 roots.
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> bad key ordering 0 1
> Trying to rebuild inode:705555
> root 5 inode 705555 errors 2001, no inode item, link count wrong
> unresolved ref dir 403566 index 0 namelen 10 name .directory
> filetype 1 errors 6, no dir index, no inode ref
> Trying to rebuild inode:705569
> root 5 inode 705569 errors 2001, no inode item, link count wrong
> unresolved ref dir 339745 index 0 namelen 18 name
> 15-03-20-Botanicka filetype 2 errors 6, no dir index, no inode ref
> =====MANY SIMILAR LINES=====
> Trying to rebuild inode:718060
> root 5 inode 718060 errors 2001, no inode item, link count wrong
> unresolved ref dir 430527 index 0 namelen 10 name Win 7.vbox
> filetype 1 errors 6, no dir index, no inode ref
> found 1350650234080 bytes used err is 1
> total csum bytes: 0
> total tree bytes: 466538496
> total fs tree bytes: 17154048
> total extent tree bytes: 448659456
> btree space waste bytes: 94077759
> file data blocks allocated: 3997077504
> referenced 3996086272
> btrfs-progs v4.1.2
>
> [root@rak ~]# mount /mnt/hdd-root/
> mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
> missing codepage or helper program, or other error
>
> In some cases useful info is found in syslog - try
> dmesg | tail or so.
>
> [root@rak ~]# dmesg | tail
> [ 1434.004203] ath5k: ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x00000000
> [ 1674.004209] ath5k: ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x00000000
> [ 2154.007675] ath5k: ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x00000000
> [ 4074.005033] ath5k: ath5k_hw_get_isr: ISR: 0x00000080 IMR: 0x00000000
> [ 4096.970037] BTRFS info (device sdb2): disk space caching is enabled
> [ 4108.444472] BTRFS critical (device sdb2): corrupt leaf, bad key
> order: block=3242455040,root=1, slot=0
> [ 4108.444649] BTRFS critical (device sdb2): corrupt leaf, bad key
> order: block=3242455040,root=1, slot=0
> [ 4108.444681] BTRFS error (device sdb2): Error removing orphan entry,
> stopping orphan cleanup
> [ 4108.444684] BTRFS error (device sdb2): could not do orphan cleanup -22
> [ 4111.047323] BTRFS: open_ctree failed
>
> [root@rak ~]# uname -a
> Linux rak 4.1.2-2-ARCH #1 SMP PREEMPT Wed Jul 15 08:30:32 UTC 2015
> x86_64 GNU/Linux
>
> [root@rak ~]# btrfs fi show /dev/sdb2
> Label: 'data' uuid: 754a3186-c0ae-4680-ab28-864c8bdad8b5
> Total devices 1 FS bytes used 1.23TiB
> devid 1 size 1.72TiB used 1.24TiB path /dev/sdb2
>
> btrfs-progs v4.2
>
> [root@rak ~]# btrfs --version
> btrfs-progs v4.2
>
> [root@rak ~]# btrfs fi show
> Label: 'data' uuid: 754a3186-c0ae-4680-ab28-864c8bdad8b5
> Total devices 1 FS bytes used 1.23TiB
> devid 1 size 1.72TiB used 1.24TiB path /dev/sdb2
>
> btrfs-progs v4.2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]
next prev parent reply other threads:[~2015-09-23 17:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-23 14:39 Btrfs check dont repair Vackář František
2015-09-23 14:43 ` Hugo Mills
2015-09-23 15:22 ` Vackář František
2015-09-25 9:36 ` Vackář František
2015-09-25 10:06 ` Hugo Mills
[not found] ` <CAMH1C+qD8Me-D0VVb5pntPQd4A9VXGCEbxQajZfDCEnWbJUxSA@mail.gmail.com>
2015-10-02 9:05 ` Vackář František
2015-10-02 10:10 ` Vackář František
2015-09-23 17:41 ` Austin S Hemmelgarn [this message]
2015-09-23 19:02 ` Vackář František
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=5602E433.6070407@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=vackarf@gmail.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.