On Sun, Dec 20, 2015 at 6:25 AM, <[email protected]> wrote: > > When I did try it just that way, it failed completely. I created the > structure, except that I put quotas on each of the subvolumes, and then > I rsynced the files from my non-btrfs copies which I had to do offline > using my grml cd, and when I rebooted back into the new arrangements, it > was a mess. I also got advice from their mailing list that I might want > separate pools and this is why I was wondering about lvm, since I don't > want partitions again. >
I'd probably avoid the quotas for the moment. I believe they were broken in some of the most recent kernels (which is why I've stopped running the most recent kernels on btrfs, I'm sure they'll get it sorted eventually). Unless you REALLY need the quota support I'd just put everything in one big filesystem and not run on top of LVM. There are many things that could have gone wrong in your migration. Unless you've identified what exactly it was, you're going to take the risk that by installing LVM you still haven't fixed whatever went wrong the first time, and you'll have less flexibility to address issues in the future. But, other than flexibility I don't think there are any issues with using btrfs on top of LVM. If you're using btrfs's raid capabilities then I'd set up a different LVM volume group for each device so that btrfs doesn't inadvertently store redundant copies on the same device. That would be the opposite of how you'd normally use LVM, and just one more reason not to use it. Personally, I don't try to use separate filesystems for /var, /usr, and so on. It just fragments your free space and becomes a headache to manage. I could maybe see having a separate filesystem for /usr if it were read-only and signed/verified, or for etc if it was a tmpfs, and so on. -- Rich
