On Sun, 10 Nov 2013, Duncan <1i5t5.dun...@cox.net> wrote: > Do you have disk quotas (btrfs qgroups) enabled? There's a known current
No. I haven't yet had BTRFS running well enough to need anything else to test. > Meanwhile, the threads getting the OOMs are going to be btrfs-worker > threads. Killing them leaves open I/O and the locks for that I/O won't > get cleaned up, thus effectively stalling I/O for anything on that btrfs There are no log entries about kernel threads getting killed, I wasn't even aware that it was possible for kernel threads to be killed. But as the logs are on a BTRFS filesystem it might just be impossible for such log records to be committed to disk. > volume (AFAIK the entire volume, not just that subvolume), tho I'm not > sure whether it'll affect all I/O (on other btrfs volumes and non-btrfs > filesystems) or not. Existing tasks will continue to operate as long as > they don't do any I/O to the locked-up volumes, and from my experience Judging by the times of the log records I believe that the SSD was scrubbed successfully and the system hung while scrubbing the 3TB SATA disks. If kernel threads are being killed as you suggest then it would be threads killed while scrubbing the 2*3TB RAID-1 that makes the SSD unusable. > and hope there's not too much damage. (Tho of course with btrfs being > experimental, if you're running it without tested backups to restore from > if worse comes to worse, you're doing it wrong, which means that any > damage there might be simply means restoring from that backup, at worst.) My backups are reasonably good. The best that they have ever been. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- 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
