Btrfsck: "root 256 inode 581419 errors 100". Can I heal this file system?

Btrfsck: "root 256 inode 581419 errors 100". Can I heal this file system?

[Adam Ryczkowski]

Welcome.

I was using this btrfs file system on kernel 3.6 rc4 and rc5 and 3.5.4 
on Mint 13 (which is based on Ubuntu 12.04). Now, I found the following 
output of btrfsck /dev/sda8 (which was of course off-line at that time):
> checking extents
> checking fs roots
> root 256 inode 581419 errors 100
> found 97398079488 bytes used err is 1
> total csum bytes: 94539548
> total tree bytes: 589582336
> total fs tree bytes: 412663808
> btree space waste bytes: 128744572
> file data blocks allocated: 870320693248
>  referenced 102221803520
> Btrfs Btrfs v0.19
I understand, that the line "root 256 inode 581419 errors 100" tries to 
tell me, that there is a problem with inode 581419. (Which happen to be 
mountpoint/@/var/cache/hald/fdi-cache; I use btrfs as a root file system 
for Linux mint 13). I pulled the recent btrfs-tools from Ubuntu 12.10 
(https://launchpad.net/ubuntu/quantal/+package/btrfs-tools; version 
0.19+20120328-7ubuntu1 
<https://launchpad.net/ubuntu/quantal/+source/btrfs-tools/0.19+20120328-7ubuntu1>). 
The btrfsck doesn't make the error disapear. I don't experience any 
problems with the file system, but maybe I am only lucky.

What exactly does this error mean?

Is there any way to heal the file system?

I can read the file just fine. But I can't confirm if the contents are 
valid though; they definitely don't look random. Would deleting the file 
help? Or re-writing it?

Is there any way of recovering from this error, or should I rebuild the 
file system from scratch?

I will gladly assist you with providing any debugging information you 
need. Just give me clear instructions, what to do. The file system is 
not in production.

Adam Ryczkowski

Re: Btrfsck: "root 256 inode 581419 errors 100". Can I heal this file system?

[David Sterba]

On Sun, Sep 30, 2012 at 12:26:36AM +0200, Adam Ryczkowski wrote:
> I was using this btrfs file system on kernel 3.6 rc4 and rc5 and 3.5.4 on
> Mint 13 (which is based on Ubuntu 12.04). Now, I found the following output
> of btrfsck /dev/sda8 (which was of course off-line at that time):
> >checking extents
> >checking fs roots
> >root 256 inode 581419 errors 100

If I'm reading fsck.c right, it means that there are missing extents at
the end of the file, ie some unaccounted range.

Please run 'filefrag -vb mountpoint/@/var/cache/hald/fdi-cache', save
the last line, and add the 2nd and last numbers

  22 1046528 52330076 63340363   2048 eof
     ^^^^^^^                     ^^^^

multiply by 1024 and this will give end of the accounted extents. Next,
run 'stat' on the file to find it's size. Tell me those numbers and I'll
tell you if your filesystem is broken :)

I think the error comes from a truncate that made extents and file size
disagree and this can be further observed by reading the file beyond the
last extent. In ideal case it returns zeros in that range, or refuse to
read anything due to missing checksum.

Do you recall any unclean shutdown? As it's a cache of a system(!d)
service, the file will be probably open for a long time and will last
out to all unexpected shutdowns.

> I understand, that the line "root 256 inode 581419 errors 100" tries to tell
> me, that there is a problem with inode 581419. (Which happen to be
> mountpoint/@/var/cache/hald/fdi-cache; I use btrfs as a root file system for
> Linux mint 13). I pulled the recent btrfs-tools from Ubuntu 12.10
> (https://launchpad.net/ubuntu/quantal/+package/btrfs-tools; version
> 0.19+20120328-7ubuntu1 <https://launchpad.net/ubuntu/quantal/+source/btrfs-tools/0.19+20120328-7ubuntu1>).
> The btrfsck doesn't make the error disapear. I don't experience any problems
> with the file system, but maybe I am only lucky.

Not sure here, it's fsck after all, but the particular error could be
fixed by resetting the inode size to the last extent end or adding a
preallocated range for the gap.

> Is there any way to heal the file system?
> 
> I can read the file just fine. But I can't confirm if the contents are valid
> though; they definitely don't look random. Would deleting the file help? Or
> re-writing it?

If it's a cache, the application will be able to recreate it if you
delete it. Howver I'm not sure if this would not provoke a runtime bug.

Maybe other developers would like to investigate, so please do not
delete it yet. Otherwise, 'rm', or 'truncate -s0 file; rm file' should work.


david