* 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
@ 2015-06-12 12:19 Robert Munteanu
2015-06-17 17:46 ` Marc MERLIN
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Robert Munteanu @ 2015-06-12 12:19 UTC (permalink / raw
To: linux-btrfs
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 O 4.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: 0000000000000000 ffffffffa0a92832
ffffffff8167c4aa ffff880128513ca8
Jun 11 23:13:08 mars kernel: ffffffff81063bb1 ffff880031929d28
ffff880221e71800 00000000ffffffa1
Jun 11 23:13:08 mars kernel: ffffffffa0a914e0 0000000000000b50
ffffffff81063c2a ffffffffa0a95928
Jun 11 23:13:08 mars kernel: Call Trace:
Jun 11 23:13:08 mars kernel: [<ffffffff8100574c>] dump_trace+0x8c/0x340
Jun 11 23:13:08 mars kernel: [<ffffffff81005aa3>] show_stack_log_lvl+0xa3/0x190
Jun 11 23:13:08 mars kernel: [<ffffffff81007201>] show_stack+0x21/0x50
Jun 11 23:13:08 mars kernel: [<ffffffff8167c4aa>] dump_stack+0x47/0x67
Jun 11 23:13:08 mars kernel: [<ffffffff81063bb1>]
warn_slowpath_common+0x81/0xb0
Jun 11 23:13:08 mars kernel: [<ffffffff81063c2a>] warn_slowpath_fmt+0x4a/0x50
Jun 11 23:13:08 mars kernel: [<ffffffffa09e598b>]
__btrfs_abort_transaction+0x4b/0x120 [btrfs]
Jun 11 23:13:08 mars kernel: [<ffffffffa0a1d18a>]
btrfs_finish_ordered_io+0x5aa/0x620 [btrfs]
Jun 11 23:13:08 mars kernel: [<ffffffffa0a43253>]
normal_work_helper+0xc3/0x320 [btrfs]
Jun 11 23:13:08 mars kernel: [<ffffffff8107bcf2>] process_one_work+0x142/0x420
Jun 11 23:13:08 mars kernel: [<ffffffff8107c0e4>] worker_thread+0x114/0x460
Jun 11 23:13:08 mars kernel: [<ffffffff81081261>] kthread+0xc1/0xe0
Jun 11 23:13:08 mars kernel: [<ffffffff81682d58>] 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
devid 1 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-12 12:19 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
@ 2015-06-17 17:46 ` Marc MERLIN
2015-06-17 19:41 ` Marc Joliet
2015-06-18 11:05 ` Robert Munteanu
2015-06-17 18:48 ` Jeff Mahoney
2015-06-26 1:54 ` Qu Wenruo
2 siblings, 2 replies; 25+ messages in thread
From: Marc MERLIN @ 2015-06-17 17:46 UTC (permalink / raw
To: Robert Munteanu; +Cc: linux-btrfs
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 O 4.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: 0000000000000000 ffffffffa0a92832
> ffffffff8167c4aa ffff880128513ca8
> Jun 11 23:13:08 mars kernel: ffffffff81063bb1 ffff880031929d28
> ffff880221e71800 00000000ffffffa1
> Jun 11 23:13:08 mars kernel: ffffffffa0a914e0 0000000000000b50
> ffffffff81063c2a ffffffffa0a95928
> Jun 11 23:13:08 mars kernel: Call Trace:
> Jun 11 23:13:08 mars kernel: [<ffffffff8100574c>] dump_trace+0x8c/0x340
> Jun 11 23:13:08 mars kernel: [<ffffffff81005aa3>] show_stack_log_lvl+0xa3/0x190
> Jun 11 23:13:08 mars kernel: [<ffffffff81007201>] show_stack+0x21/0x50
> Jun 11 23:13:08 mars kernel: [<ffffffff8167c4aa>] dump_stack+0x47/0x67
> Jun 11 23:13:08 mars kernel: [<ffffffff81063bb1>]
> warn_slowpath_common+0x81/0xb0
> Jun 11 23:13:08 mars kernel: [<ffffffff81063c2a>] warn_slowpath_fmt+0x4a/0x50
> Jun 11 23:13:08 mars kernel: [<ffffffffa09e598b>]
> __btrfs_abort_transaction+0x4b/0x120 [btrfs]
> Jun 11 23:13:08 mars kernel: [<ffffffffa0a1d18a>]
> btrfs_finish_ordered_io+0x5aa/0x620 [btrfs]
> Jun 11 23:13:08 mars kernel: [<ffffffffa0a43253>]
> normal_work_helper+0xc3/0x320 [btrfs]
> Jun 11 23:13:08 mars kernel: [<ffffffff8107bcf2>] process_one_work+0x142/0x420
> Jun 11 23:13:08 mars kernel: [<ffffffff8107c0e4>] worker_thread+0x114/0x460
> Jun 11 23:13:08 mars kernel: [<ffffffff81081261>] kthread+0xc1/0xe0
> Jun 11 23:13:08 mars kernel: [<ffffffff81682d58>] 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
> devid 1 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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
"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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-12 12:19 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
2015-06-17 17:46 ` Marc MERLIN
@ 2015-06-17 18:48 ` Jeff Mahoney
2015-06-18 11:08 ` Robert Munteanu
2015-06-26 1:54 ` Qu Wenruo
2 siblings, 1 reply; 25+ messages in thread
From: Jeff Mahoney @ 2015-06-17 18:48 UTC (permalink / raw
To: Robert Munteanu, linux-btrfs
-----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 O 4.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: 0000000000000000
> ffffffffa0a92832 ffffffff8167c4aa ffff880128513ca8 Jun 11 23:13:08
> mars kernel: ffffffff81063bb1 ffff880031929d28 ffff880221e71800
> 00000000ffffffa1 Jun 11 23:13:08 mars kernel: ffffffffa0a914e0
> 0000000000000b50 ffffffff81063c2a ffffffffa0a95928 Jun 11 23:13:08
> mars kernel: Call Trace: Jun 11 23:13:08 mars kernel:
> [<ffffffff8100574c>] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars
> kernel: [<ffffffff81005aa3>] show_stack_log_lvl+0xa3/0x190 Jun 11
> 23:13:08 mars kernel: [<ffffffff81007201>] show_stack+0x21/0x50
> Jun 11 23:13:08 mars kernel: [<ffffffff8167c4aa>]
> dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel:
> [<ffffffff81063bb1>] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08
> mars kernel: [<ffffffff81063c2a>] warn_slowpath_fmt+0x4a/0x50 Jun
> 11 23:13:08 mars kernel: [<ffffffffa09e598b>]
> __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars
> kernel: [<ffffffffa0a1d18a>] btrfs_finish_ordered_io+0x5aa/0x620
> [btrfs] Jun 11 23:13:08 mars kernel: [<ffffffffa0a43253>]
> normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel:
> [<ffffffff8107bcf2>] process_one_work+0x142/0x420 Jun 11 23:13:08
> mars kernel: [<ffffffff8107c0e4>] worker_thread+0x114/0x460 Jun 11
> 23:13:08 mars kernel: [<ffffffff81081261>] kthread+0xc1/0xe0 Jun
> 11 23:13:08 mars kernel: [<ffffffff81682d58>]
> 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 devid 1 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
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
iQIcBAEBAgAGBQJVgcDvAAoJEB57S2MheeWyzv0P/16m75jpx9hgcT7SVy+4u5Ja
sX2fFwDHgd/zGItt+F9GR4/yOB73maASeNVuNTxsBiERF7s56oGeBJ4+MYVIx48W
rrYdvKAC0DBrcc27/PiG1nwPVH/zfVPzcyYZSfvU2Mp3QFHG5ak54yw4MJhweiyW
cfdepCll1dWfGRM0o2sa5f+eXJaX/V5c2br316gsnvnlCaDlkgE9AZL9Siggrdok
ICtEJvcp5BSIBKWcvJVVJPJKS4i03TaEU2DU6ZqLs9xYWJEtu8ts0QIOmOUpOZU+
cgYTd3tb2uVzow0cK/H64CVbP/hkmA3z7WwjeiGYl1l2+bzCj+nu/YemYUIm2LYV
OCygm3o+b0RBLBFmwCVu03bjls56xwwmU71jJ5J30nPpYrwNcOEpTNN0uAfKhfmw
brziKpGEr/ITVuu1dXJ28R5dK1NNUTIhMDm5kotQUAYE8P36AY4WUmNZmTgw2Tp/
JLoNFj4XiAZNLN0t17gwYuJG+rJk5qMKzpL4MvbY2+/M0QaE7PvbVGtQTJWYgyfB
JYdBFBGUwNO7gnnKFecN+meobumuDZY0ogf7msf1Kt5x8hlrsFRtkqtvWENEtwCR
4yBPAagBrCTHJnEqp99yztg6KHYUwsPICxHJDItZnzFnHvn4P9zM8urosgzHvPsu
a3Le0Zo2YKNEWULHV5Q3
=obS1
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-17 17:46 ` Marc MERLIN
@ 2015-06-17 19:41 ` Marc Joliet
2015-06-18 11:05 ` Robert Munteanu
1 sibling, 0 replies; 25+ messages in thread
From: Marc Joliet @ 2015-06-17 19:41 UTC (permalink / raw
To: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
Am Wed, 17 Jun 2015 10:46:30 -0700
schrieb Marc MERLIN <marc@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
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-17 17:46 ` Marc MERLIN
2015-06-17 19:41 ` Marc Joliet
@ 2015-06-18 11:05 ` Robert Munteanu
2015-06-25 4:16 ` Marc MERLIN
1 sibling, 1 reply; 25+ messages in thread
From: Robert Munteanu @ 2015-06-18 11:05 UTC (permalink / raw
To: Marc MERLIN; +Cc: linux-btrfs
On Wed, Jun 17, 2015 at 8:46 PM, Marc MERLIN <marc@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 O 4.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: 0000000000000000 ffffffffa0a92832
>> ffffffff8167c4aa ffff880128513ca8
>> Jun 11 23:13:08 mars kernel: ffffffff81063bb1 ffff880031929d28
>> ffff880221e71800 00000000ffffffa1
>> Jun 11 23:13:08 mars kernel: ffffffffa0a914e0 0000000000000b50
>> ffffffff81063c2a ffffffffa0a95928
>> Jun 11 23:13:08 mars kernel: Call Trace:
>> Jun 11 23:13:08 mars kernel: [<ffffffff8100574c>] dump_trace+0x8c/0x340
>> Jun 11 23:13:08 mars kernel: [<ffffffff81005aa3>] show_stack_log_lvl+0xa3/0x190
>> Jun 11 23:13:08 mars kernel: [<ffffffff81007201>] show_stack+0x21/0x50
>> Jun 11 23:13:08 mars kernel: [<ffffffff8167c4aa>] dump_stack+0x47/0x67
>> Jun 11 23:13:08 mars kernel: [<ffffffff81063bb1>]
>> warn_slowpath_common+0x81/0xb0
>> Jun 11 23:13:08 mars kernel: [<ffffffff81063c2a>] warn_slowpath_fmt+0x4a/0x50
>> Jun 11 23:13:08 mars kernel: [<ffffffffa09e598b>]
>> __btrfs_abort_transaction+0x4b/0x120 [btrfs]
>> Jun 11 23:13:08 mars kernel: [<ffffffffa0a1d18a>]
>> btrfs_finish_ordered_io+0x5aa/0x620 [btrfs]
>> Jun 11 23:13:08 mars kernel: [<ffffffffa0a43253>]
>> normal_work_helper+0xc3/0x320 [btrfs]
>> Jun 11 23:13:08 mars kernel: [<ffffffff8107bcf2>] process_one_work+0x142/0x420
>> Jun 11 23:13:08 mars kernel: [<ffffffff8107c0e4>] worker_thread+0x114/0x460
>> Jun 11 23:13:08 mars kernel: [<ffffffff81081261>] kthread+0xc1/0xe0
>> Jun 11 23:13:08 mars kernel: [<ffffffff81682d58>] 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
>> devid 1 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 majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> "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
--
http://robert.muntea.nu/
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-17 18:48 ` Jeff Mahoney
@ 2015-06-18 11:08 ` Robert Munteanu
0 siblings, 0 replies; 25+ messages in thread
From: Robert Munteanu @ 2015-06-18 11:08 UTC (permalink / raw
To: Jeff Mahoney; +Cc: linux-btrfs
On Wed, Jun 17, 2015 at 9:48 PM, Jeff Mahoney <jeffm@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 O 4.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: 0000000000000000
>> ffffffffa0a92832 ffffffff8167c4aa ffff880128513ca8 Jun 11 23:13:08
>> mars kernel: ffffffff81063bb1 ffff880031929d28 ffff880221e71800
>> 00000000ffffffa1 Jun 11 23:13:08 mars kernel: ffffffffa0a914e0
>> 0000000000000b50 ffffffff81063c2a ffffffffa0a95928 Jun 11 23:13:08
>> mars kernel: Call Trace: Jun 11 23:13:08 mars kernel:
>> [<ffffffff8100574c>] dump_trace+0x8c/0x340 Jun 11 23:13:08 mars
>> kernel: [<ffffffff81005aa3>] show_stack_log_lvl+0xa3/0x190 Jun 11
>> 23:13:08 mars kernel: [<ffffffff81007201>] show_stack+0x21/0x50
>> Jun 11 23:13:08 mars kernel: [<ffffffff8167c4aa>]
>> dump_stack+0x47/0x67 Jun 11 23:13:08 mars kernel:
>> [<ffffffff81063bb1>] warn_slowpath_common+0x81/0xb0 Jun 11 23:13:08
>> mars kernel: [<ffffffff81063c2a>] warn_slowpath_fmt+0x4a/0x50 Jun
>> 11 23:13:08 mars kernel: [<ffffffffa09e598b>]
>> __btrfs_abort_transaction+0x4b/0x120 [btrfs] Jun 11 23:13:08 mars
>> kernel: [<ffffffffa0a1d18a>] btrfs_finish_ordered_io+0x5aa/0x620
>> [btrfs] Jun 11 23:13:08 mars kernel: [<ffffffffa0a43253>]
>> normal_work_helper+0xc3/0x320 [btrfs] Jun 11 23:13:08 mars kernel:
>> [<ffffffff8107bcf2>] process_one_work+0x142/0x420 Jun 11 23:13:08
>> mars kernel: [<ffffffff8107c0e4>] worker_thread+0x114/0x460 Jun 11
>> 23:13:08 mars kernel: [<ffffffff81081261>] kthread+0xc1/0xe0 Jun
>> 11 23:13:08 mars kernel: [<ffffffff81682d58>]
>> 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 devid 1 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
> SUSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
>
> iQIcBAEBAgAGBQJVgcDvAAoJEB57S2MheeWyzv0P/16m75jpx9hgcT7SVy+4u5Ja
> sX2fFwDHgd/zGItt+F9GR4/yOB73maASeNVuNTxsBiERF7s56oGeBJ4+MYVIx48W
> rrYdvKAC0DBrcc27/PiG1nwPVH/zfVPzcyYZSfvU2Mp3QFHG5ak54yw4MJhweiyW
> cfdepCll1dWfGRM0o2sa5f+eXJaX/V5c2br316gsnvnlCaDlkgE9AZL9Siggrdok
> ICtEJvcp5BSIBKWcvJVVJPJKS4i03TaEU2DU6ZqLs9xYWJEtu8ts0QIOmOUpOZU+
> cgYTd3tb2uVzow0cK/H64CVbP/hkmA3z7WwjeiGYl1l2+bzCj+nu/YemYUIm2LYV
> OCygm3o+b0RBLBFmwCVu03bjls56xwwmU71jJ5J30nPpYrwNcOEpTNN0uAfKhfmw
> brziKpGEr/ITVuu1dXJ28R5dK1NNUTIhMDm5kotQUAYE8P36AY4WUmNZmTgw2Tp/
> JLoNFj4XiAZNLN0t17gwYuJG+rJk5qMKzpL4MvbY2+/M0QaE7PvbVGtQTJWYgyfB
> JYdBFBGUwNO7gnnKFecN+meobumuDZY0ogf7msf1Kt5x8hlrsFRtkqtvWENEtwCR
> 4yBPAagBrCTHJnEqp99yztg6KHYUwsPICxHJDItZnzFnHvn4P9zM8urosgzHvPsu
> a3Le0Zo2YKNEWULHV5Q3
> =obS1
> -----END PGP SIGNATURE-----
--
http://robert.muntea.nu/
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-18 11:05 ` Robert Munteanu
@ 2015-06-25 4:16 ` Marc MERLIN
2015-06-25 12:08 ` Vytautas D
0 siblings, 1 reply; 25+ messages in thread
From: Marc MERLIN @ 2015-06-25 4:16 UTC (permalink / raw
To: Robert Munteanu; +Cc: linux-btrfs
On Thu, Jun 18, 2015 at 02:05:04PM +0300, Robert Munteanu wrote:
> On Wed, Jun 17, 2015 at 8:46 PM, Marc MERLIN <marc@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-25 4:16 ` Marc MERLIN
@ 2015-06-25 12:08 ` Vytautas D
[not found] ` <CABE5tBasBsycy_+q=RZj1dpqsLTREJTA72F-ZwNLt=kLX6wXhg@mail.gmail.com>
0 siblings, 1 reply; 25+ messages in thread
From: Vytautas D @ 2015-06-25 12:08 UTC (permalink / raw
To: Marc MERLIN; +Cc: Robert Munteanu, linux-btrfs
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 <marc@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 <marc@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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
[not found] ` <CABE5tBasBsycy_+q=RZj1dpqsLTREJTA72F-ZwNLt=kLX6wXhg@mail.gmail.com>
@ 2015-06-25 21:09 ` Marc MERLIN
0 siblings, 0 replies; 25+ messages in thread
From: Marc MERLIN @ 2015-06-25 21:09 UTC (permalink / raw
To: Ruslanas Gžibovskis; +Cc: Vytautas D, Robert Munteanu, linux-btrfs
On Thu, Jun 25, 2015 at 08:17:12PM +0000, 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-12 12:19 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
2015-06-17 17:46 ` Marc MERLIN
2015-06-17 18:48 ` Jeff Mahoney
@ 2015-06-26 1:54 ` Qu Wenruo
2015-06-26 2:08 ` Qu Wenruo
2 siblings, 1 reply; 25+ messages in thread
From: Qu Wenruo @ 2015-06-26 1:54 UTC (permalink / raw
To: Robert Munteanu, linux-btrfs
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 O 4.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: 0000000000000000 ffffffffa0a92832
> ffffffff8167c4aa ffff880128513ca8
> Jun 11 23:13:08 mars kernel: ffffffff81063bb1 ffff880031929d28
> ffff880221e71800 00000000ffffffa1
> Jun 11 23:13:08 mars kernel: ffffffffa0a914e0 0000000000000b50
> ffffffff81063c2a ffffffffa0a95928
> Jun 11 23:13:08 mars kernel: Call Trace:
> Jun 11 23:13:08 mars kernel: [<ffffffff8100574c>] dump_trace+0x8c/0x340
> Jun 11 23:13:08 mars kernel: [<ffffffff81005aa3>] show_stack_log_lvl+0xa3/0x190
> Jun 11 23:13:08 mars kernel: [<ffffffff81007201>] show_stack+0x21/0x50
> Jun 11 23:13:08 mars kernel: [<ffffffff8167c4aa>] dump_stack+0x47/0x67
> Jun 11 23:13:08 mars kernel: [<ffffffff81063bb1>]
> warn_slowpath_common+0x81/0xb0
> Jun 11 23:13:08 mars kernel: [<ffffffff81063c2a>] warn_slowpath_fmt+0x4a/0x50
> Jun 11 23:13:08 mars kernel: [<ffffffffa09e598b>]
> __btrfs_abort_transaction+0x4b/0x120 [btrfs]
> Jun 11 23:13:08 mars kernel: [<ffffffffa0a1d18a>]
> btrfs_finish_ordered_io+0x5aa/0x620 [btrfs]
> Jun 11 23:13:08 mars kernel: [<ffffffffa0a43253>]
> normal_work_helper+0xc3/0x320 [btrfs]
> Jun 11 23:13:08 mars kernel: [<ffffffff8107bcf2>] process_one_work+0x142/0x420
> Jun 11 23:13:08 mars kernel: [<ffffffff8107c0e4>] worker_thread+0x114/0x460
> Jun 11 23:13:08 mars kernel: [<ffffffff81081261>] kthread+0xc1/0xe0
> Jun 11 23:13:08 mars kernel: [<ffffffff81682d58>] 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
> devid 1 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
>
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-26 1:54 ` Qu Wenruo
@ 2015-06-26 2:08 ` Qu Wenruo
2015-07-09 3:09 ` Chris Murphy
0 siblings, 1 reply; 25+ messages in thread
From: Qu Wenruo @ 2015-06-26 2:08 UTC (permalink / raw
To: Robert Munteanu, linux-btrfs
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 O 4.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: 0000000000000000 ffffffffa0a92832
>> ffffffff8167c4aa ffff880128513ca8
>> Jun 11 23:13:08 mars kernel: ffffffff81063bb1 ffff880031929d28
>> ffff880221e71800 00000000ffffffa1
>> Jun 11 23:13:08 mars kernel: ffffffffa0a914e0 0000000000000b50
>> ffffffff81063c2a ffffffffa0a95928
>> Jun 11 23:13:08 mars kernel: Call Trace:
>> Jun 11 23:13:08 mars kernel: [<ffffffff8100574c>] dump_trace+0x8c/0x340
>> Jun 11 23:13:08 mars kernel: [<ffffffff81005aa3>]
>> show_stack_log_lvl+0xa3/0x190
>> Jun 11 23:13:08 mars kernel: [<ffffffff81007201>] show_stack+0x21/0x50
>> Jun 11 23:13:08 mars kernel: [<ffffffff8167c4aa>] dump_stack+0x47/0x67
>> Jun 11 23:13:08 mars kernel: [<ffffffff81063bb1>]
>> warn_slowpath_common+0x81/0xb0
>> Jun 11 23:13:08 mars kernel: [<ffffffff81063c2a>]
>> warn_slowpath_fmt+0x4a/0x50
>> Jun 11 23:13:08 mars kernel: [<ffffffffa09e598b>]
>> __btrfs_abort_transaction+0x4b/0x120 [btrfs]
>> Jun 11 23:13:08 mars kernel: [<ffffffffa0a1d18a>]
>> btrfs_finish_ordered_io+0x5aa/0x620 [btrfs]
>> Jun 11 23:13:08 mars kernel: [<ffffffffa0a43253>]
>> normal_work_helper+0xc3/0x320 [btrfs]
>> Jun 11 23:13:08 mars kernel: [<ffffffff8107bcf2>]
>> process_one_work+0x142/0x420
>> Jun 11 23:13:08 mars kernel: [<ffffffff8107c0e4>]
>> worker_thread+0x114/0x460
>> Jun 11 23:13:08 mars kernel: [<ffffffff81081261>] kthread+0xc1/0xe0
>> Jun 11 23:13:08 mars kernel: [<ffffffff81682d58>]
>> 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
>> devid 1 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
>>
>>
> --
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-06-26 2:08 ` Qu Wenruo
@ 2015-07-09 3:09 ` Chris Murphy
2015-07-09 10:52 ` Vytautas D
[not found] ` <CAO5K3OcA1_Z4-jvv_2C0StBkOr++_vUX4kOspY8cuhnX2t3z_A@mail.gmail.com>
0 siblings, 2 replies; 25+ messages in thread
From: Chris Murphy @ 2015-07-09 3:09 UTC (permalink / raw
To: Qu Wenruo; +Cc: Robert Munteanu, Btrfs BTRFS
On Thu, Jun 25, 2015 at 8:08 PM, Qu Wenruo <quwenruo@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-09 3:09 ` Chris Murphy
@ 2015-07-09 10:52 ` Vytautas D
[not found] ` <CAO5K3OcA1_Z4-jvv_2C0StBkOr++_vUX4kOspY8cuhnX2t3z_A@mail.gmail.com>
1 sibling, 0 replies; 25+ messages in thread
From: Vytautas D @ 2015-07-09 10:52 UTC (permalink / raw
To: Chris Murphy; +Cc: Qu Wenruo, Robert Munteanu, Btrfs BTRFS
<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 <lists@colorremedies.com> wrote:
> On Thu, Jun 25, 2015 at 8:08 PM, Qu Wenruo <quwenruo@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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
[not found] ` <CAO5K3OcA1_Z4-jvv_2C0StBkOr++_vUX4kOspY8cuhnX2t3z_A@mail.gmail.com>
@ 2015-07-09 21:38 ` Chris Murphy
2015-07-10 0:34 ` Qu Wenruo
0 siblings, 1 reply; 25+ messages in thread
From: Chris Murphy @ 2015-07-09 21:38 UTC (permalink / raw
To: Vytautas D; +Cc: Chris Murphy, Qu Wenruo, Robert Munteanu, Btrfs BTRFS
On Thu, Jul 9, 2015 at 4:52 AM, Vytautas D <vytdau@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-09 21:38 ` Chris Murphy
@ 2015-07-10 0:34 ` Qu Wenruo
2015-07-10 0:45 ` Chris Murphy
2015-07-26 21:47 ` Robert Munteanu
0 siblings, 2 replies; 25+ messages in thread
From: Qu Wenruo @ 2015-07-10 0:34 UTC (permalink / raw
To: Chris Murphy, Vytautas D; +Cc: Robert Munteanu, Btrfs BTRFS
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 <vytdau@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?
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-10 0:34 ` Qu Wenruo
@ 2015-07-10 0:45 ` Chris Murphy
2015-07-10 4:45 ` Qu Wenruo
2015-07-26 21:47 ` Robert Munteanu
1 sibling, 1 reply; 25+ messages in thread
From: Chris Murphy @ 2015-07-10 0:45 UTC (permalink / raw
To: Qu Wenruo, Btrfs BTRFS
On Thu, Jul 9, 2015 at 6:34 PM, Qu Wenruo <quwenruo@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-10 0:45 ` Chris Murphy
@ 2015-07-10 4:45 ` Qu Wenruo
2015-07-14 23:29 ` Chris Murphy
0 siblings, 1 reply; 25+ messages in thread
From: Qu Wenruo @ 2015-07-10 4:45 UTC (permalink / raw
To: Chris Murphy, Btrfs BTRFS
Chris Murphy wrote on 2015/07/09 18:45 -0600:
> On Thu, Jul 9, 2015 at 6:34 PM, Qu Wenruo <quwenruo@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-10 4:45 ` Qu Wenruo
@ 2015-07-14 23:29 ` Chris Murphy
0 siblings, 0 replies; 25+ messages in thread
From: Chris Murphy @ 2015-07-14 23:29 UTC (permalink / raw
To: Qu Wenruo; +Cc: Btrfs BTRFS
On Thu, Jul 9, 2015 at 10:45 PM, Qu Wenruo <quwenruo@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 <quwenruo@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-10 0:34 ` Qu Wenruo
2015-07-10 0:45 ` Chris Murphy
@ 2015-07-26 21:47 ` Robert Munteanu
2015-07-30 13:16 ` Robert Munteanu
1 sibling, 1 reply; 25+ messages in thread
From: Robert Munteanu @ 2015-07-26 21:47 UTC (permalink / raw
To: Qu Wenruo; +Cc: Chris Murphy, Vytautas D, Btrfs BTRFS
On Fri, Jul 10, 2015 at 3:34 AM, Qu Wenruo <quwenruo@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
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-26 21:47 ` Robert Munteanu
@ 2015-07-30 13:16 ` Robert Munteanu
2015-07-31 2:08 ` Qu Wenruo
0 siblings, 1 reply; 25+ messages in thread
From: Robert Munteanu @ 2015-07-30 13:16 UTC (permalink / raw
To: Qu Wenruo; +Cc: Chris Murphy, Vytautas D, Btrfs BTRFS
> 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/
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-30 13:16 ` Robert Munteanu
@ 2015-07-31 2:08 ` Qu Wenruo
2015-07-31 13:38 ` Robert Munteanu
0 siblings, 1 reply; 25+ messages in thread
From: Qu Wenruo @ 2015-07-31 2:08 UTC (permalink / raw
To: Robert Munteanu; +Cc: Chris Murphy, Vytautas D, Btrfs BTRFS
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
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-31 2:08 ` Qu Wenruo
@ 2015-07-31 13:38 ` Robert Munteanu
2015-08-03 0:54 ` Qu Wenruo
2015-08-03 1:22 ` Qu Wenruo
0 siblings, 2 replies; 25+ messages in thread
From: Robert Munteanu @ 2015-07-31 13:38 UTC (permalink / raw
To: Qu Wenruo; +Cc: Chris Murphy, Vytautas D, Btrfs BTRFS
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
On Fri, Jul 31, 2015 at 5:08 AM, Qu Wenruo <quwenruo@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/
[-- Attachment #2: screenlog.0.gz --]
[-- Type: application/x-gzip, Size: 4709 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-31 13:38 ` Robert Munteanu
@ 2015-08-03 0:54 ` Qu Wenruo
2015-08-03 1:22 ` Qu Wenruo
1 sibling, 0 replies; 25+ messages in thread
From: Qu Wenruo @ 2015-08-03 0:54 UTC (permalink / raw
To: Robert Munteanu; +Cc: Chris Murphy, Vytautas D, Btrfs BTRFS
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 <quwenruo@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
>
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-07-31 13:38 ` Robert Munteanu
2015-08-03 0:54 ` Qu Wenruo
@ 2015-08-03 1:22 ` Qu Wenruo
2015-08-03 7:45 ` Robert Munteanu
1 sibling, 1 reply; 25+ messages in thread
From: Qu Wenruo @ 2015-08-03 1:22 UTC (permalink / raw
To: Robert Munteanu; +Cc: Chris Murphy, Vytautas D, Btrfs BTRFS
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 <quwenruo@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
>
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* 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
2015-08-03 1:22 ` Qu Wenruo
@ 2015-08-03 7:45 ` Robert Munteanu
0 siblings, 0 replies; 25+ messages in thread
From: Robert Munteanu @ 2015-08-03 7:45 UTC (permalink / raw
To: Qu Wenruo; +Cc: Chris Murphy, Vytautas D, Btrfs BTRFS
On Mon, Aug 3, 2015 at 4:22 AM, Qu Wenruo <quwenruo@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
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2015-08-03 7:45 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-12 12:19 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
2015-06-17 17:46 ` Marc MERLIN
2015-06-17 19:41 ` Marc Joliet
2015-06-18 11:05 ` Robert Munteanu
2015-06-25 4:16 ` Marc MERLIN
2015-06-25 12:08 ` Vytautas D
[not found] ` <CABE5tBasBsycy_+q=RZj1dpqsLTREJTA72F-ZwNLt=kLX6wXhg@mail.gmail.com>
2015-06-25 21:09 ` Marc MERLIN
2015-06-17 18:48 ` Jeff Mahoney
2015-06-18 11:08 ` Robert Munteanu
2015-06-26 1:54 ` Qu Wenruo
2015-06-26 2:08 ` Qu Wenruo
2015-07-09 3:09 ` Chris Murphy
2015-07-09 10:52 ` Vytautas D
[not found] ` <CAO5K3OcA1_Z4-jvv_2C0StBkOr++_vUX4kOspY8cuhnX2t3z_A@mail.gmail.com>
2015-07-09 21:38 ` Chris Murphy
2015-07-10 0:34 ` Qu Wenruo
2015-07-10 0:45 ` Chris Murphy
2015-07-10 4:45 ` Qu Wenruo
2015-07-14 23:29 ` Chris Murphy
2015-07-26 21:47 ` Robert Munteanu
2015-07-30 13:16 ` Robert Munteanu
2015-07-31 2:08 ` Qu Wenruo
2015-07-31 13:38 ` Robert Munteanu
2015-08-03 0:54 ` Qu Wenruo
2015-08-03 1:22 ` Qu Wenruo
2015-08-03 7:45 ` Robert Munteanu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.