On Sat, Jun 25, 2016 at 2:10 PM, Vasco Almeida <vascomalme...@sapo.pt> wrote: > Citando Chris Murphy <li...@colorremedies.com>:
>> >> I would do a couple things in order: >> 1. Mount ro and copy off what you want in case the whole thing gets >> worse and can't ever be mounted again. >> 2. Mount with only these options: -o skip_balance,subvolid=5,nospace_cache > > > I have mounted with that options and was readwrite first and then it forces > readonly. You can see a delay between first BTRFS messages and the "BTRFS > info: forced readonly" message in dmesg. > > /dev/mapper/vg_pupu-lv_opensuse_root on /mnt type btrfs > (ro,relatime,seclabel,nospace_cache,skip_balance,subvolid=5,subvol=/) > > >> If it mounts rw, don't do anything with it, just see if it cleans up >> after itself. It also looks from the previous trace it was trying to >> remove a snapshot and there are complaints of problems in that >> snapshot. So hopefully just waiting 5 minutes doing nothing and it'll >> clean up after itself (you can check with top to see if there are any >> btrfs related transactions that run including the btrfs-cleaner >> process) wait until they're done. > > > I can see that btrfs processes including btrfs-cleaner but they may be not > doing much since device was forced readonly after mounting it. Readonly just refers to user space to and including VFS, is my understanding. The file system itself can still write to the block device. > I have umount it normally (umount /mnt) after more than 20 minutes since > mounting it. > >> 3. btrfs-image so that devs can see what's causing the problem that >> the current code isn't handling well enough. > > > btrfs-image does not create dump image: > > # btrfs-image /dev/mapper/vg_pupu-lv_opensuse_root > btrfs-lv_opensuse_root.image > checksum verify failed on 437944320 found 8BF8C752 wanted 39F456C8 > checksum verify failed on 437944320 found 8BF8C752 wanted 39F456C8 > checksum verify failed on 437944320 found 8BF8C752 wanted 39F456C8 > checksum verify failed on 437944320 found 8BF8C752 wanted 39F456C8 > Csum didn't match > Error reading metadata block > Error adding block -5 > checksum verify failed on 437944320 found 8BF8C752 wanted 39F456C8 > checksum verify failed on 437944320 found 8BF8C752 wanted 39F456C8 > checksum verify failed on 437944320 found 8BF8C752 wanted 39F456C8 > checksum verify failed on 437944320 found 8BF8C752 wanted 39F456C8 > Csum didn't match > Error reading metadata block > Error flushing pending -5 > create failed (Success) > # echo $? > 1 Well it's pretty strange to have DUP metadata and for the checksum verify to fail on both copies. I don't have much optimism that brfsck repair can fix it either. But still it's worth a shot since there's not much else to go on. -- Chris Murphy -- 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
