diff mbox

Is it possible to have metadata-only device with no data?

Message ID 20170206045421.02e18d70@natsu (mailing list archive)
State New, archived
Headers show

Commit Message

Roman Mamedov Feb. 5, 2017, 11:54 p.m. UTC
On Sun, 5 Feb 2017 22:55:42 +0100
Hans van Kranenburg <hans.van.kranenburg@mendix.com> 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.

Comments

Alexander Tomokhov Feb. 14, 2017, 1:20 a.m. UTC | #1
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@romanrm.net>:
> On Sun, 5 Feb 2017 22:55:42 +0100
> Hans van Kranenburg <hans.van.kranenburg@mendix.com> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

--- 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);