On 2015-07-16 07:41, Austin S Hemmelgarn wrote:
After an a long time of trying to reproduce this in a Virtual Machine with no success, and increasing issues from the motherboard in the system in question culminating in it dying completely, I'm pretty sure now that this was in fact a hardware problem and not a bug in BTRFS. I've been unable to reproduce it at all after replacing the motherboard.On 2015-07-15 17:29, Chris Murphy wrote:On Wed, Jul 15, 2015 at 10:15 AM, Hugo Mills <h...@carfax.org.uk> wrote:There is at least one superblock on every device, usually two, and often three. Each superblock contains the virtual address of the roots of the root tree, the chunk tree and the log tree. Those are useless without having the chunk tree, so there's also some information about the chunk tree appended to the end of each superblock to bootstrap the virtual address space lookup.So maybe Austin can use btrfs-show-super -a on every device and see if there's anything different on some of the devices, that shouldn't be different? There must be something the kernel is tripping over that the use space tools aren't for some reason.I actually did do so when this happened most recently (I just didn't think to mention it in the most recent e-mail), and nothing appeared to be different either between devices or within a given device (IIRC, there's 2 sb per device in each of the filesystems in question). I'm going to try and reproduce this in a VM for inspection as all the filesystems I had this issue with now seem to be working fine (with the exception of some errors in the data blocks of one that got caught by scrub).
smime.p7s
Description: S/MIME Cryptographic Signature
