> -----Original Message----- > From: linux-btrfs-owner@xxxxxxxxxxxxxxx <linux-btrfs- > owner@xxxxxxxxxxxxxxx> On Behalf Of Marc MERLIN > Sent: Tuesday, 3 July 2018 1:19 AM > To: Qu Wenruo <quwenruo.btrfs@xxxxxxx> > Cc: Su Yue <suy.fnst@xxxxxxxxxxxxxx>; linux-btrfs@xxxxxxxxxxxxxxx > Subject: Re: how to best segment a big block device in resizeable btrfs > filesystems? > > Hi Qu, > > I'll split this part into a new thread: > > > 2) Don't keep unrelated snapshots in one btrfs. > > I totally understand that maintain different btrfs would hugely add > > maintenance pressure, but as explains, all snapshots share one > > fragile extent tree. > > Yes, I understand that this is what I should do given what you explained. > My main problem is knowing how to segment things so I don't end up with > filesystems that are full while others are almost empty :) > > Am I supposed to put LVM thin volumes underneath so that I can share the > same single 10TB raid5? > > If I do this, I would have > software raid 5 < dmcrypt < bcache < lvm < btrfs That's a lot of layers, and > that's also starting to make me nervous :) You could combine bcache and lvm if you are happy to use dm-cache instead (which lvm uses). I use it myself (but without thin provisioning) and it works well. > > Is there any other way that does not involve me creating smaller block > devices for multiple btrfs filesystems and hope that they are the right size > because I won't be able to change it later? > > Thanks, > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet cooking > Home page: http://marc.merlins.org/ | PGP 7F55D5F27AAF9D08 > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the > body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at > http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
