Btrfs devel - Oct 2009 - Oops and somewhat borked filesystem after btrfs-convert and image removal

Hello,

I managed to get an oops and a somewhat borked btrfs filesystem after
using btrfs-convert and then removing the image file. I will explain the
full sequence of actions below (as I remember it):

 - In the beginning, I have an ext3 filesystem that I''d like to convert
   to btrfs

 - I run btrfs-convert on the filesystem, forgetting to do fsck before
   it - however, I have done a full fsck recently on the filesystem, and
   it was cleanly unmounted (no journal replay necessary)

 - Conversion runs smoothly

 - I boot the newly converted filesystem as a root filesystem for my
   computer, and everything looks good. "df" reports proper free
space.

 - I mount the subvolume with the ext2 filesystem under /mnt, while
   having the btrfs main volume as my root filesystem:

     mount -t btrfs -o subvol=ext2_saved /dev/mapper/perspire-root /mnt

 - I remove the image file from the subvolume:

     rm /mnt/image

 - At this time, during or immediately after the removal, I get a
   notification of a kernel oops, which is here:

     http://www.kerneloops.org/submitresult.php?number=823167

 - I unmount the subvolume:

     umount /mnt

 - I reboot the computer, after which I check "df":

     /dev/mapper/perspire-root 7245824 -73786976294826385180 -4575460 100% /

   (Sizes in 1K-blocks, used space being the hugely negative number, and
   available being the somewhat less huge number.)

 - Btrfsck reports:

     root 5 inode 453339 errors 2
     root 5 inode 453343 errors 2
     root 5 inode 453347 errors 2
     root 5 inode 453356 errors 2
     root 5 inode 466532 errors 2
     root 5 inode 466537 errors 2
     root 5 inode 466540 errors 2
     root 5 inode 466544 errors 2
     found 5867835392 bytes used err is 1
     total csum bytes: 5477992
     total tree bytes: 258371584
     total fs tree bytes: 228814848
     btree space waste bytes: 71477071
     file data blocks allocated: 8317644800
      referenced 5582884864
     Btrfs Btrfs v0.19

 - Otherwise the filesystem seems to be in perfect working order, no
   problems that I can see. I have been using it for several days after
   the incident now.

Then, useful info:

 - Kernel: 2.6.31-trunk-686 (debian experimental)
 - Btrfs utilities: 0.19-5 (debian package)
 - Hardware: Acer Aspire One, with 8 Gb SSD

Please let me know if you have any further questions, or want the
btrfs-debug-tree output of the filesystem or something similar. I will
not be reading the list, so please e-mail me directly as well.

Also, I am wondering, how am I supposed to fix this situation? I see
conflicting info if btrfsck can be run on a mounted filesystem (I did
run it on a mounted filesystem above, as can be seen) - but is it
supposed to be able to fix this kind of corruption?

(In this case, the data on the drive is not crucial, I can fix it by
reinstalling or just copying files out and in, but that''s obviously not
good enough solution for a stable release.)

-- Naked
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, Oct 27, 2009 at 3:09 AM, Nuutti Kotivuori <naked@iki.fi>
wrote:
> Hello,
>
> I managed to get an oops and a somewhat borked btrfs filesystem after
> using btrfs-convert and then removing the image file. I will explain the
> full sequence of actions below (as I remember it):
>
>  - In the beginning, I have an ext3 filesystem that I''d like to
convert
>   to btrfs
>
>  - I run btrfs-convert on the filesystem, forgetting to do fsck before
>   it - however, I have done a full fsck recently on the filesystem, and
>   it was cleanly unmounted (no journal replay necessary)
>
>  - Conversion runs smoothly
>
>  - I boot the newly converted filesystem as a root filesystem for my
>   computer, and everything looks good. "df" reports proper free
space.
>
>  - I mount the subvolume with the ext2 filesystem under /mnt, while
>   having the btrfs main volume as my root filesystem:
>
>     mount -t btrfs -o subvol=ext2_saved /dev/mapper/perspire-root /mnt
>
>  - I remove the image file from the subvolume:
>
>     rm /mnt/image
>
>  - At this time, during or immediately after the removal, I get a
>   notification of a kernel oops, which is here:
>
>     http://www.kerneloops.org/submitresult.php?number=823167
This is a known bug in btrfs kernel driver, it''s fixed in 2.6.32-rcX.
>
>  - I unmount the subvolume:
>
>     umount /mnt
>
>  - I reboot the computer, after which I check "df":
>
>     /dev/mapper/perspire-root 7245824 -73786976294826385180 -4575460 100% /
This is a known bug in btrfs-progs 0.19, it''s fixed in
btrfs-progs-untable tree.
>
>   (Sizes in 1K-blocks, used space being the hugely negative number, and
>   available being the somewhat less huge number.)
>
>  - Btrfsck reports:
>
>     root 5 inode 453339 errors 2
>     root 5 inode 453343 errors 2
>     root 5 inode 453347 errors 2
>     root 5 inode 453356 errors 2
>     root 5 inode 466532 errors 2
>     root 5 inode 466537 errors 2
>     root 5 inode 466540 errors 2
>     root 5 inode 466544 errors 2
>     found 5867835392 bytes used err is 1
>     total csum bytes: 5477992
>     total tree bytes: 258371584
>     total fs tree bytes: 228814848
>     btree space waste bytes: 71477071
>     file data blocks allocated: 8317644800
>      referenced 5582884864
>     Btrfs Btrfs v0.19
These errors are not critical. Some inodes'' link counts are zero,
but they aren''t marked as orphan inodes. I have no idea how this
can happen. Did you run btrfsck on mounted FS?
>
>  - Otherwise the filesystem seems to be in perfect working order, no
>   problems that I can see. I have been using it for several days after
>   the incident now.
>
> Then, useful info:
>
>  - Kernel: 2.6.31-trunk-686 (debian experimental)
>  - Btrfs utilities: 0.19-5 (debian package)
>  - Hardware: Acer Aspire One, with 8 Gb SSD
>
> Please let me know if you have any further questions, or want the
> btrfs-debug-tree output of the filesystem or something similar. I will
> not be reading the list, so please e-mail me directly as well.
>
> Also, I am wondering, how am I supposed to fix this situation? I see
> conflicting info if btrfsck can be run on a mounted filesystem (I did
> run it on a mounted filesystem above, as can be seen) - but is it
> supposed to be able to fix this kind of corruption?
>
> (In this case, the data on the drive is not crucial, I can fix it by
> reinstalling or just copying files out and in, but that''s
obviously not
> good enough solution for a stable release.)
Copying files out and in is the simplest and safest solution.
Sorry for the inconvenience.

Yan, Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

"Yan, Zheng " <yanzheng@21cn.com>
writes:
> This is a known bug in btrfs kernel driver, it''s fixed in
2.6.32-rcX.
Thank you, good to know.
> This is a known bug in btrfs-progs 0.19, it''s fixed in
> btrfs-progs-untable tree.
Thank you, good to know.
> These errors are not critical. Some inodes'' link counts are zero,
> but they aren''t marked as orphan inodes. I have no idea how this
> can happen. Did you run btrfsck on mounted FS?
Yes, I did run it on a mounted FS. An earlier wiki document said that
btrfsck can be run on a mounted or an unmounted filesystem - however the
wiki said earlier that it can be run either on a mounted or an unmounted
fs. Btrfsck doesn''t complain that it''s being run on a mounted
fs... then
again, I''m not sure if it can know that.
> Copying files out and in is the simplest and safest solution.
> Sorry for the inconvenience.
No problem.

But, I am wondering, is btrfsck at some point supposed to fix this kind
of corruption? Is it on the roadmap at some point?

I mean, it''s ofcourse obvious that bugs like this are fixed at the
source, so errors like this should no longer happen. However, there will
always be bugs, or if not bugs then just the processor randomly
calculating wrong once in a blue moon, and it would be good to know that
btrfsck can fix the filesystem even in situations that "cannot"
happen. And free space accounting is probably easiest of them all.

-- Naked
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html