Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Mon, Aug 3, 2015 at 4:22 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote: Yes, you're right, that's a dead loop. But for better debugging, would you please upload the following info? 1) output of command btrfs-debug-tree -t 5 DEV. The only important things are info about that inode. Whose objectid(first item in a key) is 14214570 and type is one of the following: INODE_ITEM, INODE_REF, EXTENT_DATA So you may only need to cut the things like below: == item 4 key (14214570 INODE_ITEM 0) itemoff 15881 itemsize 160 inode generation 6 transid 6 size 1073741824 nbytes 1073741824 block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0 flags 0x0 item 5 key (14214570 INODE_REF XXX) itemoff 15866 itemsize 15 inode ref index 2 namelen 5 name: file1 item 6 key (14214570 EXTENT_DATA 0) itemoff 15813 itemsize 53 extent data disk byte 2176843776 nr 134217728 extent data offset 0 nr 134217728 ram 134217728 extent compression 0 item 7 key (14214570 EXTENT_DATA XXX) itemoff 15760 itemsize 53 extent data disk byte 2311061504 nr 134217728 extent data offset 0 nr 134217728 ram 134217728 extent compression 0 (All items with 14214570 objectid is needed to debug) == And it's highly recommended to only cut that part and paste it. Not only to reduce the output, but also help your privacy. As you can see, INODE_REF contains file name, which can be sometimes leaking your personal infomation. item 46 key (14214570 INODE_ITEM 0) itemoff 11902 itemsize 160 inode generation 2285 transid 2308 size 32768 nbytes 0 block group 0 mode 100644 links 1 uid 1000 gid 100 rdev 0 flags 0x10 item 47 key (14214570 INODE_REF 5506079) itemoff 11875 itemsize 27 inode ref index 300 namelen 17 name: root-0bc95412.log I double-checked and there is no EXTENT_DATA entry. 2) output of command btrfs-debug-tree -t 2 DEV Just in case your extent tree mismatch with fs tree. The gzipped log is 13MB, so I've uploaded it to https://dl.dropboxusercontent.com/u/3160732/btrfs-debug-tree-t-2.log.gz ; sha1sum is fb4c671bb90b97aa64f6d3938948100c2175e6a5 . If you don't like to execute 2 commands and are OK with leaking file/dir names, you can also use btrfs-debug-tree DEV to dump every metadata info. If the above aren't enough I will provide the more comprehensive output. Alternatively, if btrfs-image -c9 DEV works without problem, it will also helps a lot for debugging. This one is also quite large ( 332MB ) - https://dl.dropboxusercontent.com/u/3160732/sda1-btrfs-image-c9.img ; sha1sum is c243e127a317f69faa5548993914a678f6f79524. Thanks, Robert -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Thanks for the log.
I'll investigate it to see whether we can resolve the infinite loop problem.
Thanks,
Qu
Robert Munteanu wrote on 2015/07/31 16:38 +0300:
On Fri, Jul 31, 2015 at 5:08 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Any full output about it?
Please see the attached log. I left the process running for about 4
hours, and after the first five minutes all it cared about was a
single inode. I ended up stopping it as it looks like it's not making
progress.
Not sure if it real loops, but maybe the inode number changed in later
output?
Looks to me like it's the same inode
$ awk '/ for inode/ { print $7 } ' screenlog.0 | sort | uniq
14214570
Thanks,
Robert
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Yes, you're right, that's a dead loop.
But for better debugging, would you please upload the following info?
1) output of command btrfs-debug-tree -t 5 DEV.
The only important things are info about that inode.
Whose objectid(first item in a key) is 14214570 and type is one of the
following:
INODE_ITEM, INODE_REF, EXTENT_DATA
So you may only need to cut the things like below:
==
item 4 key (14214570 INODE_ITEM 0) itemoff 15881 itemsize 160
inode generation 6 transid 6 size 1073741824 nbytes
1073741824
block group 0 mode 100644 links 1 uid 0 gid 0
rdev 0 flags 0x0
item 5 key (14214570 INODE_REF XXX) itemoff 15866 itemsize 15
inode ref index 2 namelen 5 name: file1
item 6 key (14214570 EXTENT_DATA 0) itemoff 15813 itemsize 53
extent data disk byte 2176843776 nr 134217728
extent data offset 0 nr 134217728 ram 134217728
extent compression 0
item 7 key (14214570 EXTENT_DATA XXX) itemoff 15760 itemsize 53
extent data disk byte 2311061504 nr 134217728
extent data offset 0 nr 134217728 ram 134217728
extent compression 0
(All items with 14214570 objectid is needed to debug)
==
And it's highly recommended to only cut that part and paste it.
Not only to reduce the output, but also help your privacy.
As you can see, INODE_REF contains file name, which can be sometimes
leaking your personal infomation.
2) output of command btrfs-debug-tree -t 2 DEV
Just in case your extent tree mismatch with fs tree.
If you don't like to execute 2 commands and are OK with leaking file/dir
names, you can also use btrfs-debug-tree DEV to dump every metadata
info.
Alternatively, if btrfs-image -c9 DEV works without problem, it will
also helps a lot for debugging.
Thanks,
Qu
Robert Munteanu wrote on 2015/07/31 16:38 +0300:
On Fri, Jul 31, 2015 at 5:08 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Any full output about it?
Please see the attached log. I left the process running for about 4
hours, and after the first five minutes all it cared about was a
single inode. I ended up stopping it as it looks like it's not making
progress.
Not sure if it real loops, but maybe the inode number changed in later
output?
Looks to me like it's the same inode
$ awk '/ for inode/ { print $7 } ' screenlog.0 | sort | uniq
14214570
Thanks,
Robert
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Fri, Jul 31, 2015 at 5:08 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote:
Any full output about it?
Please see the attached log. I left the process running for about 4
hours, and after the first five minutes all it cared about was a
single inode. I ended up stopping it as it looks like it's not making
progress.
Not sure if it real loops, but maybe the inode number changed in later
output?
Looks to me like it's the same inode
$ awk '/ for inode/ { print $7 } ' screenlog.0 | sort | uniq
14214570
Thanks,
Robert
--
http://robert.muntea.nu/
screenlog.0.gz
Description: GNU Zip compressed data
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
The disk image (still) contains sensitive data so I can't share it unfortunately. What I can do is keep it untouched until Friday evening EEST and run any debugging commands that you might think of to trace down the source of the errors. Alternatively, if there's an easy and safe fix and debugging is not worth it, I'm happy to apply that fix as well. Based on the results of running btrfs check --repair on an image file taken from the actual disk I ran a btrfs check --repair on the physical partition The output was ( again, re-typed so might contain typos ) # btfrs check --repair /dev/sda1 enabling repair mode repair mode will force to clear out log tree, Are you sure [y/N]: y Checking filesystem on /dev/sda1 UUID: ... checking extents Fixed 0 roots. checking free space cache. cache and super generation don't match, space cache will be invalidated checking fs roots Fixed discount file extends for inode: 14214570 in root: 5 root 5 inode 14214570 errors 100, file extend discount Found file extent holes: Fixed discount file extends for inode: 14214570 in root: 5 root 5 inode 14214570 errors 100, file extend discount Found file extent holes: The previous 3 lines repeat a lot, every 10 seconds maybe. After 30 minutes I got bored and stopped the process, as it looks like it's looping at some condition that without making any progress. At any rate, something worked well and I can now mount the volume again from the rescue disk and boot from a read-only snapshot. Cheers, Robert -- http://robert.muntea.nu/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Robert Munteanu wrote on 2015/07/30 16:16 +0300: The disk image (still) contains sensitive data so I can't share it unfortunately. What I can do is keep it untouched until Friday evening EEST and run any debugging commands that you might think of to trace down the source of the errors. Alternatively, if there's an easy and safe fix and debugging is not worth it, I'm happy to apply that fix as well. Based on the results of running btrfs check --repair on an image file taken from the actual disk I ran a btrfs check --repair on the physical partition The output was ( again, re-typed so might contain typos ) # btfrs check --repair /dev/sda1 enabling repair mode repair mode will force to clear out log tree, Are you sure [y/N]: y Checking filesystem on /dev/sda1 UUID: ... checking extents Fixed 0 roots. checking free space cache. cache and super generation don't match, space cache will be invalidated checking fs roots Fixed discount file extends for inode: 14214570 in root: 5 root 5 inode 14214570 errors 100, file extend discount Found file extent holes: Fixed discount file extends for inode: 14214570 in root: 5 root 5 inode 14214570 errors 100, file extend discount Found file extent holes: Any full output about it? Not sure if it real loops, but maybe the inode number changed in later output? Thanks, Qu The previous 3 lines repeat a lot, every 10 seconds maybe. After 30 minutes I got bored and stopped the process, as it looks like it's looping at some condition that without making any progress. At any rate, something worked well and I can now mount the volume again from the rescue disk and boot from a read-only snapshot. Cheers, Robert -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Fri, Jul 10, 2015 at 3:34 AM, Qu Wenruo quwen...@cn.fujitsu.com wrote: One of my patch addressed a problem that a converted btrfs can't pass btrfsck. Not sure if that is the cause, but if you can try btrfs-progs v3.19.1, the one without my btrfs-progs patches and some other newer convert related patches, and see the result? I think this would at least provide the base for bisect the btrfs-progs if the bug is in btrfs-progs. Unfortunately, even though I had the original image saved, I was unable to restore it ; I went on with btrfs fi defrag and btrfs balance before realising that there was an issue. And that issue hid itself for quite some time ( I thought I had avoided it by using a different /home partition ) and appeared at the worst possible time - when doing a system update ( zypper dup ). The system became read-only and I rebooted to Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Trying to boot an older snapshot ( I use snapper ) shows a more explicit error BTRFS: error (device sda1) in btrfs_replay_log:2334: errno=-95 unknown (Failed to recover log tree) BTRFS: open_ctree failed Running $ btrfs check /dev/sda1 yields the following output ( note that I'm typing this as I see it on the screen, some typos might occur ): Checking filesystem on /dev/sda1 UUID: checking extents checking free space cache checking fs roots root 5 inode 14214570 errors 100, file extent discount Found file extent holes: root 497 inode 14214570 errors 100, file extent discount Found file extent holes: root 689 inode 14214570 errors 100, file extent discount Found file extent holes: root 732 inode 14214570 errors 100, file extent discount Found file extent holes: root 733 inode 14214570 errors 100, file extent discount Found file extent holes: root 734 inode 14214570 errors 100, file extent discount Found file extent holes: root 762 inode 14214570 errors 100, file extent discount Found file extent holes: root 1184 inode 14214570 errors 100, file extent discount Found file extent holes: found 110778231275 bytes used err is 1 total csum bytes: 104238064 total tree byes: 4047454208 total fs tree bytes: 3849125888 total extend tree bytes: 76496896 btree space waste bytes: 907307515 file data blocks allocated: 642367569920 referenced 211828183040 btrfs-progs v4.1+20150622 Also, $(uname -r) is 4.1.1-1-desktop The disk image (still) contains sensitive data so I can't share it unfortunately. What I can do is keep it untouched until Friday evening EEST and run any debugging commands that you might think of to trace down the source of the errors. Alternatively, if there's an easy and safe fix and debugging is not worth it, I'm happy to apply that fix as well. At any rate, looking forward to your replies. Thanks, Robert -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Thu, Jul 9, 2015 at 10:45 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote: Chris Murphy wrote on 2015/07/09 18:45 -0600: On Thu, Jul 9, 2015 at 6:34 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote: One of my patch addressed a problem that a converted btrfs can't pass btrfsck. Not sure if that is the cause, but if you can try btrfs-progs v3.19.1, the one without my btrfs-progs patches and some other newer convert related patches, and see the result? I think this would at least provide the base for bisect the btrfs-progs if the bug is in btrfs-progs. I'm happy to regression test with 3.19.1 but I'm confused. After conversion, btrfs check (4.1) finds no problems. After ext2_saved snapshot is deleted, btrfsck finds no problems. After defrag, again btrfsck finds no problems. After the failed balance, btrfsck finds no problems but crashes with Aborted (core dump). Even btrfsck reports no error, some btrfs-convert behavior change may lead to kernel mis-function. But we are not sure it's btrfs-progs or kernel itself has bug. Maybe btrfs convert did something wrong/different triggering the bug, or just kernel regression? So hat I'd like to check is, with 3.19.1 progs (kernel version doesn't change), whether the kernel still failes to do balance. If the problem still happens, then we can focus on kernel part, or at least, put at least less effort on btrfs-progs. Should I still test 3.19.1? I'm not able to reproduce this for reasons I don't understand. The setup is in a qemu-kvm VM, with the ext4 original as a qcow2. I had been using 'qemu-img create -f qcow2 -o nocow=on -b original.qcow2 converted qcow2' and then doing the conversions with the converted.qcow2 file in the VM. I did this half a dozen times and always at the balance step it imploded (but differently for 4.1 and 4.2). Now the balance completes with no errors. btrfs check doesn't complaint either. Very irritating as nothing else has changed with that VM. There is another user who had this similar problem with the converted ext4 going read-only. They ran btrfs check with both 3.19.1 and 4.0. Their results are here, hopefully it's helpful until I can figure out how to get this reproducing again. http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg44701.html -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Chris Murphy wrote on 2015/07/09 18:45 -0600: On Thu, Jul 9, 2015 at 6:34 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote: One of my patch addressed a problem that a converted btrfs can't pass btrfsck. Not sure if that is the cause, but if you can try btrfs-progs v3.19.1, the one without my btrfs-progs patches and some other newer convert related patches, and see the result? I think this would at least provide the base for bisect the btrfs-progs if the bug is in btrfs-progs. I'm happy to regression test with 3.19.1 but I'm confused. After conversion, btrfs check (4.1) finds no problems. After ext2_saved snapshot is deleted, btrfsck finds no problems. After defrag, again btrfsck finds no problems. After the failed balance, btrfsck finds no problems but crashes with Aborted (core dump). Even btrfsck reports no error, some btrfs-convert behavior change may lead to kernel mis-function. But we are not sure it's btrfs-progs or kernel itself has bug. Maybe btrfs convert did something wrong/different triggering the bug, or just kernel regression? So hat I'd like to check is, with 3.19.1 progs (kernel version doesn't change), whether the kernel still failes to do balance. If the problem still happens, then we can focus on kernel part, or at least, put at least less effort on btrfs-progs. Should I still test 3.19.1? Yes, please. Thanks, Qu -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Thu, Jul 9, 2015 at 6:34 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote: One of my patch addressed a problem that a converted btrfs can't pass btrfsck. Not sure if that is the cause, but if you can try btrfs-progs v3.19.1, the one without my btrfs-progs patches and some other newer convert related patches, and see the result? I think this would at least provide the base for bisect the btrfs-progs if the bug is in btrfs-progs. I'm happy to regression test with 3.19.1 but I'm confused. After conversion, btrfs check (4.1) finds no problems. After ext2_saved snapshot is deleted, btrfsck finds no problems. After defrag, again btrfsck finds no problems. After the failed balance, btrfsck finds no problems but crashes with Aborted (core dump). Should I still test 3.19.1? -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Slightly off topic does these bugs exist in systems that converted from ext4 to btrfs using kernel 3.13 and then upgraded to kernel 4.1 ? On Thu, Jul 9, 2015 at 4:09 AM, Chris Murphy li...@colorremedies.com wrote: On Thu, Jun 25, 2015 at 8:08 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote: A quite code search leads me to inline extent. So, if you still have the original ext* image, would you please try revert to ext* and then convert it to btrfs again? But this time, please convert with --no-inline option, and see if this remove the problem. Using -n at convert time does not make a difference for the btrfs-convert bugs I've opened: https://bugzilla.kernel.org/show_bug.cgi?id=101191 https://bugzilla.kernel.org/show_bug.cgi?id=101181 https://bugzilla.kernel.org/show_bug.cgi?id=101221 https://bugzilla.kernel.org/show_bug.cgi?id=101231 The last one I just discovered happens much sooner, is easier to reproduce than the other two. It's a scrub right after a successful btrfs-convert that btrfs check says is OK. But the scrub ends with two separate oopses and multiple call traces and a spectacularly hard kernic panic (ssh and even the console dies). So I think btrfs-convert has a bug, but then the kernel code is not gracefully handling it at all either and crashes badly with a scrub; and less badly with balance. However, the file system is still OK despite scrub crash. With balance failure, the file system is too badly damaged and btrfs check and btrfs-image fail. -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Thu, Jul 9, 2015 at 4:52 AM, Vytautas D vyt...@gmail.com wrote: Slightly off topic does these bugs exist in systems that converted from ext4 to btrfs using kernel 3.13 and then upgraded to kernel 4.1 ? I don't recall what btrfs-progs and kernel I last tested ext4 conversion with. I know this is a regression, I just don't know how old it is. I think there's more than one bug here (obviously since I've filed 4 related bugs in ~24 hours), but I really don't know the scope of the problem. But the case where the recommended procedure not only fails but corrupts the file system and it can't be fixed or rolled back, is not good. Perhaps the wiki should provide a warning that this is currently broken, status unknown, or something? -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
One of my patch addressed a problem that a converted btrfs can't pass btrfsck. Not sure if that is the cause, but if you can try btrfs-progs v3.19.1, the one without my btrfs-progs patches and some other newer convert related patches, and see the result? I think this would at least provide the base for bisect the btrfs-progs if the bug is in btrfs-progs. Thanks, Qu Chris Murphy wrote on 2015/07/09 15:38 -0600: On Thu, Jul 9, 2015 at 4:52 AM, Vytautas D vyt...@gmail.com wrote: Slightly off topic does these bugs exist in systems that converted from ext4 to btrfs using kernel 3.13 and then upgraded to kernel 4.1 ? I don't recall what btrfs-progs and kernel I last tested ext4 conversion with. I know this is a regression, I just don't know how old it is. I think there's more than one bug here (obviously since I've filed 4 related bugs in ~24 hours), but I really don't know the scope of the problem. But the case where the recommended procedure not only fails but corrupts the file system and it can't be fixed or rolled back, is not good. Perhaps the wiki should provide a warning that this is currently broken, status unknown, or something? -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Thu, Jun 25, 2015 at 8:08 PM, Qu Wenruo quwen...@cn.fujitsu.com wrote: A quite code search leads me to inline extent. So, if you still have the original ext* image, would you please try revert to ext* and then convert it to btrfs again? But this time, please convert with --no-inline option, and see if this remove the problem. Using -n at convert time does not make a difference for the btrfs-convert bugs I've opened: https://bugzilla.kernel.org/show_bug.cgi?id=101191 https://bugzilla.kernel.org/show_bug.cgi?id=101181 https://bugzilla.kernel.org/show_bug.cgi?id=101221 https://bugzilla.kernel.org/show_bug.cgi?id=101231 The last one I just discovered happens much sooner, is easier to reproduce than the other two. It's a scrub right after a successful btrfs-convert that btrfs check says is OK. But the scrub ends with two separate oopses and multiple call traces and a spectacularly hard kernic panic (ssh and even the console dies). So I think btrfs-convert has a bug, but then the kernel code is not gracefully handling it at all either and crashes badly with a scrub; and less badly with balance. However, the file system is still OK despite scrub crash. With balance failure, the file system is too badly damaged and btrfs check and btrfs-image fail. -- Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
That's unfortunate. Many users, including me, started using btrfs by
converting from ext4. I hope this gets fixed.
Vytas
On Thu, Jun 25, 2015 at 5:16 AM, Marc MERLIN m...@merlins.org wrote:
On Thu, Jun 18, 2015 at 02:05:04PM +0300, Robert Munteanu wrote:
On Wed, Jun 17, 2015 at 8:46 PM, Marc MERLIN m...@merlins.org wrote:
On Fri, Jun 12, 2015 at 03:19:06PM +0300, Robert Munteanu wrote:
Hi,
Note to others: kernel 4.0.4
Reply to you:
I tried ext4 to btrfs once a year ago and it severely mangled my
filesystem.
I looked at it as a cool feature/hack that may have worked some time ago,
but
that no one really uses anymore, and that may not work right at this
point.
Unless you hear back from a developer interested in debugging/fixing
this, I would assume that this feature is broken and dead.
I did hear, but in case the general consensus is that this feature is
broken/experimental/unsafe, it would be great to mention it in the
wiki page.
Done
https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3
Marc
--
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems
what McDonalds is to gourmet
cooking
Home page: http://marc.merlins.org/ | PGP
1024R/763BE901
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Thu, Jun 25, 2015 at 08:17:12PM +, Ruslanas Gžibovskis wrote: nope. started from scratch! never upgrade from old running fs. Better to move 1 file and extend , move another files, extend and so on then just convert... It's like moving from windows and only boot partition to have on ext2 and other system on ntfs... all my friends do the same. And by the way does anyone still use ext3/4? isn't it dead? Even rhel now goes with default xfs... Yes, plenty of people use ext4, it's not dead :) It also just added built in encryption in the filesystem, which no other filesystem has AFAIK. Due to how btrfs works with block layouts, it shouldn't be hard to encrypt blocks as they are written just like they can be compressed currently, but no one has sponsored that work yet. Because Google uses ext4 and they (we) care about encrypting data to protect user data from things like possible hardware theft or maybe even a datacenter being raided in some country, that's how ext4 got encryption built in. Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Qu Wenruo wrote on 2015/06/26 09:54 +0800: Robert Munteanu wrote on 2015/06/12 15:19 +0300: Hi, I have converted my root ext4 partition to btrfs. I used an USB stick to boot and used btrfs-convert. I also did a balance and defrag ( in that order ) , both when the fs was mounted. After logging in to KDE I quickly get a read-only filesystem. I've pasted the backtrace below Jun 11 23:13:08 mars kernel: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120 [btrfs]() Jun 11 23:13:08 mars kernel: BTRFS: Transaction aborted (error -95) Jun 11 23:13:08 mars kernel: Modules linked in: bnep bluetooth rfkill fuse vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) af_packet nf_log_ipv6 xt_pkttype nf_log_ip v4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_con ntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c snd_hda _codec_hdmi raid1 md_mod gpio_ich ppdev iTCO_wdt iTCO_vendor_support coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel snd_hda_intel dm_mod kvm snd_hda_co ntroller snd_hda_codec snd_hwdep serio_raw pcspkr snd_pcm i2c_i801 snd_seq joydev snd_seq_device snd_timer snd 8250_fintek parport_pc parport acpi_cpufreq lpc_ich Jun 11 23:13:08 mars kernel: soundcore mfd_core shpchp processor ata_generic btrfs hid_logitech_hidpp xor raid6_pq sr_mod cdrom nvidia_uvm(PO) nvidia(PO) firewire_ohc i firewire_core crc_itu_t uas usb_storage r8169 mii pata_jmicron hid_logitech_dj drm button sg Jun 11 23:13:08 mars kernel: CPU: 2 PID: 2777 Comm: kworker/u8:0 Tainted: P O4.0.4-3-desktop #1 Jun 11 23:13:08 mars kernel: Hardware name: Gigabyte Technology Co., Ltd. EP35-DS4/EP35-DS4, BIOS F6d 01/08/2009 Jun 11 23:13:08 mars kernel: Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] Jun 11 23:13:08 mars kernel: a0a92832 8167c4aa 880128513ca8 Jun 11 23:13:08 mars kernel: 81063bb1 880031929d28 880221e71800 ffa1 Jun 11 23:13:08 mars kernel: a0a914e0 0b50 81063c2a a0a95928 Jun 11 23:13:08 mars kernel: Call Trace: Jun 11 23:13:08 mars kernel: [8100574c] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars kernel: [81005aa3] show_stack_log_lvl+0xa3/0x190 Jun 11 23:13:08 mars kernel: [81007201] show_stack+0x21/0x50 Jun 11 23:13:08 mars kernel: [8167c4aa] dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel: [81063bb1] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08 mars kernel: [81063c2a] warn_slowpath_fmt+0x4a/0x50 Jun 11 23:13:08 mars kernel: [a09e598b] __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars kernel: [a0a1d18a] btrfs_finish_ordered_io+0x5aa/0x620 [btrfs] Jun 11 23:13:08 mars kernel: [a0a43253] normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel: [8107bcf2] process_one_work+0x142/0x420 Jun 11 23:13:08 mars kernel: [8107c0e4] worker_thread+0x114/0x460 Jun 11 23:13:08 mars kernel: [81081261] kthread+0xc1/0xe0 Jun 11 23:13:08 mars kernel: [81682d58] ret_from_fork+0x58/0x90 Jun 11 23:13:08 mars kernel: ---[ end trace 4c4eb7d6e98afa91 ]--- Jun 11 23:13:08 mars kernel: BTRFS: error (device sda1) in btrfs_finish_ordered_io:2896: errno=-95 unknown IIRC some one in the mail-list has reported the same bug. Still not sure the root cause but seems highly related to converted fs. It would be much better if you have a clue to trigger the bug. Like read/write which file(s) may cause the bug. If it's OK for you, please upload the btrfs-debug-tree output. WARNING: This output will not contain any data but all your filename/dir name. My first guess is some btrfs codes can't handle the special extent converted from ext* well, but still quite hard to say even the errno(EOPNOTSUPP) is quite unique and easy to find the source :( Thanks, Qu A quite code search leads me to inline extent. So, if you still have the original ext* image, would you please try revert to ext* and then convert it to btrfs again? But this time, please convert with --no-inline option, and see if this remove the problem. Thanks, Qu Jun 11 23:13:08 mars kernel: BTRFS info (device sda1): forced readonly Some diagnostic info: - btrfs scrub reports no errors - on the host machine I'm running btrfs v4.0+20150429 and kernel 4.0.4-3-desktop - on the live medium, used to run btrfs-convert, I was running btrfs v4.0+20150429 and kernel 4.0.3-1-default # btrfs fi show Label: none uuid: 54dea125-74cd-4bb2-86a2-f7bc645b76cf Total devices 1 FS bytes used 90.22GiB devid1 size 223.57GiB used 92.03GiB path /dev/sda1 btrfs-progs v4.0+20150429 # btrfs fi df / Data, single: total=89.00GiB, used=88.17GiB System,
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Robert Munteanu wrote on 2015/06/12 15:19 +0300: Hi, I have converted my root ext4 partition to btrfs. I used an USB stick to boot and used btrfs-convert. I also did a balance and defrag ( in that order ) , both when the fs was mounted. After logging in to KDE I quickly get a read-only filesystem. I've pasted the backtrace below Jun 11 23:13:08 mars kernel: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120 [btrfs]() Jun 11 23:13:08 mars kernel: BTRFS: Transaction aborted (error -95) Jun 11 23:13:08 mars kernel: Modules linked in: bnep bluetooth rfkill fuse vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) af_packet nf_log_ipv6 xt_pkttype nf_log_ip v4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_con ntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c snd_hda _codec_hdmi raid1 md_mod gpio_ich ppdev iTCO_wdt iTCO_vendor_support coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel snd_hda_intel dm_mod kvm snd_hda_co ntroller snd_hda_codec snd_hwdep serio_raw pcspkr snd_pcm i2c_i801 snd_seq joydev snd_seq_device snd_timer snd 8250_fintek parport_pc parport acpi_cpufreq lpc_ich Jun 11 23:13:08 mars kernel: soundcore mfd_core shpchp processor ata_generic btrfs hid_logitech_hidpp xor raid6_pq sr_mod cdrom nvidia_uvm(PO) nvidia(PO) firewire_ohc i firewire_core crc_itu_t uas usb_storage r8169 mii pata_jmicron hid_logitech_dj drm button sg Jun 11 23:13:08 mars kernel: CPU: 2 PID: 2777 Comm: kworker/u8:0 Tainted: P O4.0.4-3-desktop #1 Jun 11 23:13:08 mars kernel: Hardware name: Gigabyte Technology Co., Ltd. EP35-DS4/EP35-DS4, BIOS F6d 01/08/2009 Jun 11 23:13:08 mars kernel: Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] Jun 11 23:13:08 mars kernel: a0a92832 8167c4aa 880128513ca8 Jun 11 23:13:08 mars kernel: 81063bb1 880031929d28 880221e71800 ffa1 Jun 11 23:13:08 mars kernel: a0a914e0 0b50 81063c2a a0a95928 Jun 11 23:13:08 mars kernel: Call Trace: Jun 11 23:13:08 mars kernel: [8100574c] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars kernel: [81005aa3] show_stack_log_lvl+0xa3/0x190 Jun 11 23:13:08 mars kernel: [81007201] show_stack+0x21/0x50 Jun 11 23:13:08 mars kernel: [8167c4aa] dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel: [81063bb1] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08 mars kernel: [81063c2a] warn_slowpath_fmt+0x4a/0x50 Jun 11 23:13:08 mars kernel: [a09e598b] __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars kernel: [a0a1d18a] btrfs_finish_ordered_io+0x5aa/0x620 [btrfs] Jun 11 23:13:08 mars kernel: [a0a43253] normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel: [8107bcf2] process_one_work+0x142/0x420 Jun 11 23:13:08 mars kernel: [8107c0e4] worker_thread+0x114/0x460 Jun 11 23:13:08 mars kernel: [81081261] kthread+0xc1/0xe0 Jun 11 23:13:08 mars kernel: [81682d58] ret_from_fork+0x58/0x90 Jun 11 23:13:08 mars kernel: ---[ end trace 4c4eb7d6e98afa91 ]--- Jun 11 23:13:08 mars kernel: BTRFS: error (device sda1) in btrfs_finish_ordered_io:2896: errno=-95 unknown IIRC some one in the mail-list has reported the same bug. Still not sure the root cause but seems highly related to converted fs. It would be much better if you have a clue to trigger the bug. Like read/write which file(s) may cause the bug. If it's OK for you, please upload the btrfs-debug-tree output. WARNING: This output will not contain any data but all your filename/dir name. My first guess is some btrfs codes can't handle the special extent converted from ext* well, but still quite hard to say even the errno(EOPNOTSUPP) is quite unique and easy to find the source :( Thanks, Qu Jun 11 23:13:08 mars kernel: BTRFS info (device sda1): forced readonly Some diagnostic info: - btrfs scrub reports no errors - on the host machine I'm running btrfs v4.0+20150429 and kernel 4.0.4-3-desktop - on the live medium, used to run btrfs-convert, I was running btrfs v4.0+20150429 and kernel 4.0.3-1-default # btrfs fi show Label: none uuid: 54dea125-74cd-4bb2-86a2-f7bc645b76cf Total devices 1 FS bytes used 90.22GiB devid1 size 223.57GiB used 92.03GiB path /dev/sda1 btrfs-progs v4.0+20150429 # btrfs fi df / Data, single: total=89.00GiB, used=88.17GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=3.00GiB, used=2.05GiB GlobalReserve, single: total=512.00MiB, used=0.00B Is there a way out? I still have the old ext4 image and can revert, but I'm keeping the btrfs one for now, in case I can extract some useful debugging information from it. Thanks,
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Thu, Jun 18, 2015 at 02:05:04PM +0300, Robert Munteanu wrote: On Wed, Jun 17, 2015 at 8:46 PM, Marc MERLIN m...@merlins.org wrote: On Fri, Jun 12, 2015 at 03:19:06PM +0300, Robert Munteanu wrote: Hi, Note to others: kernel 4.0.4 Reply to you: I tried ext4 to btrfs once a year ago and it severely mangled my filesystem. I looked at it as a cool feature/hack that may have worked some time ago, but that no one really uses anymore, and that may not work right at this point. Unless you hear back from a developer interested in debugging/fixing this, I would assume that this feature is broken and dead. I did hear, but in case the general consensus is that this feature is broken/experimental/unsafe, it would be great to mention it in the wiki page. Done https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3 Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | PGP 1024R/763BE901 -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Wed, Jun 17, 2015 at 9:48 PM, Jeff Mahoney je...@suse.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/12/15 8:19 AM, Robert Munteanu wrote: Hi, I have converted my root ext4 partition to btrfs. I used an USB stick to boot and used btrfs-convert. I also did a balance and defrag ( in that order ) , both when the fs was mounted. After logging in to KDE I quickly get a read-only filesystem. I've pasted the backtrace below Jun 11 23:13:08 mars kernel: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120 [btrfs]() Jun 11 23:13:08 mars kernel: BTRFS: Transaction aborted (error -95) Jun 11 23:13:08 mars kernel: Modules linked in: bnep bluetooth rfkill fuse vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) af_packet nf_log_ipv6 xt_pkttype nf_log_ip v4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_con ntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c snd_hda _codec_hdmi raid1 md_mod gpio_ich ppdev iTCO_wdt iTCO_vendor_support coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel snd_hda_intel dm_mod kvm snd_hda_co ntroller snd_hda_codec snd_hwdep serio_raw pcspkr snd_pcm i2c_i801 snd_seq joydev snd_seq_device snd_timer snd 8250_fintek parport_pc parport acpi_cpufreq lpc_ich Jun 11 23:13:08 mars kernel: soundcore mfd_core shpchp processor ata_generic btrfs hid_logitech_hidpp xor raid6_pq sr_mod cdrom nvidia_uvm(PO) nvidia(PO) firewire_ohc i firewire_core crc_itu_t uas usb_storage r8169 mii pata_jmicron hid_logitech_dj drm button sg Jun 11 23:13:08 mars kernel: CPU: 2 PID: 2777 Comm: kworker/u8:0 Tainted: P O4.0.4-3-desktop #1 openSUSE Tumbleweed, I take it? Yes. Also reported at https://bugzilla.opensuse.org/show_bug.cgi?id=934464 . We still actively support btrfs-convert through SLES, so we're invested in ensuring it continues working properly. I'd be interested in seeing images of both filesystems to investigate and to see if we can reproduce it. Errno -95 is -EOPNOTSUPP which is kind of strange to see. I can see a few possible places it would get passed up with a trace like that but being able to reproduce it would be extremely helpfu l. In the meantime I got bored and 'fixed' it ( I think ) . The fix involved copying the /home tree to a different ( xfs ) partition, and now the error does not appear anymore. However, I still have the old tree in the btrfs partition ( as /home2 ). I will try and reproduce the issue there and submit a reduced image which triggers the error. Unfortunately I no longer have the old ext4 partition image. Thanks, Robert - -Jeff Jun 11 23:13:08 mars kernel: Hardware name: Gigabyte Technology Co., Ltd. EP35-DS4/EP35-DS4, BIOS F6d 01/08/2009 Jun 11 23:13:08 mars kernel: Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] Jun 11 23:13:08 mars kernel: a0a92832 8167c4aa 880128513ca8 Jun 11 23:13:08 mars kernel: 81063bb1 880031929d28 880221e71800 ffa1 Jun 11 23:13:08 mars kernel: a0a914e0 0b50 81063c2a a0a95928 Jun 11 23:13:08 mars kernel: Call Trace: Jun 11 23:13:08 mars kernel: [8100574c] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars kernel: [81005aa3] show_stack_log_lvl+0xa3/0x190 Jun 11 23:13:08 mars kernel: [81007201] show_stack+0x21/0x50 Jun 11 23:13:08 mars kernel: [8167c4aa] dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel: [81063bb1] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08 mars kernel: [81063c2a] warn_slowpath_fmt+0x4a/0x50 Jun 11 23:13:08 mars kernel: [a09e598b] __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars kernel: [a0a1d18a] btrfs_finish_ordered_io+0x5aa/0x620 [btrfs] Jun 11 23:13:08 mars kernel: [a0a43253] normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel: [8107bcf2] process_one_work+0x142/0x420 Jun 11 23:13:08 mars kernel: [8107c0e4] worker_thread+0x114/0x460 Jun 11 23:13:08 mars kernel: [81081261] kthread+0xc1/0xe0 Jun 11 23:13:08 mars kernel: [81682d58] ret_from_fork+0x58/0x90 Jun 11 23:13:08 mars kernel: ---[ end trace 4c4eb7d6e98afa91 ]--- Jun 11 23:13:08 mars kernel: BTRFS: error (device sda1) in btrfs_finish_ordered_io:2896: errno=-95 unknown Jun 11 23:13:08 mars kernel: BTRFS info (device sda1): forced readonly Some diagnostic info: - btrfs scrub reports no errors - on the host machine I'm running btrfs v4.0+20150429 and kernel 4.0.4-3-desktop - on the live medium, used to run btrfs-convert, I was running btrfs v4.0+20150429 and kernel 4.0.3-1-default # btrfs fi show Label: none uuid:
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Wed, Jun 17, 2015 at 8:46 PM, Marc MERLIN m...@merlins.org wrote: On Fri, Jun 12, 2015 at 03:19:06PM +0300, Robert Munteanu wrote: Hi, Note to others: kernel 4.0.4 Reply to you: I tried ext4 to btrfs once a year ago and it severely mangled my filesystem. I looked at it as a cool feature/hack that may have worked some time ago, but that no one really uses anymore, and that may not work right at this point. Unless you hear back from a developer interested in debugging/fixing this, I would assume that this feature is broken and dead. I did hear, but in case the general consensus is that this feature is broken/experimental/unsafe, it would be great to mention it in the wiki page. Thanks, Robert Marc I have converted my root ext4 partition to btrfs. I used an USB stick to boot and used btrfs-convert. I also did a balance and defrag ( in that order ) , both when the fs was mounted. After logging in to KDE I quickly get a read-only filesystem. I've pasted the backtrace below Jun 11 23:13:08 mars kernel: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120 [btrfs]() Jun 11 23:13:08 mars kernel: BTRFS: Transaction aborted (error -95) Jun 11 23:13:08 mars kernel: Modules linked in: bnep bluetooth rfkill fuse vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) af_packet nf_log_ipv6 xt_pkttype nf_log_ip v4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_con ntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c snd_hda _codec_hdmi raid1 md_mod gpio_ich ppdev iTCO_wdt iTCO_vendor_support coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel snd_hda_intel dm_mod kvm snd_hda_co ntroller snd_hda_codec snd_hwdep serio_raw pcspkr snd_pcm i2c_i801 snd_seq joydev snd_seq_device snd_timer snd 8250_fintek parport_pc parport acpi_cpufreq lpc_ich Jun 11 23:13:08 mars kernel: soundcore mfd_core shpchp processor ata_generic btrfs hid_logitech_hidpp xor raid6_pq sr_mod cdrom nvidia_uvm(PO) nvidia(PO) firewire_ohc i firewire_core crc_itu_t uas usb_storage r8169 mii pata_jmicron hid_logitech_dj drm button sg Jun 11 23:13:08 mars kernel: CPU: 2 PID: 2777 Comm: kworker/u8:0 Tainted: P O4.0.4-3-desktop #1 Jun 11 23:13:08 mars kernel: Hardware name: Gigabyte Technology Co., Ltd. EP35-DS4/EP35-DS4, BIOS F6d 01/08/2009 Jun 11 23:13:08 mars kernel: Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] Jun 11 23:13:08 mars kernel: a0a92832 8167c4aa 880128513ca8 Jun 11 23:13:08 mars kernel: 81063bb1 880031929d28 880221e71800 ffa1 Jun 11 23:13:08 mars kernel: a0a914e0 0b50 81063c2a a0a95928 Jun 11 23:13:08 mars kernel: Call Trace: Jun 11 23:13:08 mars kernel: [8100574c] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars kernel: [81005aa3] show_stack_log_lvl+0xa3/0x190 Jun 11 23:13:08 mars kernel: [81007201] show_stack+0x21/0x50 Jun 11 23:13:08 mars kernel: [8167c4aa] dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel: [81063bb1] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08 mars kernel: [81063c2a] warn_slowpath_fmt+0x4a/0x50 Jun 11 23:13:08 mars kernel: [a09e598b] __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars kernel: [a0a1d18a] btrfs_finish_ordered_io+0x5aa/0x620 [btrfs] Jun 11 23:13:08 mars kernel: [a0a43253] normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel: [8107bcf2] process_one_work+0x142/0x420 Jun 11 23:13:08 mars kernel: [8107c0e4] worker_thread+0x114/0x460 Jun 11 23:13:08 mars kernel: [81081261] kthread+0xc1/0xe0 Jun 11 23:13:08 mars kernel: [81682d58] ret_from_fork+0x58/0x90 Jun 11 23:13:08 mars kernel: ---[ end trace 4c4eb7d6e98afa91 ]--- Jun 11 23:13:08 mars kernel: BTRFS: error (device sda1) in btrfs_finish_ordered_io:2896: errno=-95 unknown Jun 11 23:13:08 mars kernel: BTRFS info (device sda1): forced readonly Some diagnostic info: - btrfs scrub reports no errors - on the host machine I'm running btrfs v4.0+20150429 and kernel 4.0.4-3-desktop - on the live medium, used to run btrfs-convert, I was running btrfs v4.0+20150429 and kernel 4.0.3-1-default # btrfs fi show Label: none uuid: 54dea125-74cd-4bb2-86a2-f7bc645b76cf Total devices 1 FS bytes used 90.22GiB devid1 size 223.57GiB used 92.03GiB path /dev/sda1 btrfs-progs v4.0+20150429 # btrfs fi df / Data, single: total=89.00GiB, used=88.17GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=3.00GiB, used=2.05GiB GlobalReserve, single: total=512.00MiB, used=0.00B Is there a way out? I still have the
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
On Fri, Jun 12, 2015 at 03:19:06PM +0300, Robert Munteanu wrote: Hi, Note to others: kernel 4.0.4 Reply to you: I tried ext4 to btrfs once a year ago and it severely mangled my filesystem. I looked at it as a cool feature/hack that may have worked some time ago, but that no one really uses anymore, and that may not work right at this point. Unless you hear back from a developer interested in debugging/fixing this, I would assume that this feature is broken and dead. Marc I have converted my root ext4 partition to btrfs. I used an USB stick to boot and used btrfs-convert. I also did a balance and defrag ( in that order ) , both when the fs was mounted. After logging in to KDE I quickly get a read-only filesystem. I've pasted the backtrace below Jun 11 23:13:08 mars kernel: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120 [btrfs]() Jun 11 23:13:08 mars kernel: BTRFS: Transaction aborted (error -95) Jun 11 23:13:08 mars kernel: Modules linked in: bnep bluetooth rfkill fuse vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) af_packet nf_log_ipv6 xt_pkttype nf_log_ip v4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_con ntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c snd_hda _codec_hdmi raid1 md_mod gpio_ich ppdev iTCO_wdt iTCO_vendor_support coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel snd_hda_intel dm_mod kvm snd_hda_co ntroller snd_hda_codec snd_hwdep serio_raw pcspkr snd_pcm i2c_i801 snd_seq joydev snd_seq_device snd_timer snd 8250_fintek parport_pc parport acpi_cpufreq lpc_ich Jun 11 23:13:08 mars kernel: soundcore mfd_core shpchp processor ata_generic btrfs hid_logitech_hidpp xor raid6_pq sr_mod cdrom nvidia_uvm(PO) nvidia(PO) firewire_ohc i firewire_core crc_itu_t uas usb_storage r8169 mii pata_jmicron hid_logitech_dj drm button sg Jun 11 23:13:08 mars kernel: CPU: 2 PID: 2777 Comm: kworker/u8:0 Tainted: P O4.0.4-3-desktop #1 Jun 11 23:13:08 mars kernel: Hardware name: Gigabyte Technology Co., Ltd. EP35-DS4/EP35-DS4, BIOS F6d 01/08/2009 Jun 11 23:13:08 mars kernel: Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] Jun 11 23:13:08 mars kernel: a0a92832 8167c4aa 880128513ca8 Jun 11 23:13:08 mars kernel: 81063bb1 880031929d28 880221e71800 ffa1 Jun 11 23:13:08 mars kernel: a0a914e0 0b50 81063c2a a0a95928 Jun 11 23:13:08 mars kernel: Call Trace: Jun 11 23:13:08 mars kernel: [8100574c] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars kernel: [81005aa3] show_stack_log_lvl+0xa3/0x190 Jun 11 23:13:08 mars kernel: [81007201] show_stack+0x21/0x50 Jun 11 23:13:08 mars kernel: [8167c4aa] dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel: [81063bb1] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08 mars kernel: [81063c2a] warn_slowpath_fmt+0x4a/0x50 Jun 11 23:13:08 mars kernel: [a09e598b] __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars kernel: [a0a1d18a] btrfs_finish_ordered_io+0x5aa/0x620 [btrfs] Jun 11 23:13:08 mars kernel: [a0a43253] normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel: [8107bcf2] process_one_work+0x142/0x420 Jun 11 23:13:08 mars kernel: [8107c0e4] worker_thread+0x114/0x460 Jun 11 23:13:08 mars kernel: [81081261] kthread+0xc1/0xe0 Jun 11 23:13:08 mars kernel: [81682d58] ret_from_fork+0x58/0x90 Jun 11 23:13:08 mars kernel: ---[ end trace 4c4eb7d6e98afa91 ]--- Jun 11 23:13:08 mars kernel: BTRFS: error (device sda1) in btrfs_finish_ordered_io:2896: errno=-95 unknown Jun 11 23:13:08 mars kernel: BTRFS info (device sda1): forced readonly Some diagnostic info: - btrfs scrub reports no errors - on the host machine I'm running btrfs v4.0+20150429 and kernel 4.0.4-3-desktop - on the live medium, used to run btrfs-convert, I was running btrfs v4.0+20150429 and kernel 4.0.3-1-default # btrfs fi show Label: none uuid: 54dea125-74cd-4bb2-86a2-f7bc645b76cf Total devices 1 FS bytes used 90.22GiB devid1 size 223.57GiB used 92.03GiB path /dev/sda1 btrfs-progs v4.0+20150429 # btrfs fi df / Data, single: total=89.00GiB, used=88.17GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=3.00GiB, used=2.05GiB GlobalReserve, single: total=512.00MiB, used=0.00B Is there a way out? I still have the old ext4 image and can revert, but I'm keeping the btrfs one for now, in case I can extract some useful debugging information from it. Thanks, Robert -- http://robert.muntea.nu/ -- To unsubscribe from this list: send the
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Am Wed, 17 Jun 2015 10:46:30 -0700 schrieb Marc MERLIN m...@merlins.org: I tried ext4 to btrfs once a year ago and it severely mangled my filesystem. I looked at it as a cool feature/hack that may have worked some time ago, but that no one really uses anymore, and that may not work right at this point. Just another data point: when I switched to btrfs in the middle of last year I used btrfs-convert on two file systems (an SSD and my backup partition on a USB 3.0 HDD), and it worked in both cases (i.e., no data loss). I did see some strange balance issues (see the ML archives), but IIRC nothing really serious. -- Marc Joliet -- People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup pgpazrScetd8J.pgp Description: Digitale Signatur von OpenPGP
Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/12/15 8:19 AM, Robert Munteanu wrote: Hi, I have converted my root ext4 partition to btrfs. I used an USB stick to boot and used btrfs-convert. I also did a balance and defrag ( in that order ) , both when the fs was mounted. After logging in to KDE I quickly get a read-only filesystem. I've pasted the backtrace below Jun 11 23:13:08 mars kernel: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120 [btrfs]() Jun 11 23:13:08 mars kernel: BTRFS: Transaction aborted (error -95) Jun 11 23:13:08 mars kernel: Modules linked in: bnep bluetooth rfkill fuse vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) af_packet nf_log_ipv6 xt_pkttype nf_log_ip v4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_con ntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c snd_hda _codec_hdmi raid1 md_mod gpio_ich ppdev iTCO_wdt iTCO_vendor_support coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel snd_hda_intel dm_mod kvm snd_hda_co ntroller snd_hda_codec snd_hwdep serio_raw pcspkr snd_pcm i2c_i801 snd_seq joydev snd_seq_device snd_timer snd 8250_fintek parport_pc parport acpi_cpufreq lpc_ich Jun 11 23:13:08 mars kernel: soundcore mfd_core shpchp processor ata_generic btrfs hid_logitech_hidpp xor raid6_pq sr_mod cdrom nvidia_uvm(PO) nvidia(PO) firewire_ohc i firewire_core crc_itu_t uas usb_storage r8169 mii pata_jmicron hid_logitech_dj drm button sg Jun 11 23:13:08 mars kernel: CPU: 2 PID: 2777 Comm: kworker/u8:0 Tainted: P O4.0.4-3-desktop #1 openSUSE Tumbleweed, I take it? We still actively support btrfs-convert through SLES, so we're invested in ensuring it continues working properly. I'd be interested in seeing images of both filesystems to investigate and to see if we can reproduce it. Errno -95 is -EOPNOTSUPP which is kind of strange to see. I can see a few possible places it would get passed up with a trace like that but being able to reproduce it would be extremely helpfu l. - -Jeff Jun 11 23:13:08 mars kernel: Hardware name: Gigabyte Technology Co., Ltd. EP35-DS4/EP35-DS4, BIOS F6d 01/08/2009 Jun 11 23:13:08 mars kernel: Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] Jun 11 23:13:08 mars kernel: a0a92832 8167c4aa 880128513ca8 Jun 11 23:13:08 mars kernel: 81063bb1 880031929d28 880221e71800 ffa1 Jun 11 23:13:08 mars kernel: a0a914e0 0b50 81063c2a a0a95928 Jun 11 23:13:08 mars kernel: Call Trace: Jun 11 23:13:08 mars kernel: [8100574c] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars kernel: [81005aa3] show_stack_log_lvl+0xa3/0x190 Jun 11 23:13:08 mars kernel: [81007201] show_stack+0x21/0x50 Jun 11 23:13:08 mars kernel: [8167c4aa] dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel: [81063bb1] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08 mars kernel: [81063c2a] warn_slowpath_fmt+0x4a/0x50 Jun 11 23:13:08 mars kernel: [a09e598b] __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars kernel: [a0a1d18a] btrfs_finish_ordered_io+0x5aa/0x620 [btrfs] Jun 11 23:13:08 mars kernel: [a0a43253] normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel: [8107bcf2] process_one_work+0x142/0x420 Jun 11 23:13:08 mars kernel: [8107c0e4] worker_thread+0x114/0x460 Jun 11 23:13:08 mars kernel: [81081261] kthread+0xc1/0xe0 Jun 11 23:13:08 mars kernel: [81682d58] ret_from_fork+0x58/0x90 Jun 11 23:13:08 mars kernel: ---[ end trace 4c4eb7d6e98afa91 ]--- Jun 11 23:13:08 mars kernel: BTRFS: error (device sda1) in btrfs_finish_ordered_io:2896: errno=-95 unknown Jun 11 23:13:08 mars kernel: BTRFS info (device sda1): forced readonly Some diagnostic info: - btrfs scrub reports no errors - on the host machine I'm running btrfs v4.0+20150429 and kernel 4.0.4-3-desktop - on the live medium, used to run btrfs-convert, I was running btrfs v4.0+20150429 and kernel 4.0.3-1-default # btrfs fi show Label: none uuid: 54dea125-74cd-4bb2-86a2-f7bc645b76cf Total devices 1 FS bytes used 90.22GiB devid1 size 223.57GiB used 92.03GiB path /dev/sda1 btrfs-progs v4.0+20150429 # btrfs fi df / Data, single: total=89.00GiB, used=88.17GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=3.00GiB, used=2.05GiB GlobalReserve, single: total=512.00MiB, used=0.00B Is there a way out? I still have the old ext4 image and can revert, but I'm keeping the btrfs one for now, in case I can extract some useful debugging information from it. Thanks, Robert - -- Jeff Mahoney
btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120
Hi, I have converted my root ext4 partition to btrfs. I used an USB stick to boot and used btrfs-convert. I also did a balance and defrag ( in that order ) , both when the fs was mounted. After logging in to KDE I quickly get a read-only filesystem. I've pasted the backtrace below Jun 11 23:13:08 mars kernel: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120 [btrfs]() Jun 11 23:13:08 mars kernel: BTRFS: Transaction aborted (error -95) Jun 11 23:13:08 mars kernel: Modules linked in: bnep bluetooth rfkill fuse vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) af_packet nf_log_ipv6 xt_pkttype nf_log_ip v4 nf_log_common xt_LOG xt_limit ip6t_REJECT xt_tcpudp nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_raw ipt_REJECT iptable_raw xt_CT iptable_filter ip6table_mangle nf_con ntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables xt_conntrack nf_conntrack ip6table_filter ip6_tables x_tables xfs libcrc32c snd_hda _codec_hdmi raid1 md_mod gpio_ich ppdev iTCO_wdt iTCO_vendor_support coretemp snd_hda_codec_realtek snd_hda_codec_generic kvm_intel snd_hda_intel dm_mod kvm snd_hda_co ntroller snd_hda_codec snd_hwdep serio_raw pcspkr snd_pcm i2c_i801 snd_seq joydev snd_seq_device snd_timer snd 8250_fintek parport_pc parport acpi_cpufreq lpc_ich Jun 11 23:13:08 mars kernel: soundcore mfd_core shpchp processor ata_generic btrfs hid_logitech_hidpp xor raid6_pq sr_mod cdrom nvidia_uvm(PO) nvidia(PO) firewire_ohc i firewire_core crc_itu_t uas usb_storage r8169 mii pata_jmicron hid_logitech_dj drm button sg Jun 11 23:13:08 mars kernel: CPU: 2 PID: 2777 Comm: kworker/u8:0 Tainted: P O4.0.4-3-desktop #1 Jun 11 23:13:08 mars kernel: Hardware name: Gigabyte Technology Co., Ltd. EP35-DS4/EP35-DS4, BIOS F6d 01/08/2009 Jun 11 23:13:08 mars kernel: Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs] Jun 11 23:13:08 mars kernel: a0a92832 8167c4aa 880128513ca8 Jun 11 23:13:08 mars kernel: 81063bb1 880031929d28 880221e71800 ffa1 Jun 11 23:13:08 mars kernel: a0a914e0 0b50 81063c2a a0a95928 Jun 11 23:13:08 mars kernel: Call Trace: Jun 11 23:13:08 mars kernel: [8100574c] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars kernel: [81005aa3] show_stack_log_lvl+0xa3/0x190 Jun 11 23:13:08 mars kernel: [81007201] show_stack+0x21/0x50 Jun 11 23:13:08 mars kernel: [8167c4aa] dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel: [81063bb1] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08 mars kernel: [81063c2a] warn_slowpath_fmt+0x4a/0x50 Jun 11 23:13:08 mars kernel: [a09e598b] __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars kernel: [a0a1d18a] btrfs_finish_ordered_io+0x5aa/0x620 [btrfs] Jun 11 23:13:08 mars kernel: [a0a43253] normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel: [8107bcf2] process_one_work+0x142/0x420 Jun 11 23:13:08 mars kernel: [8107c0e4] worker_thread+0x114/0x460 Jun 11 23:13:08 mars kernel: [81081261] kthread+0xc1/0xe0 Jun 11 23:13:08 mars kernel: [81682d58] ret_from_fork+0x58/0x90 Jun 11 23:13:08 mars kernel: ---[ end trace 4c4eb7d6e98afa91 ]--- Jun 11 23:13:08 mars kernel: BTRFS: error (device sda1) in btrfs_finish_ordered_io:2896: errno=-95 unknown Jun 11 23:13:08 mars kernel: BTRFS info (device sda1): forced readonly Some diagnostic info: - btrfs scrub reports no errors - on the host machine I'm running btrfs v4.0+20150429 and kernel 4.0.4-3-desktop - on the live medium, used to run btrfs-convert, I was running btrfs v4.0+20150429 and kernel 4.0.3-1-default # btrfs fi show Label: none uuid: 54dea125-74cd-4bb2-86a2-f7bc645b76cf Total devices 1 FS bytes used 90.22GiB devid1 size 223.57GiB used 92.03GiB path /dev/sda1 btrfs-progs v4.0+20150429 # btrfs fi df / Data, single: total=89.00GiB, used=88.17GiB System, single: total=32.00MiB, used=16.00KiB Metadata, single: total=3.00GiB, used=2.05GiB GlobalReserve, single: total=512.00MiB, used=0.00B Is there a way out? I still have the old ext4 image and can revert, but I'm keeping the btrfs one for now, in case I can extract some useful debugging information from it. Thanks, Robert -- http://robert.muntea.nu/ -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
