Re: btrfs raid1 balance slow

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hmm, for some reason, I did not get the mail from Hugo and Qu (had too look it up in the archive). I think there is a delay when subscribing to the email list.

> Do you have lots of snapshots? It can take a lot of time on some of
the metadata chunks if there's lots of shared extents.

No, I do not have any snapshots. Never made one - just got started with btrfs.
# btrfs subvolume show /export | grep Snap
        Snapshot(s):


> Are you using qgroup?

No, quotas are disabled:
# btrfs qgroup show /export
ERROR: can't list qgroups: quotas not enabled


>Please use kernel newer than v5.2, which contains the optimization.

I'm running 5.4.10-200.fc31.x86_64, that should be good


> Just as Hugo said, cancel the current one, add all device, then rebalance.

Yes, that would be the best. I'm moving data however.. Expand btrfs > move the content of a 2TB disk > use that disk to expand btrfs > move the content of a 2TB disk etc. When this balance is done I'll move 2TB, find a temp drive to store the other 2TB and add the remaining 2 drives in 1 go.

I'm not in a hurry.. just wondering if this is normal. As I had 2x4TB with 150GB free and am adding 1x2TB (~1800GB, ~900 after raid1) I would expect that I will end up with 150+900=1050 GB free (usable), spread like (approx.):
4TB disk 1: 420GB (previously: 75GB)
4TB disk 2: 420GB (previously: 75GB)
2TB disk: 210GB

Thinking very simplisticly -and that's probably where I'm wrong, just wondering if it's a factor 8 wrong- this would mean 420-75 = 345GB read from each 4TB disks and written to the new 2TB disk. At a rate of 20MB/s (pretty conservative, but I do have a little bit of load) this should take like 10 hours. It will, however, at this rate, take approx. 82 hours. Even if all data needs to be read (does it? ~3500GB net) it should only take ~50 hours..

Klaas



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux