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: Sat, 09 Nov 2013 09:33:15 +0100	[thread overview]
Message-ID: <527DF34B.2030309@friedels.name> (raw)
In-Reply-To: <pan$2f107$ddc92f2a$30381770$58497a03@cox.net>

Hello

thanks for your reply.

> 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?

Greetings,
Hendrik




-- 
Hendrik Friedel
Auf dem Brink 12
28844 Weyhe
Mobil 0178 1874363

  reply	other threads:[~2013-11-09  8:33 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 [this message]
2013-11-11 19:06                 ` Hendrik Friedel
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=527DF34B.2030309@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).