On 05/05/15 15:54, David Sterba wrote: > On Sat, May 02, 2015 at 05:03:31PM +0100, sam tygier wrote: >> Currently BTRFS allows you to make bad choices of data and >> metadata levels. For example -d raid1 -m raid0 means you can >> only use half your total disk space, but will loose everything >> if 1 disk fails. This patch prevents you creating the situation >> another will be need to prevent rebalancing in to it. >> >> When making a filesystem check that metadata mode is at least >> as redundant as the data mode. For example don't allow: >> -d raid1 -m raid0 > > This is enforcing some policty that makes sense for some usecases, but I > think that the tool should be flexible enough to create any kind of raid > profiles. It's up to the user. I'm willing to add a warning that the > profiles seem fishy, but failing mkfs without any way to override that > is IMHO not a good thing. There already seems to be policy in test_num_disk_vs_raid() disallowing DUP for multiple devices. Is there really a useful case better protected data than metadata? In btrfs_balance() fs/btrfs/volumes.c, operations that reduce integrity require a 'force' option. Would that be a good way of handling questionable data/metadata combinations? If so should it overload the existing for option, or additional one, e.g. --force-raid-level? Otherwise I could redo it as just a warning. If wrote a similar check for rebalancing is there a way to share the group_profile_max_safe_loss() function between the kernel and btrfs-progs? Thanks, Sam -- 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
