Sergio Belkin wrote:
So, let's say we have 3 small disks: 4GB, 3G, and 2GB.
If I create one file of 3GB I think that
3 GB is written on 4GB disk, it leaves 1 GB free.
3 GB of copy is written on 3 GB disk, it leaves 0 GB Free.
So, I create one file of 1GB that is written on 4GB disk, it leaves 0 GB
free.
1 GB of copy is written on 2 GB disk, so it leaves 1 GB free.
So I've used 4GB, ok it leaves 1 GB free on only one disk, but cannot be
mirrored.
However as [1] I could use 4.5 ((4GB+3GB+2GB)/2) GB instead of 4GB.
Surely, I'm missing or mistaking something.
Please could you help me?
The optimum size can theoretically be achieved by using the following
physical partitioning:
* x GB on the 4 GB disk and the 3 GB disk,
* y GB on the 4 GB disk and the 2 GB disk, and
* z GB on the 3 GB disk and the 2 GB disk,
for a total of x+y+z GB, where x, y, and z solve the following system of
equations:
* x+y=4
* x+z=3
* y+z=2
i.e., in standard form:
* 1x+1y+0z=4
* 1x+0y+1z=3
* 0x+1y+1z=2
The determinant of this system is -2, which is not 0, so this system admits
a unique solution. It can be computed using any method to solve linear
systems of equations, such as direct substitution (solving an equation for a
variable and substituting it), Gauss elimination with back substitution,
Gauss-Jordan (bidirectional) elimination, or Cramer's rule. The result is:
* x=2.5
* y=1.5
* z=0.5
for a total of x+y+z=2.5+1.5+0.5=4.5 GB.
Now how btrfs actually handles this in practice is a different story.
Judging from Chris Murphy's reply, it does not precompute the above
repartition, but tries to dynamically select 2 disks for each newly
allocated 1 GB block to approximate the optimal solution for large enough
drives (which will not achieve the optimum for the sizes in your example
because the optimum allocation is not an integer amount of gigabytes, and
will in fact be pretty far from the optimum due to the small sizes, whereas
the larger the disk sizes, the less noticeable the loss is).
Kevin Kofler