Nuutti Kotivuori
2009-Oct-26 19:09 UTC
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
Yan, Zheng
2009-Oct-27 02:23 UTC
Re: Oops and somewhat borked filesystem after btrfs-convert and image removal
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=823167This 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.19These 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
Nuutti Kotivuori
2009-Oct-27 08:12 UTC
Re: Oops and somewhat borked filesystem after btrfs-convert and image removal
"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