Re: how to clone a btrfs filesystem

[Duncan <1i5t5.duncan@cox.net>]

Christoph Anton Mitterer posted on Sun, 19 Apr 2015 22:00:24 +0200 as
excerpted:

> Most of the time, only one of the two disks shows activity, while the
> other is reading respectively writing.
> The CPU isn't really under full load either (not even a single core),...
> it's rather in the 5-10% utilisation.
> The resulting transferspeed is about 21,5 MB/s (not MiB).
> Seems to be pretty low...

In general, btrfs hasn't really been optimized yet.  One of the more 
obvious cases of this is the btrfs raid1 mode read case, where the read-
scheduling algorithm is simple even/odd based on the PID, which means a 
single read thread will bottleneck on a single device, even if the other 
one is totally idle.

That's the biggest "forget optimization, 50% utilization is the best-case 
as we're not yet optimizing" example out there, AFAIK.

Which, given the common developer wisdom about premature optimization, 
can be explained.  But accepting that explanation, one is still stymied 
by the fact that all the previous warnings about btrfs being in heavy 
development, keep good backups and be prepared to use them, etc, are 
being stripped, because btrfs is supposedly ready for normal use now.  
But if it's ready for normal use, why isn't it optimized for normal use, 
then?  And if it's not ready for normal use, why are the warnings 
actually telling people that being prematurely stripped?

IMO, therefore, a major btrfs development milestone will be when they 
decide development has stabilized enough that it's time to actually 
optimize these things for production use, and that doing so is no longer 
"premature optimization", because the filesystem is mature and its 
methods stable enough that optimization is no longer premature.  Once 
/that/ happens, arguably then, and /only/ then, can /real/ discussion 
start on whether/when btrfs is /truly/ mature and stable.

Until that optimization, then, the clear answer is that btrfs is not yet 
stable, because developers are demonstrating by their failure to 
optimize, that they don't consider the filesystem mature and stable 
enough for it yet, such that any major effort at optimization (as opposed 
to simply taking the opportunity when it presents itself as the most 
sensible option) is premature.

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