All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hendrik Friedel <hendrik@friedels.name>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: free space inode generation (0) did not match free space cache generation
Date: Sat, 22 Mar 2014 19:13:48 +0100	[thread overview]
Message-ID: <532DD2DC.3030408@friedels.name> (raw)

Hello,

I have a file-system on which I cannot write anymore (no space left on 
device, which is not true
root@homeserver:~/btrfs/integration/devel# df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdd2        30G     24G  5,1G   83% /mnt/test1
)

About the filesystem:
root@homeserver:~/btrfs/integration/devel# ./btrfs fi show /mnt/test1
Label: 'ROOT_BTRFS_RAID'  uuid: a2d5f2db-04ca-413a-aee1-cb754aa8fba5
         Total devices 2 FS bytes used 11.84GiB
         devid    1 size 14.85GiB used 14.67GiB path /dev/sde2
         devid    2 size 14.65GiB used 14.65GiB path /dev/sdd2
Btrfs this-will-become-v3.13-48-g57c3600


Check of the filesystem:
root@homeserver:~/btrfs/integration/devel# umount /mnt/test1
root@homeserver:~/btrfs/integration/devel# ./btrfsck /dev/sdd2
Checking filesystem on /dev/sdd2
UUID: a2d5f2db-04ca-413a-aee1-cb754aa8fba5
checking extents
checking free space cache
free space inode generation (0) did not match free space cache 
generation (41)
free space inode generation (0) did not match free space cache 
generation (7380)
free space inode generation (0) did not match free space cache 
generation (3081)
checking fs roots
checking csums
checking root refs
found 3680170466 bytes used err is 0
total csum bytes: 10071956
total tree bytes: 2398781440
total fs tree bytes: 2308784128
total extent tree bytes: 74203136
btree space waste bytes: 372004575
file data blocks allocated: 341759610880
  referenced 75292241920
Btrfs this-will-become-v3.13-48-g57c3600

Before the btrfsck I did a
  mount -o clear_cache  /dev/sdd2 /mnt/test1/

which in fact reduced the number of error messages (did not match free 
space cache generation) from more than ten to just three.

I do have a backup of the FS and in fact it would have been quicker just 
whiping the disk and using the backup (just 16GB), than writing this 
message.
But:
Is it of interest to look at fixing this for someone, so that the 
development of btrfs can profit of this, or should I just whipe the disc?

Greetings,
Hendrik

             reply	other threads:[~2014-03-22 18:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-22 18:13 Hendrik Friedel [this message]
2014-03-22 19:23 ` free space inode generation (0) did not match free space cache generation Duncan
     [not found] <532DF38B.40409@friedels.name>
2014-03-22 21:16 ` Hendrik Friedel
2014-03-22 23:32   ` Duncan
2014-03-24 20:52     ` Hendrik Friedel
2014-03-25 13:00       ` Duncan
2014-03-25 20:03         ` Hendrik Friedel
2014-03-25 20:10           ` Hugo Mills
2014-03-25 21:28             ` Duncan
2014-03-25 21:50               ` Hugo Mills
2014-03-28  7: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=532DD2DC.3030408@friedels.name \
    --to=hendrik@friedels.name \
    --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 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.