On Sun, Dec 03, 2017 at 01:45:45 +0000, Duncan wrote: > OTOH, it's also quite possible that people chose btrfs at least partly > for other reasons, say the "storage pool" qualities, and would rather
Well, to name some: 1. filesystem-level backups via snapshot/send/receive - much cleaner and faster than rsyncs or other old-fashioned methods. This obviously requires the CoW-once feature; - caveat: for btrfs-killing usage patterns all the snapshots but the last one need to be removed; 2. block-level checksums with RAID1-awareness - in contrary to mdadm RAIDx, which chooses random data copy from underlying devices, this is much less susceptible to bit rot; - caveats: requires CoW enabled, RAID1 reading is dumb (even/odd PID instead of real balancing), no N-way mirroring nor write-mostly flag. 3. compression - there is no real alternative, however: - caveat: requires CoW enabled, which makes it not suitable for ...systemd journals, which compress with great ratio (c.a. 1:10), nor for various databases, as they will be nocowed sooner or later; 4. storage pools you've mentioned - they are actually not much superior to LVM-based approach; until one could create subvolume with different profile (e.g. 'disable RAID1 for /var/log/journal') it is still better to create separate filesystems, meaning one have to use LVM or (the hard way) paritioning. Some of the drawbacks above are immanent to CoW and so shouldn't be expected to be fixed internally, as the needs are conflicting, but their impact might be nullified by some housekeeping. -- Tomasz Pala <go...@pld-linux.org> -- 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