Created attachment 106812 [details] relevant dmesg output Setup description: Label: none uuid: d7662fe5-04fc-4b4b-a6e0-4d34637d56d3 Total devices 2 FS bytes used 188.91GB devid 1 size 500.00GB used 279.03GB path /dev/sda8 devid 2 size 500.00GB used 279.01GB path /dev/sdb3 The devices are in raid1 mode and the volume is mounted at /home with noatime,compress=lzo,space_cache,inode_cache. Bug description: I ran into this bug a few days ago. My machine has been running for many, many hours with suspends to RAM in between. Suddenly the affected BTRFS volume became read-only. After a reboot (which required pushing the reset button because the volume couldn't be unmounted), the problem reoccured with virtually the same dmesg output (see attachment) within a few minutes. I fsck'ed and scrubbed the volume in single user mode without errors. After another reboot, same problem within minutes. For the time being I worked around the problem by copying relevant data to another partition and shut my machine down after work. Yesterday I scrubbed it again in multiuser mode but without logging into a desktop session. Afterwards I resumed using the volume normally and it didn't fail until now. I'm not involved with btrfs or kernel development but willing and able to poke around more if necessary.
A remark to the attached dmesg log: There was no message in the preceeding 100 seconds. In the following ~100 seconds were only messages about other components complaining about /home being unwritable.
I believe I've fixed this already, could you try and reproduce on btrfs-next and see if you still see the problem? If you can't build your own kernel I'm pretty sure the patch is in 3.9. Thanks.
Alright, I'll try to find the relevant change set, though I have no idea how to reproduce it. (I didn't find any reference to the same problem in the first place; the closest it got, was http://www.spinics.net/lists/linux-btrfs/msg17504.htm)