Btrfsck: "root 256 inode 581419 errors 100". Can I heal this file system?
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):
Quoted 11 lines
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
Quoted 6 lines · Adam Ryczkowski
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):Quoted 3 lines
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.
Quoted 8 lines
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.
Quoted 5 lines
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