Jump to content

btrfs stability on 3.14.x kernel ?


mdel

Recommended Posts

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 by zador.blood.stained
Changed topic tithe to not confuse people, 4.14.x != vanilla
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines