Thank you. Interesting. At least it's possible to implement in theory. Though, this way metadata-only device is still handled like a casual btrfs device and not distinguished separately from normal data+metadata devices. 06.02.2017, 02:54, "Roman Mamedov" <rm@xxxxxxxxxxx>: > On Sun, 5 Feb 2017 22:55:42 +0100 > Hans van Kranenburg <hans.van.kranenburg@xxxxxxxxxx> wrote: > >> On 02/05/2017 10:42 PM, Alexander Tomokhov wrote: >> > Is it possible, having two drives to do raid1 for metadata but keep data on a single drive only? >> >> Nope. >> >> Would be a really nice feature though... Putting metadata on SSD and >> bulk data on HDD... > > You can play around with this hack just to see how that would perform, but it > comes with no warranty and untested even by me. I was going to try it, but put > it on hold since you'd also need to make sure the SSD is being preferred for > metadata reads (and not HDD), but so far have not figured out a simple way of > ensuring that. > > --- linux-amd64-4.4/fs/btrfs/volumes.c.orig 2016-11-01 22:41:41.970978721 +0500 > +++ linux-amd64-4.4/fs/btrfs/volumes.c 2016-11-01 22:58:45.958977731 +0500 > @@ -4597,6 +4597,14 @@ > if (total_avail == 0) > continue; > > + /* If we have two devices and one is less than 25% of the total FS size, then > + * presumably it's a small device just for metadata RAID1, don't use it > + * for new data chunks. */ > + if ((fs_devices->num_devices == 2) && > + (device->total_bytes * 4 < fs_devices->total_rw_bytes) && > + (type & BTRFS_BLOCK_GROUP_DATA)) > + continue; > + > ret = find_free_dev_extent(trans, device, > max_stripe_size * dev_stripes, > &dev_offset, &max_avail); > > -- > With respect, > Roman -- 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
