You are not logged in.
Dear community,
I have recently added a new hard drive to my existing btrfs setup:
Previous configuration:
2x 20TB, Data: raid1, metadata: raid1 (side note: the "devices" that btrfs uses are dm-crypt volumes - but this should not matter for this question)
To add the new 24TB drive, I did the following:
btrfs device add "new dm-crypt device" "btrfs volume mount point"
btrfs balance start -dconvert=raid1 -mconvert=raid1c3 --enqueue "btrfs volume mount point"
This worked flawlessly. The balance was starting fine (although quite slow) for both data and metadata, i.e. the data started to be distributed to the newly added device (profile Raid1 remained) and the metadata started conversion from raid1 to raid1c3.
At some point, I unfortunately needed to reboot the system, and alongside this reboot the kernel was switched (6.12.6 --> 6.12.7).
To reboot, I did the following:
btrfs balance pause "btrfs volume mount point"
reboot
Due to the documentation on Arch btrfs-balance man page, I expected that the balance is just continuing after the volume get auto-mounted at boot.
However, what I noticed was, that only the metadata conversion from raid1 to raid1c3 was continuing, the data chunks did not get further balanced although they were by far not yet evenly distributed to the three devices. I noticed this as the used data space on the new drive did not increase
Furthermore, I noticed the following line in dmesg output:
[ 161.951728] BTRFS info (device dm-2): balance: resume -dconvert=raid1,soft -mconvert=raid1c3,soft -sconvert=raid1c3,soft
My question is now if I misunderstood the documentation of btrfs-balance resume:
Expectation: the balance is resuming from where I paused and the data chunks get distributed to the new device as well
Reality: only the metadata conversion of the not-yet raid1c3 chunks resumed until all raid1 metadata was converted to raid1c3
The reality seems to be exactly what the dmesg output line expresses - the "soft" filter means no chunks that already fulfill the desired profile are touched.
--> Is simly my understanding of pause/resume wrong, or is this somehow a "bug" in the resume process?
I guess for this kind of "resume", also the "state" of the balance would not have needed to be saved to the filesystem at pause time.
Thank you very much in advance for your replies.
Excerpts from the btrfs-balance man page:
...
pause <path>
pause running balance operation, this will store the state of the balance progress and used filters to the filesystem
resume <path>
resume interrupted balance, the balance status must be stored on the filesystem from previous run, e.g. after it was paused or forcibly interrupted and mounted again with skip_balance
...
soft
Takes no parameters. Only has meaning when converting between profiles, or When doing convert from one profile to another and soft mode is on, chunks that already have the target profile are left untouched. This is useful e.g. when half of the filesystem was converted earlier but got cancelled.The soft mode switch is (like every other filter) per-type. For example, this means that we can convert metadata chunks the "hard" way while converting data chunks selectively with soft switch.
...
Last edited by Nox997 (2024-12-30 08:57:39)
Offline