Simulating disk failure with btrfs single mode
What does the &#x27;single&#x27; profile do in btrfs?<p>I thought it was equivalent to RAID-0 mode, but apparently it isn&#x27;t, because they are separate options and btrfs switched from RAID-0 mode to &#x27;single&#x27; mode by default, although the &#x27;mkfs.btrfs&#x27; man page doesn&#x27;t explain what&#x27;s the difference between them nor why btrfs did that. It has helpful diagrams for the RAID modes, but not &#x27;single&#x27; mode.<p>So how does btrfs allocate data among disks with this profile? This is not explained anywhere I could find. Is it just like concatenating a bunch of disks together?<p>If so, yes, you would expect corrupting a single disk would completely corrupt a corresponding percentage of the files, but almost nothing on others, assuming the files were 1) written perfectly in order (i.e. were not fragmented) and 2) they were filling all of the disks. In this scenario, completely corrupting one of N disks would correspondingly completely corrupt 1&#x2F;Nth of files (approximately speaking).<p>If you were using RAID-0 mode, however, it would be different: it would corrupt almost all (large enough) files, but only 1&#x2F;Nth of their contents.<p>The results, however, could vary a lot depending on how file data actually ends up being allocated on disk, of course.<p>That said, note that the results of this experiment can be completely misleading due to most of the data still being cached in RAM. I would say that to conduct this experiment more meaningfully you should:<p>1. &quot;umount&quot; the filesystem after having written all data to it.<p>2. Corrupt the disk.<p>3. Run &quot;echo 3 &gt; &#x2F;proc&#x2F;sys&#x2F;vm&#x2F;drop_caches&quot; (a couple of times, just in case). This should get rid of the still-cached blocks in RAM, just in case. Or better yet, just reboot your machine :)<p>4. Mount the filesystem and check for corruption.<p>At least, that&#x27;s what you should do if you were performing this test on ZFS, otherwise corrupting the disks would not affect ZFS&#x27;s cache and you wouldn&#x27;t necessarily observe the effects of corruption when accessing the corrupted files normally (i.e. not as part of a scrub).<p>Admittedly, in btrfs this might not be necessary because btrfs&#x27; cached file data might be exactly the same as the underlying disks&#x27; cached blocks. This is not true with ZFS, however, as ZFS&#x27;s caches and the Linux kernel one don&#x27;t share data (at least, not the vast majority of it).<p>It would also be helpful to know the distribution of file sizes that were copied into the filesystem, otherwise the &quot;successfully read the entire file&quot; vs &quot;got an error reading the entire file&quot; statistics are not as helpful as it might seem at first sight (e.g. if there is a significant percentage of very small files).