&gt; Hi, sorry for my tone - it&#x27;s beyond rational discussion...<p>No worries. I don&#x27;t give a shit about tone, just about content. Tone is next to impossible to accurately judge through text anyway, so I don&#x27;t presume to understand someone&#x27;s intent unless I have a pile of evidence. :-)<p>&gt; ...btrfs wants a special degraded remount that might or might not be able to recover to rw someday... replacing a disk online is not really possible.<p>But, from the email you quoted:<p>&quot;...while btrfs raid will often let you recover from a bad device, <i>sometimes</i> that recovery is in the form of letting you mount ro, so you can access the data and copy it elsewhere, before blowing away the filesystem and starting over.&quot;<p>And [0] indicates that you <i>can</i> live-replace a failed drive in a btrfs RAID array. (The man page makes it seem that you might want to also pass the -r flag to the replace operation.)<p>I&#x27;ve never had the money around to amass the disks required to run my btrfs array in RAID1 data mode, so I can&#x27;t test the claim of that Stack Overflow post, but I <i>do</i> use it in <i>single</i> data, <i>RAID1</i> metadata and system mode. I&#x27;ve had a drive in that array suddenly drop out due to a firewire controller hiccup, and I suffered <i>no</i> data loss. (The volume did get forced into ro mode, so future writes <i>were</i> lost, but all applications <i>knew</i> that those writes were lost.)<p>Additionally, I&#x27;ve been able to live-add and live-remove drives from my array with <i>no</i> hassle (other than the expected speed degradation due to shuffling the data around) whatsoever.<p>&gt; ...so RAID1 doubles [read] throughput. Well not on btrfs.<p>Maybe I&#x27;m out of the loop, but I&#x27;ve <i>never</i> heard anyone say &quot;use RAID1 to double your read throughput&quot;. That sounds like a <i>very</i> nice thing to have, but far from essential. Its absence <i>certainly</i> doesn&#x27;t make btrfs&#x27;s RAID1 implementation <i>broken</i>. :)<p>&gt; Umounting and running btrfs --check repair is not really cool if you want some uptime...<p>Agreed, <i>very</i> much so.<p>One thing bothers me about that guy who was reporting the bug on the 4.1 kernel. He claimed that his mount options were:<p><pre><code>    &#x2F;dev&#x2F;sdb &#x2F;media&#x2F;storage2 btrfs ro,noatime,compress=lzo,space_cache 0 0
</code></pre>
but the issue he was reporting <i>smelled</i> like it could only happen on a rw volume. Wonder what was up with that.<p>It&#x27;s <i>also</i> interesting that noone replied to his messages. Both linux-btrfs and #btrfs have always been quite responsive when I&#x27;ve sent messages.<p>&gt; 4x4TB RAID10 (90% free) -&gt; ENOSPC - this was somehwere between 3.16 or 3.19 - how can this even happen?<p>Dunno. It looks like the Global Reserve got introduced in ~3.16, so it&#x27;s not likely related to that. Maybe you hit a hard-link limit or had <i>really</i>, <i>really</i> large xattrs attached to files or something? (I <i>do</i> know that btrfs has (had?) a <i>surprisingly</i> low limit on the number of hard links supported in a volume, but I have <i>no</i> idea how hitting that limit presents itself.)<p>Do you remember if you let the system idle for a few minutes and tried your operation again? (Not that that&#x27;s a reliable [or even reasonable] solution, mind, but does provide a useful piece of diagnostic info.)<p>In the <i>distant</i> past, running a balance on empty chunks (in order to free them and free up otherwise unused metadata space) was one recommended way to work around mysterious ENOSPC issues. This isn&#x27;t <i>supposed</i> to be required anymore, but it&#x27;s a last-ditch cargo-cult thing that can&#x27;t do anything worse than waste one&#x27;s time.<p>&gt; Good for you. Was hit by this nasty undeletable directory bug...<p>That <i>seriously</i> sucks. However, I don&#x27;t call that data corruption. Inconvenient, bordering on unacceptable? Yes. Data corruption? Nah. Your <i>data</i> is still present and <i>correct</i>, but you can&#x27;t get rid of some directories. [1]<p>&gt; Currently btrfs deadlocks reliable in a OOM situation... With 4.2 things got better...<p>Is it <i>any</i> OOM situation, or just <i>particular</i> ones? I know that I&#x27;ve had google-chrome + Hangouts run away and nom all my memory on <i>multiple</i> occasions, and had my btrfs volumes function just fine after the OOM killer had its way with Chrome.<p>Also, do you have a handle on <i>roughly</i> how much better it has become in 4.2, and is this problem something that the btrfs folks are aware of?<p>&gt; [btrfs is] probably fine for personal use. But don&#x27;t think about using it for something that is demanding.<p>That&#x27;s a <i>far</i> softer statement than &quot;btrfs is a shitshow ... I will refrain from using it ever again if I have a choice.&quot;. :)<p>Anyway, I <i>do</i> <i>REALLY</i> hope I soon get the budget to set up a btrfs testbed. I&#x27;d <i>really</i> like to see (and help diagnose) all these failures that people keep talking about... in a carefully controlled environment, with data that I don&#x27;t care about -naturally-. :)<p>[0] <a href="http:&#x2F;&#x2F;superuser.com&#x2F;questions&#x2F;685364&#x2F;can-a-failed-btrfs-drive-in-raid-1-be-replaced-live" rel="nofollow">http:&#x2F;&#x2F;superuser.com&#x2F;questions&#x2F;685364&#x2F;can-a-failed-btrfs-dri...</a><p>[1] And -for the record- I saw an <i>eerily</i> similar thing happen <i>every other month</i> at a Windows-only programming shop I used to work for. One or more files and&#x2F;or directories on the NTFS-backed Windows 2003 file server would <i>inevitably</i> become undeletable. [2] The sysadmin would have to take the whole thing down for a half hour to smear chicken guts in the right places to get rid of the offending files&#x2F;directories. Despite these <i>regular</i> issues, we never decided to stop using NTFS. ;)<p>[2] And no, <i>noone</i> who was using the file server had admin access. Unprivved user access was all that was needed to create these undeletable files and directories.