linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hendrik Friedel <hendrik@friedels.name>
To: Duncan <1i5t5.duncan@cox.net>, linux-btrfs@vger.kernel.org
Subject: Re: btrfsck errors is it save to fix?
Date: Mon, 11 Nov 2013 20:06:18 +0100	[thread overview]
Message-ID: <52812AAA.1080106@friedels.name> (raw)
In-Reply-To: <527DF34B.2030309@friedels.name>

Hello,

I re-post this:

 >> To answer the "is it safe to fix" question...
>  >
>> In that context, yes, it's safe to btrfsck --repair, because you're
>> prepared to lose the entire filesystem if worse comes to worse in any
>> case, so even if btrfsck --repair makes things worse instead of better,
>> you've not lost anything you're particularly worried about anyway.
>
> I do have an daily backup of the important data.
> There is other data, that is (a bit more than) nice to keep
> (TV-Recordings). It seems all still readable, so I can also back this
> up, if I could free some space.
>
> So, I have run btrfsck --repair:
> -------
> root@homeserver:~/btrfs/btrfs-progs# git pull
> remote: Counting objects: 124, done.
> remote: Compressing objects: 100% (52/52), done.
> remote: Total 99 (delta 55), reused 89 (delta 47)
> Unpacking objects: 100% (99/99), done.
>  From git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs
>     d1570a0..c652e4e  integration -> origin/integration
> Already up-to-date.
> -------
>
>
> The repair:
> -------
> ./btrfsck --repair /dev/sdc1
> enabling repair mode
> Checking filesystem on /dev/sdc1
> UUID: 989306aa-d291-4752-8477-0baf94f8c42f
> checking extents
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> root 256 inode 9579 errors 100
> root 256 inode 9580 errors 100
> root 256 inode 14258 errors 100
> root 256 inode 14259 errors 100
> root 4444 inode 9579 errors 100
> root 4444 inode 9580 errors 100
> root 4444 inode 14258 errors 100
> root 4444 inode 14259 errors 100
> found 2895817096773 bytes used err is 1
> total csum bytes: 3206482672
> total tree bytes: 3901480960
> total fs tree bytes: 38912000
> total extent tree bytes: 135892992
> btree space waste bytes: 411727425
> file data blocks allocated: 3446512275456
>   referenced 3445793439744
> Btrfs v0.20-rc1-358-g194aa4
> -------
>
>
>
>
>
> After the repair, another check reveals the same errors as before:
> -------
> ./btrfsck  /dev/sdc1
> Checking filesystem on /dev/sdc1
> UUID: 989306aa-d291-4752-8477-0baf94f8c42f
> checking extents
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> root 256 inode 9579 errors 100
> root 256 inode 9580 errors 100
> root 256 inode 14258 errors 100
> root 256 inode 14259 errors 100
> root 4444 inode 9579 errors 100
> root 4444 inode 9580 errors 100
> root 4444 inode 14258 errors 100
> root 4444 inode 14259 errors 100
> found 2895817096773 bytes used err is 1
> total csum bytes: 3206482672
> total tree bytes: 3901480960
> total fs tree bytes: 38912000
> total extent tree bytes: 135892992
> btree space waste bytes: 411727425
> file data blocks allocated: 3446512275456
>   referenced 3445793439744
> Btrfs v0.20-rc1-358-g194aa4a
> -------
>
>
> The only messages in syslog/dmesg regarding btrfs are:
> [299517.270322] btrfs: device fsid 989306aa-d291-4752-8477-0baf94f8c42f
> devid 2 transid 140436 /dev/sdc1
> [299525.805867] btrfs: device fsid 989306aa-d291-4752-8477-0baf94f8c42f
> devid 1 transid 140436 /dev/sdb1
> [299525.807148] btrfs: device fsid 989306aa-d291-4752-8477-0baf94f8c42f
> devid 2 transid 140436 /dev/sdc1
> [299525.808277] btrfs: device fsid 989306aa-d291-4752-8477-0baf94f8c42f
> devid 1 transid 140436 /dev/sdb1
> (repeating several times)
>
>
> Can we find out, why btrfsck does not fix the errors?

I got no reply to this.
Now, I have two Intentions:
-Help improving btrfs(ck)
-Make the System usable again

Please let me know, if it is of interest to work with this example on 
btrfsck, which apparently now is not able to fix this problem and what 
Information you would need from me.

Otherwise, I can proceed to the second point.

Greetings,
Hendrik

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
http://www.avast.com


  reply	other threads:[~2013-11-11 19:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-01 22:29 btrfsck errors is it save to fix? Hendrik Friedel
2013-11-02  8:12 ` cwillu
2013-11-02  8:58   ` Hendrik Friedel
2013-11-04 21:14     ` Hendrik Friedel
2013-11-05  2:03       ` cwillu
2013-11-06  6:45         ` Hendrik Friedel
2013-11-07 19:16           ` Hendrik Friedel
2013-11-08 10:09             ` Duncan
2013-11-09  8:33               ` Hendrik Friedel
2013-11-11 19:06                 ` Hendrik Friedel [this message]
2013-11-11 23:58                   ` Kai Krakow
2013-11-12  7:32                     ` Duncan
2013-11-12 19:37                       ` Kai Krakow
2013-11-13 12:20                         ` Duncan
2013-11-13 12:24                         ` Duncan
2013-11-16 12:32                           ` Hendrik Friedel

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=52812AAA.1080106@friedels.name \
    --to=hendrik@friedels.name \
    --cc=1i5t5.duncan@cox.net \
    --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).