On Mon, Oct 13, 2014 at 4:48 PM, john terragon <jterra...@gmail.com> wrote: > I think I just found a consistent simple way to trigger the problem > (at least on my system). And, as I guessed before, it seems to be > related just to readonly snapshots: > > 1) I create a readonly snapshot > 2) I do some changes on the source subvolume for the snapshot (I'm not > sure changes are strictly needed) > 3) reboot (or probably just unmount and remount. I reboot because the > fs I've problems with contains my root subvolume) > > After the rebooting (or the remount) I consistently have the corruption > with the usual multitude of these in dmesg > "parent transid verify failed on 902316032 wanted 2484 found 4101" > and the characteristic ls -la output > > drwxr-xr-x 1 root root 250 Oct 10 15:37 root > d????????? ? ? ? ? ? root-b2 > drwxr-xr-x 1 root root 250 Oct 10 15:37 root-b3 > d????????? ? ? ? ? ? root-backup > > root-backup and root-b2 are both readonly whereas root-b3 is rw (and > it didn't get corrupted). > > David, maybe you can try the same steps on one of your machines? >
Look at that. I didn't realize it, but indeed I have a corrupted snapshot: /data/.snapshots/5338/: ls: cannot access /data/.snapshots/5338/snapshot: Cannot allocate memory total 4 drwxr-xr-x 1 root root 32 Oct 11 06:09 . drwxr-x--- 1 root root 32 Oct 11 07:42 .. -rw------- 1 root root 135 Oct 11 06:09 info.xml d????????? ? ? ? ? ? snapshot Several older snapshots are fine, and those predate my 3.17 upgrade. I noticed that this corrupted snapshot isn't even listed in my snapper lists. btrfs su delete /data/.snapshots/5338/snapshot Transaction commit: none (default) ERROR: error accessing '/data/.snapshots/5338/snapshot' Removing them appears to be problematic as well. I might just disable compress=lzo and go back to 3.16 to see how that goes. -- Rich -- 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
