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

[Alexander Tomokhov]

Yeah, thank you for suggestion. Bcache is what I actually use right now. 
However it's concept is different, operating at block/bucket level and requires 
another (underlying!) layer.

06.02.2017, 01:27, "Kai Krakow" :
> Am Mon, 06 Feb 2017 00:42:01 +0300
> schrieb Alexander Tomokhov :
>
>>  Is it possible, having two drives to do raid1 for metadata but keep
>>  data on a single drive only? --
>
> No, but you could take a look into bcache which should get you
> something similar if used in write-around mode.
>
> Random access will become cached in bcache, which should most of the
> time be metadata, plus of course randomly accessed data from HDD. If
> you reduce the sequential cutoff trigger in bcache, it should cache
> mostly metadata only.
>
> --
> Regards,
> Kai
>
> Replies to list-only preferred.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majord...@vger.kernel.org
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alexander Tomokhov]

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" :
> On Sun, 5 Feb 2017 22:55:42 +0100
> Hans van Kranenburg  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,
> _offset, _avail);
>
> --
> With respect,
> Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Omar Sandoval]

On Mon, Feb 06, 2017 at 12:42:01AM +0300, Alexander Tomokhov wrote:
> Is it possible, having two drives to do raid1 for metadata but keep data on a 
> single drive only?

Chris had a patch for doing basically this that we were testing
internally, but I don't think he ever sent it to the mailing list.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Austin S. Hemmelgarn]

On 2017-02-05 23:26, Duncan wrote:

Hans van Kranenburg posted on Sun, 05 Feb 2017 22:55:42 +0100 as
excerpted:


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...


FWIW, it's on the list to be implemented in the future, but there's a lot
more things on that list than devs working on btrfs, and the feature
development and stabilization trend is that features often take much
longer than anticipated, particularly to properly stabilize (to the level
of the rest of btrfs, which is in general stabilizing but not yet fully
stable, so stabilization is relative, here), which has slowed down the
pipeline of new features due to the devs having their hands full
stabilizing currently done but not yet properly stabilized features.
There are also a number of higher priority features than this.  While it 
would be a wonderful feature to have, it doesn't exactly have a 
particularly significant impact on broad usability.  Most of the 
features being actively worked on are trying to gain parity (no pun 
intended) with other multi-device storage stacks.  Working quotas, 
parity-RAID, hot-spares, and n-way replication are all pretty 
significant to the usability of BTRFS in a pretty large number of 
situations, which is a large part of why they (other than n-way 
replication) are the primary focus right now for development.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Duncan]

Hans van Kranenburg posted on Sun, 05 Feb 2017 22:55:42 +0100 as
excerpted:

> 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...

FWIW, it's on the list to be implemented in the future, but there's a lot 
more things on that list than devs working on btrfs, and the feature 
development and stabilization trend is that features often take much 
longer than anticipated, particularly to properly stabilize (to the level 
of the rest of btrfs, which is in general stabilizing but not yet fully 
stable, so stabilization is relative, here), which has slowed down the 
pipeline of new features due to the devs having their hands full 
stabilizing currently done but not yet properly stabilized features.

So if they're not working on it yet, chances are it's going to be at 
/least/ three years to usably stable, and realistically, they may not 
even start working on it until perhaps 5-7 years out, so it could easily 
be another decade out for such a feature to properly stabilize.

And given that the practical forecast horizon for free software is around 
five years, because enough unexpected happens in that time to make trying 
to predict in any worthwhile detail further out pretty much a fool's 
errand, effectively, it's at or outside the prediction horizon, so in 
practice, there's no telling /when/ it might be implemented and then 
stabilized enough to use, only that it /is/ on the list for "someday".

Meanwhile, FWIW, my feature of choice, N-way-mirroring, has long been 
scheduled for "right after raid56 mode".  Well, raid56 mode first wasn't 
introduced until long after originally scheduled (3.6 or earlier), then 
when it was it was runtime-only, the maintenance and recovery tools 
weren't there yet, then something like two years later they were ready so 
it was in theory feature-complete (in 3.19) but not yet stabilized, then 
in the stabilization process, some serious implementation bugs were found 
such that it can't yet be recommended and may yet require a full 
rewrite... so I'm still waiting for N-way-mirroring, which was supposed 
to follow shortly after raid56 mode.

And given that raid56 mode might now take another couple years to 
stabilize (and it could be longer than that), I'm not expecting N-way-
mirroring for another three years or so, so even it could well be five 
years out to usable stability.  And it has long been at least in the 
known queue for after raid56 mode, and hasn't really been even started 
yet, so features on the list, but not yet actually on the queue, again, 
who knows, but five years out at least is a reasonable bet, and that's 
prediction horizon, so indeed, there's no way to really even predict, at 
this point.

But I do know all about waiting, by now.  I've learned, and am continuing 
to learn, all about patience! =:^]

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Roman Mamedov]

On Sun, 5 Feb 2017 22:55:42 +0100
Hans van Kranenburg  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,
   _offset, _avail);


-- 
With respect,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Kai Krakow]

Am Mon, 06 Feb 2017 00:42:01 +0300
schrieb Alexander Tomokhov :

> Is it possible, having two drives to do raid1 for metadata but keep
> data on a single drive only? --

No, but you could take a look into bcache which should get you
something similar if used in write-around mode.

Random access will become cached in bcache, which should most of the
time be metadata, plus of course randomly accessed data from HDD. If
you reduce the sequential cutoff trigger in bcache, it should cache
mostly metadata only.

-- 
Regards,
Kai

Replies to list-only preferred.

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Hans van Kranenburg]

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...

-- 
Hans van Kranenburg
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Alexander Tomokhov]

Is it possible, having two drives to do raid1 for metadata but keep data on a 
single drive only?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html