* Is it possible to have metadata-only device with no data? @ 2017-02-05 21:42 Alexander Tomokhov 2017-02-05 21:55 ` Hans van Kranenburg ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Alexander Tomokhov @ 2017-02-05 21:42 UTC (permalink / raw) To: linux-btrfs Is it possible, having two drives to do raid1 for metadata but keep data on a single drive only? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is it possible to have metadata-only device with no data? 2017-02-05 21:42 Is it possible to have metadata-only device with no data? Alexander Tomokhov @ 2017-02-05 21:55 ` Hans van Kranenburg 2017-02-05 23:54 ` Roman Mamedov 2017-02-06 4:26 ` Duncan 2017-02-05 22:27 ` Kai Krakow 2017-02-06 18:39 ` Omar Sandoval 2 siblings, 2 replies; 9+ messages in thread From: Hans van Kranenburg @ 2017-02-05 21:55 UTC (permalink / raw) To: Alexander Tomokhov, linux-btrfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is it possible to have metadata-only device with no data? 2017-02-05 21:55 ` Hans van Kranenburg @ 2017-02-05 23:54 ` Roman Mamedov 2017-02-14 1:20 ` Alexander Tomokhov 2017-02-06 4:26 ` Duncan 1 sibling, 1 reply; 9+ messages in thread From: Roman Mamedov @ 2017-02-05 23:54 UTC (permalink / raw) To: Hans van Kranenburg; +Cc: Alexander Tomokhov, linux-btrfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is it possible to have metadata-only device with no data? 2017-02-05 23:54 ` Roman Mamedov @ 2017-02-14 1:20 ` Alexander Tomokhov 0 siblings, 0 replies; 9+ messages in thread From: Alexander Tomokhov @ 2017-02-14 1:20 UTC (permalink / raw) To: Roman Mamedov, Hans van Kranenburg; +Cc: linux-btrfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is it possible to have metadata-only device with no data? 2017-02-05 21:55 ` Hans van Kranenburg 2017-02-05 23:54 ` Roman Mamedov @ 2017-02-06 4:26 ` Duncan 2017-02-06 12:37 ` Austin S. Hemmelgarn 1 sibling, 1 reply; 9+ messages in thread From: Duncan @ 2017-02-06 4:26 UTC (permalink / raw) To: linux-btrfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is it possible to have metadata-only device with no data? 2017-02-06 4:26 ` Duncan @ 2017-02-06 12:37 ` Austin S. Hemmelgarn 0 siblings, 0 replies; 9+ messages in thread From: Austin S. Hemmelgarn @ 2017-02-06 12:37 UTC (permalink / raw) To: linux-btrfs 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is it possible to have metadata-only device with no data? 2017-02-05 21:42 Is it possible to have metadata-only device with no data? Alexander Tomokhov 2017-02-05 21:55 ` Hans van Kranenburg @ 2017-02-05 22:27 ` Kai Krakow 2017-02-14 1:22 ` Alexander Tomokhov 2017-02-06 18:39 ` Omar Sandoval 2 siblings, 1 reply; 9+ messages in thread From: Kai Krakow @ 2017-02-05 22:27 UTC (permalink / raw) To: linux-btrfs Am Mon, 06 Feb 2017 00:42:01 +0300 schrieb Alexander Tomokhov <alexoundos@ya.ru>: > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is it possible to have metadata-only device with no data? 2017-02-05 22:27 ` Kai Krakow @ 2017-02-14 1:22 ` Alexander Tomokhov 0 siblings, 0 replies; 9+ messages in thread From: Alexander Tomokhov @ 2017-02-14 1:22 UTC (permalink / raw) To: Kai Krakow, linux-btrfs@vger.kernel.org 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" <hurikhan77@gmail.com>: > Am Mon, 06 Feb 2017 00:42:01 +0300 > schrieb Alexander Tomokhov <alexoundos@ya.ru>: > >> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Is it possible to have metadata-only device with no data? 2017-02-05 21:42 Is it possible to have metadata-only device with no data? Alexander Tomokhov 2017-02-05 21:55 ` Hans van Kranenburg 2017-02-05 22:27 ` Kai Krakow @ 2017-02-06 18:39 ` Omar Sandoval 2 siblings, 0 replies; 9+ messages in thread From: Omar Sandoval @ 2017-02-06 18:39 UTC (permalink / raw) To: Alexander Tomokhov; +Cc: linux-btrfs, Chris Mason 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-02-14 1:30 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-02-05 21:42 Is it possible to have metadata-only device with no data? Alexander Tomokhov 2017-02-05 21:55 ` Hans van Kranenburg 2017-02-05 23:54 ` Roman Mamedov 2017-02-14 1:20 ` Alexander Tomokhov 2017-02-06 4:26 ` Duncan 2017-02-06 12:37 ` Austin S. Hemmelgarn 2017-02-05 22:27 ` Kai Krakow 2017-02-14 1:22 ` Alexander Tomokhov 2017-02-06 18:39 ` Omar Sandoval
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).