On 09/26/2015 02:45 PM, Carlos E. R. wrote:
Unfortunately, I still do not trust btrfs.
There are a few architectural assumptions in BtrFS. Whether they were made consciously and explicitly, I don't know. The idea of being able to support, spread a FS across multiple spindles in te various modes of striping & mirroring etc is not unique to btrFS, but there is a feeling of both "One Ring" and "Borg" to it. By comparison I can have different LVs with different strategies using LVM. I'd probably be happier ignoring the features of BtrFS, implement g it as if it were just another FS, and layering it on top of LVM. The "One Ring" aspect of BtrFS means that its efficiency and defectiveness come into play if you don't partition, but rather use subvolumes. its till the one file system, the subvolumes are just there to help with management They are not really partitions. This runs counter to previously established *NIX practices where partitions can be used, for example, to enforce security measures. The /tmp can, for example, be mounted: sticky, noexec, nosetuid. nodev. Preventing hard links across files systems from /sbin to /tmp or /home is another simple, well established precaution. These many not matter in a home setting, but then again BtrFS is being pitched at large production systems; its is the default in SLES12, for example. To my mind the issue isn't so much potential bugs in BtrFS; we can expect those in any 'in development' product, and BtrFS is walking the same path that KDE4.0 did :-( And of course it is by the very nature of the way it has been specified, an ambitious, large and complex piece of software. I've been running BtrFS as my ROOTFS for almost a year with negligible problems, but then again I haven't stressed it or exercised its capability. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org