mdel Posted December 13, 2016 Posted December 13, 2016 (edited) hi, i'm running Armbian with kernel 3.14.73 from @balbes150 image for s905 i was trying to upgrade an usb hard drive and started transferring about 400GB of data from the old usb hdd (ext4) to the new one (brtfs) when this happened : i've added the initial btrfs disk mount. [ 95.972270] scsi 1:0:0:0: Direct-Access ATA Hitachi HUA72302 A840 PQ: 0 ANSI: 6 [ 95.990817] sd 1:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.81 TiB) [ 96.007364] sd 1:0:0:0: [sdb] Write Protect is off [ 96.020930] sd 1:0:0:0: [sdb] Mode Sense: 43 00 00 00 [ 96.021451] sd 1:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 96.081024] sdb: sdb1 sdb2 [ 96.087622] sd 1:0:0:0: [sdb] Attached SCSI disk [ 96.467915] BTRFS: device label USBBackup devid 1 transid 10 /dev/sdb2 [ 96.509151] BTRFS: device label USBLinux devid 1 transid 44 /dev/sdb1 [ 96.526054] BTRFS: device label USBBackup devid 1 transid 10 /dev/sdb2 [ 96.541960] BTRFS: device label USBLinux devid 1 transid 44 /dev/sdb1 [ 277.575889] BTRFS: device label USBLinux devid 1 transid 44 /dev/sdb1 [ 277.593542] BTRFS info (device sdb1): btrfs: use no compression [ 277.623166] BTRFS info (device sdb1): disk space caching is enabled [ 280.020449] EXT4-fs (sda2): mounted filesystem with writeback data mode. Opts: data=writeback [17089.147117] BTRFS: sdb1 checksum verify failed on 577847296 wanted 3949F1FD found 26D7F292 level 0 [17089.172645] BTRFS: sdb1 checksum verify failed on 577847296 wanted 3949F1FD found 26D7F292 level 0 [17089.189544] BTRFS: sdb1 checksum verify failed on 577847296 wanted 3949F1FD found 26D7F292 level 0 [17089.199629] BTRFS: sdb1 checksum verify failed on 577847296 wanted 3949F1FD found 26D7F292 level 0 [17089.208591] ------------[ cut here ]------------ [17089.214854] WARNING: CPU: 0 PID: 2160 at fs/btrfs/inode.c:878 $x+0x368/0x420 [btrfs]() [17089.223015] Modules linked in: tun meson_ir nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc i2c_gpio i2c_algo_bit bonding fuse autofs4 btrfs xor raid6_pq [17089.243100] CPU: 0 PID: 2160 Comm: btrfs-transacti Not tainted 3.14.73-vegas95 #1 [17089.250014] Call trace: [17089.255068] [<ffffffc001089040>] dump_backtrace+0x0/0x140 [17089.260153] [<ffffffc0010891a4>] show_stack+0x24/0x2c [17089.265214] [<ffffffc00183fa48>] dump_stack+0x80/0xa4 [17089.270261] [<ffffffc0010ad7fc>] warn_slowpath_common+0x94/0xb8 [17089.275740] [<ffffffc0010ad968>] warn_slowpath_null+0x38/0x44 [17089.281604] [<ffffffbffc059fb0>] $x+0x368/0x420 [btrfs] [17089.286744] [<ffffffbffc05a404>] $x+0x39c/0x968 [btrfs] [17089.291911] [<ffffffbffc05ac68>] $x+0x298/0x370 [btrfs] [17089.297089] [<ffffffbffc071eb4>] __extent_writepage+0x660/0x7c4 [btrfs] [17089.303643] [<ffffffbffc0721c4>] $x+0x1ac/0x2d4 [btrfs] [17089.308819] [<ffffffbffc07333c>] extent_writepages+0x68/0x88 [btrfs] [17089.315112] [<ffffffbffc055d54>] $x+0x34/0x48 [btrfs] [17089.319987] [<ffffffc001182f08>] do_writepages+0x40/0x6c [17089.325247] [<ffffffc001177678>] __filemap_fdatawrite_range+0x6c/0x78 [17089.331628] [<ffffffc0011777a4>] filemap_fdatawrite_range+0x34/0x40 [17089.337970] [<ffffffbffc06c6f4>] btrfs_wait_ordered_range+0x80/0x16c [btrfs] [17089.344958] [<ffffffbffc092800>] __btrfs_write_out_cache+0x52c/0x6f8 [btrfs] [17089.351945] [<ffffffbffc093d48>] $x+0x98/0xfc [btrfs] [17089.356941] [<ffffffbffc0434d8>] btrfs_write_dirty_block_groups+0x4e8/0x628 [btrfs] [17089.364540] [<ffffffbffc0c5404>] commit_cowonly_roots+0x13c/0x204 [btrfs] [17089.371261] [<ffffffbffc0530b4>] btrfs_commit_transaction+0x454/0x888 [btrfs] [17089.378333] [<ffffffbffc04f5c0>] $x+0x150/0x1d0 [btrfs] [17089.383380] [<ffffffc0010d1fe0>] kthread+0xdc/0xf0 [17089.388956] ---[ end trace 6da0e760a6c1ab74 ]--- my cp command got stuck and kswapd0 started to go haywire showing 1.5GB/s of I/O i'm only guessing that a btrfs process crashed, i don't know much about btrfs so i have not configured anything special besides adding the compress=no to my fstab. The first 200GB copy completed properly. I did notice that the I/O rate was not completely stable, going around 35MB/s read and write from the two disks, but every 10-15 sec stopping and a btrfs commit process started doing some io for a couple of seconds then the devices read write would come back. Reading about those "checksum verify" messages, i see quite a lot of mentions of btrfs kernel bugs, so i'm wondering about my choice of btrfs on the current vanilla kernel. Although it is not the latest one i don't expect it has moved far beyond my version with an up to date kernel.. Edited December 13, 2016 by zador.blood.stained Changed topic tithe to not confuse people, 4.14.x != vanilla
zador.blood.stained Posted December 13, 2016 Posted December 13, 2016 i'm running Armbian with kernel 3.14.73 from @balbes150 image for s905 This kernel version is too old to consider reliable for btrfs, you can't call 3.14.x a "vanilla" kernel. It was discussed several times on this forum - 4.4.x LTS is the minimum kernel version to use for btrfs and don't worry about stability, though using the latest mainline is still recommended if possible.
mdel Posted December 13, 2016 Author Posted December 13, 2016 yeah sorry i meant legacy not vanilla. okay so i'll forget about btrfs, not a problem i can format that partition to ext4 and copy everything again.
Recommended Posts