This is an RFC; I wrote this patch because I find the idea interesting even though it adds more complication to the chunk allocator. The core idea is to store the metadata on the ssd and leave the data on the rotational disks. BTRFS looks at the rotational flags to understand the kind of disks. This new mode is enabled passing the option ssd_metadata at mount time. This policy of allocation is the "preferred" one. If this doesn't permit a chunk allocation, the "classic" one is used. Some examples: (/dev/sd[abc] are ssd, and /dev/sd[ef] are rotational) Non striped profile: metadata->raid1, data->raid1 The data is stored on /dev/sd[ef], metadata is stored on /dev/sd[abc]. When /dev/sd[ef] are full, then the data chunk is allocated also on /dev/sd[abc]. Striped profile: metadata->raid5, data->raid5 raid5 requires 3 disks at minimum, so /dev/sd[ef] are not enough for a data profile raid5. To allow a data chunk allocation, the data profile raid5 will be stored on all the disks /dev/sd[abcdef]. Instead the metadata profile raid5 will be allocated on /dev/sd[abc], because these are enough to host this chunk. NOTE1: I don't touch the mkfs.btrfs program, so the new policy will be applied only to the next chunk allocation. If you want to allocate properly the chunk created by mkfs.btrfs, a btrfs balance is required. NOTE1: I made only few tests. Don't use for valued data BR G.Baroncelli
