On Wed, Mar 16, 2016 at 6:55 AM, Anton Aylward <opensuse@antonaylward.com> wrote:
On 03/15/2016 02:46 PM, Carlos E. R. wrote:
With btrfs subvolumes you do nothing. There are no constraints on the size of any of them, as long as there is free space on the big partition.
That's the whole point: with BtrFS there is *no* partitioning, its all one file system. There are no boundaries.
Sorta mostly true but there is a distinction with subvolumes. They are a different file system tree, and in that sense is characteristic of a separate volume. For example you can have duplicate inodes on Btrfs. A particular inode number will appear only one time in a subvolume, but it can (and does) appear multiple times on a file system. And because of this you can't make hard links across subvolume boundaries, just like you can't hard link between two XFS volumes; and you can't do --reflink copies (presently) across subvolumes unless you use a fully qualified path from the top level (ID 5) subvolume. So there are some boundaries, they're just not identical to the boundaries we're used to. Subvolumes have other advantages also including send/receive: incremental send/receive produces a received subvolume that represents the entire current state of the sent subvolume (all files) even though it was an incremental send - due to shared extents.
If you don't think there should be constraints, then why don't you try driving just anywhere on the roadways, ignore signs and traffic lights? Constraints are what make things work well.
Blanket arguments are fun, because they're easy to turn around. OS X is very constrained, and even more constrained is iOS. Do they work well? In many ways yes, in other ways not.
Of course it has caveats. If there is corruption, all of them are affected, for instance. LVM also has caveats: it can break, and if it does you need to understand how to boot and rescue LVM.
Yes, anything can break. The problems I've had with LVM I've always traced down to disk hardware and would have afflicted BtrFS as well. The days of simple bad sectors are past, the drive electronics has 'modules' that take care of remapping ... until it all gets overwhelming.
Drives, especially flash, can and do return what it thinks is completely valid data, not a bad sector, but is actually not correct. And of all the Linux fs's, only Btrfs will prevent corrupt data from getting to user space (or actually even earlier, it's stopped in kernel code.) The exact path to the affected file is listed in kernel messages. LVM doesn't do this. There are all sorts of reasons how this is possible, torn writes, redirected writes, and so on, nothing else will see this. XFS v5 now has metadata checksumming, so it's improved, but data is not checksummed.
There's a lot of "yes it used to be but we changed all that" in late model disk drives. The last time I had a catastrophic disk failure the manufacturer techs gave me a long and detailed explanation of how things now work and why the 'crash' I had was unrecoverable -- no matter what, and regardless of the file system.
Btrfs doesn't work miracles. It's not going to recover data the drive itself considers corrupt. The thing Btrfs does is know when corruption has happened and the drive doesn't know it. It can happen outside of the drive, in cable connectors, or the controller.
I've posted before about the use of the rescue disk and chroot to do repairs. it works for LVM as well. I've had file system wipe-outs with BtrFS that were unrecoverable, but no problem with ReiserFS has ever been unrecoverable. LVM also seems to be 'self repairing' in that its internal links and pointers lets the tools recover the structure correctly.
Conventional linear LVM is like partitioning. It works by deduction, there really aren't any pointers until you start using snapshots and then things can get tricky and slow in a big hurry. The new LVM thin provisioning stuff is even more tricky, where there are lots of pointers and separate metadata pools, and separate repair tools that I would call distinctly non-obvious and non-trivial to use and works in progress. I've intentionally blown up thin provisioning volumes numerous times in ways I've never been able to do with Btrfs short of overwriting superblocks and wholesale sabotage. So I would not say LVM is bullet proof or easy to manage in comparison to Btrfs. However what makes a huge difference is familiarity. You'll naturally favor that with which you are familar. I see LVM as emacs, there's just too much going on and as yet it still doesn't have all the raid features found in mdadm. Nevertheless, LVM is badass, I just prefer to use Btrfs 95% of the time and use LVM mainly because it makes certain kinds of tests easier than qcow2 or loop mounted image files. We're fortunate to have many choices. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org