Le 29/09/2015 16:49, Lionel Bouton a écrit : > Le 27/09/2015 17:34, Lionel Bouton a écrit : >> [...] >> It's not clear to me that "btrfs fi defrag <file>" can't interfere with >> another process trying to use the file. I assume basic reading and >> writing is OK but there might be restrictions on unlinking/locking/using >> other ioctls... Are there any I should be aware of and should look for >> in Ceph OSDs? This is on a 3.8.19 kernel (with Gentoo patches which >> don't touch BTRFS sources) with btrfs-progs 4.0.1. We have 5 servers on >> our storage network : 2 are running a 4.0.5 kernel and 3 are running >> 3.8.19. The 3.8.19 servers are waiting for an opportunity to reboot on >> 4.0.5 (or better if we have the time to test a more recent kernel before >> rebooting : 4.1.8 and 4.2.1 are our candidates for testing right now). > Apparently this isn't the problem : we just had another similar Ceph OSD > crash without any concurrent defragmentation going on. However the Ceph developpers confirmed that BTRFS returned an EIO while reading data from disk. Is there a known bug in kernel 3.18.9 (sorry for the initial typo) that could lead to that? I couldn't find any on the wiki. The last crash was on a filesystem mounted with these options: rw,noatime,nodiratime,compress=lzo,space_cache,recovery,autodefrag Some of the extents have been recompressed to zlib (though at the time of the crash there was no such activity as I disabled it 2 days before to simplify diagnostics). Best regards, Lionel Bouton -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
