On May 3, 2017 4:28:11 PM EDT, Alexandru Guzu <alexg...@gmail.com> wrote: >Hi all, > >In a VirtualBox VM, I converted a EXT4 fs to BTRFS that is now running >on Ubuntu 16.04 (Kernel 4.4.0-72). I was able to use the system for >several weeks. I even did kernel updates, compression, deduplication >without issues. > >Since today, a little while after booting (usually when I start >opening applications), the FS becomes read-only. IMO, the only thing >that might have changed that could affect this is a kernel upgrade. >However, since the FS becomes RO, I cannot easily do a kernel update >(I guess I'd have to chroot and do it). > >The stack trace is the following: > >[ 88.836057] ------------[ cut here ]------------ >[ 88.836082] WARNING: CPU: 0 PID: 25 at >/build/linux-wXdoVv/linux-4.4.0/fs/btrfs/inode.c:2931 >btrfs_finish_ordered_io+0x63b/0x650 [btrfs]() >[ 88.836083] BTRFS: Transaction aborted (error -95) >[ 88.836084] Modules linked in: nvram msr zram lz4_compress >vboxsf(OE) joydev crct10dif_pclmul crc32_pclmul ghash_clmulni_intel >aesni_intel snd_intel8x0 aes_x86_64 snd_ac97_codec lrw gf128mul >glue_helper ablk_helper cryptd ac97_bus snd_pcm snd_seq_midi >snd_seq_midi_event snd_rawmidi snd_seq vboxvideo(OE) snd_seq_device >snd_timer ttm input_leds drm_kms_helper serio_raw i2c_piix4 snd drm >fb_sys_fops syscopyarea sysfillrect sysimgblt soundcore 8250_fintek >vboxguest(OE) mac_hid parport_pc ppdev lp parport autofs4 btrfs xor >raid6_pq hid_generic usbhid hid psmouse ahci libahci fjes video >pata_acpi >[ 88.836116] CPU: 0 PID: 25 Comm: kworker/u2:1 Tainted: G >OE 4.4.0-72-generic #93-Ubuntu >[ 88.836117] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS >VirtualBox 12/01/2006 >[ 88.836130] Workqueue: btrfs-endio-write btrfs_endio_write_helper >[btrfs] >[ 88.836132] 0000000000000286 00000000618d3a00 ffff88007cabbc78 >ffffffff813f82b3 >[ 88.836134] ffff88007cabbcc0 ffffffffc01912a8 ffff88007cabbcb0 >ffffffff81081302 >[ 88.836135] ffff880058bf01b0 ffff8800355f2800 ffff88007b9e64e0 >ffff88007c66f098 >[ 88.836137] Call Trace: >[ 88.836142] [<ffffffff813f82b3>] dump_stack+0x63/0x90 >[ 88.836145] [<ffffffff81081302>] warn_slowpath_common+0x82/0xc0 >[ 88.836147] [<ffffffff8108139c>] warn_slowpath_fmt+0x5c/0x80 >[ 88.836159] [<ffffffffc012373f>] ? unpin_extent_cache+0x8f/0xe0 >[btrfs] >[ 88.836167] [<ffffffffc00e0b06>] ? btrfs_free_path+0x26/0x30 >[btrfs] >[ 88.836178] [<ffffffffc011554b>] >btrfs_finish_ordered_io+0x63b/0x650 [btrfs] >[ 88.836188] [<ffffffffc0115845>] finish_ordered_fn+0x15/0x20 >[btrfs] >[ 88.836200] [<ffffffffc013dfda>] >btrfs_scrubparity_helper+0xca/0x2f0 [btrfs] >[ 88.836202] [<ffffffff810caee1>] ? >__raw_callee_save___pv_queued_spin_unlock+0x11/0x20 >[ 88.836214] [<ffffffffc013e28e>] btrfs_endio_write_helper+0xe/0x10 >[btrfs] >[ 88.836217] [<ffffffff8109a555>] process_one_work+0x165/0x480 >[ 88.836219] [<ffffffff8109a8bb>] worker_thread+0x4b/0x4c0 >[ 88.836220] [<ffffffff8109a870>] ? process_one_work+0x480/0x480 >[ 88.836222] [<ffffffff8109a870>] ? process_one_work+0x480/0x480 >[ 88.836224] [<ffffffff810a0be8>] kthread+0xd8/0xf0 >[ 88.836225] [<ffffffff810a0b10>] ? >kthread_create_on_node+0x1e0/0x1e0 >[ 88.836229] [<ffffffff8183ca0f>] ret_from_fork+0x3f/0x70 >[ 88.836230] [<ffffffff810a0b10>] ? >kthread_create_on_node+0x1e0/0x1e0 >[ 88.836232] ---[ end trace f4b8dbb54f0db139 ]--- >[ 88.836234] BTRFS: error (device sda1) in >btrfs_finish_ordered_io:2931: errno=-95 unknown >[ 88.836236] BTRFS info (device sda1): forced readonly >[ 88.836392] pending csums is 118784 > >If I reboot with the Live CD version, I can run `scrub` and `check` >without any issues. Also the FS stays read-write. > >Is this a known issue? Could it be due to the conversion, or can this >happen on any system on any time. This is a test VM that I can >re-make, but I would like to know if this can happen on a production >system. > >Regards, >Alex. >-- >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
Just FYI, I ran into basically this same issue a while back. My solution was to copy all the data off it, re-run mkfs.btrfs, then copy all the data back. I found that none of the existing data was damaged, so I think the actual issue is something left over from the conversion that confuses the commit logic. --Sean -- 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
