On 08/05/2016 02:12 PM, Austin S. Hemmelgarn wrote: > If you stick to single disk
We do, all our btrfs filesystems reside on one single block device, redundancy is provided by a DRBD layer below. > don't use quota groups We don't use any quotas. > stick to reasonably sized filesystems (not more than a few TB) We do, currently 4 TB max, because that's the only way to utilize different physical storage devices for different filesystem instances such that we can backup them in parallel within reasonable time. > and avoid a couple of specific unconventional storage configurations below it Configurations like what? > The whole issue with > databases is often a non-issue for desktop users in my experience Well, try a "cat" on a sqlite file that has been used by some ordinary desktop software (like a browser) for a year - and you'll experience horrible performance, due to the extreme amount of fragments. (Having to manually "de-fragment" a filesystem periodically is something that I had considered a thing of the past when I started using BSD's hfs instead of the Amiga FFS in the late 1980s... ;-) > and if you think VM image > performance is bad, you should really be looking at using real block storage instead of a file > (seriously, this will usually get you a bigger performance boost than using ext4 or XFS > over BTRFS as an underlying filesystem will). Sure, assigning block devices to each VM would be even better, but also much less convenient for operations. It's a feature here that any user can start a new VM instance (without root privileges) at any time, and that the images used by those VMs are part of the incremental backup that stores only differences, not "whole files that have been changed". >> We sure do - actually, the possibility to "run daily backups from a >> snapshot while write performance remains acceptable" is the one and >> only reason for me to use btrfs rather than xfs for those $HOME dirs. >> In every other aspect (stability, performance, suitability for >> storing VM-images or database-files) xfs wins for me. >> And the btrfs advantage "file system based snapshot being more >> performant than block device based snapshot" may fade away >> with the replacement of magnetic disks with SSDs in the long run. > I'm going to respond to the two parts of this separately: > 1. As far as snapshot performance, you'd be surprised. I've got pretty good consumer grade SSD's > that can do a sustained 250MB/s write speed, which means that to be as fast as a snapshot, > the data set would have to be less than 25MB No, I'm talking about LVM snapshots, which utilitze Copy-On-Write on the block device level. Creating such an LVM snapshot is as quick as creating a btrfs snapshot, regardless of the size. The only significant draw-back of the LVM snapshot is that whenever data is written to the filesystem, that causes copy operations from one part of the (currently magnetic) storage to another part, and that seriously hurts the write performance. (Of course, it would not be a reasonable option to take a block device snapshot by first copying all the data on it.) > 2. As far as snapshots being the only advantage of BTRFS, that's just bogus. > XFS does have metadata checksumming now, but that provides no protection for > data, just metadata. We check for bit-rot on the block device level, DRBD verifies the integrity of the data by reading from both redundant storage devices and comparing the checksums, periodically every week. So far, we never encountered a single bit-rot error, even though the underlying physical storage devices are "cheap SATA disks". > XFS also doesn't have transparent compression support I have no use for that. Disk space is relatively cheap, cheap enough that we don't bother with RAID-5 or such, but use the "full redundancy" provided by a shared-nothing DRBD setup. > filesystems can't be shrunk I enlarged XFS filesystems multiple times while in use, which worked well. I never had to shrink a filesystem, and I cannot imagine how such a use case could occur to me. > and it stores no backups of any metadata except super-blocks. Which is fine with me, as redundancy is provided on the block device level by DRBD. > While the compression and filesystem shrinking may not be needed in > your use case, the data integrity features are almost certainly an advantage. Btrfs sure has some nifty features, and I understand that for some stuff like "subvolumes" or "deduplication" are important. But a hundred great features cannot make up for a lack of stability, therefore I would love to see those ENOSPC-related issues to be resolved rather than more fancy features being built :-) Regards, Lutz Vieweg -- 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
