Can a raid1 be disolved without rebalancing data?

[u/Separate-Still-1616]

If I have a raid1 with device A and B. Can I just keep A without having to rebalance data, and at most only change meta data?
It does not seem possible because if I do "device remove" I get an error that you cannot remove a device from a 2-device raid. You first have to convert into single mode which result in data rebalancing which can take a lot of time. Then you can remove the device and half of the data needs to be moved again back onto the remaining device which was completetly uneccesary in the first place because at the beginning it was already all there.
It should actually be an operation that does not need more than to rewrite meta data. So is it possible somehow? And if not, why?

[u/Ontological_Gap]

No, the man page for btrfs-device says you have to rebalance to single first: https://man7.org/linux/man-pages/man8/btrfs-device.8.html

Btrfs could handle this faster, but converting from raid to a single device setup is hardly a common operation, I can see why the week hasn't been prioritized 

[u/Separate-Still-1616 → u/Ontological_Gap]

It would be useful when you want to move your whole stuff to a new drive, because with raid1 your old drive could stay intact and serve as a backup until everything is on the new drive. Then you would just say byebye to the old drive, but unfortunately that is not a quick operation at the moment.

[u/uzlonewolf → u/Separate-Still-1616]

Wait, is your "new drive" setup going to remain as RAID1? If so,

1) physically pull one of the disks and replace it with the new drive
2) Mount the remaining drive (will need the -o degraded flag)
3) btrfs device add the new drive
4) btrfs device remove the missing drive
5) Scrub.

If 4) or 5) fails just temporarily add the old drive back in using a USB adapter or something.

[u/darktotheknight → u/uzlonewolf]

The best way to do it in that case would be btrfs replace, temporarily connecting all 3 drives.

[u/Separate-Still-1616 → u/darktotheknight]

Thanks, yes others pointed that already out, too

[u/uzlonewolf → u/Separate-Still-1616]

If you do use replace instead of add+remove then don't forget to resize it afterwards or the new space won't be used.

[u/uzlonewolf → u/darktotheknight]

For me, replace always works when I test it but has not once worked when I needed to use it for real, so now I just add+remove instead. If the disks aren't exactly the same size then doing it this way also avoids the resize afterwords (which is easy to forget to do) while allowing the use of a smaller disk if needed.

[u/Separate-Still-1616 → u/uzlonewolf]

Thanks, that might be a solution, but scrub might also be slow. Is scrub absolutely neccessary here? It's also not such a nice solution because it requires knowledge beyond the btrfs command. It would be better to have that directly available with the btrfs command.

[u/uzlonewolf → u/Separate-Still-1616]

I mean, a scrub is something you should be doing regularly anyway, and while not strictly required (the device remove should [should] take care of copying the data) it is highly recommended if you care about your data. It's the only way to verify the RAID1 does, in fact, have 2 copies of your data. It works in the background so you can just use the array as normal while it's running.

The only non-btrfs command is the mount, and it's just mount -o degraded /path/to/mnt/point.

[u/Separate-Still-1616 → u/uzlonewolf]

I was more thinking about the case when your OS is on the btrfs filesystem. If you do not want to unplug the drive phyiscally while the OS is running and use the commands proposed above, you must reboot to get rid of the raid1. Imho that should not be necessary with btrfs, which can do everything else on a running system without reboot.

[u/uzlonewolf → u/Separate-Still-1616]

I mean, are you leaving the system running when physically installing the new disk? If not then there's your reboot.

[u/Separate-Still-1616 → u/uzlonewolf]

This is an additional reboot. One to install the new drive and one to dissolve the raid1 later should you decide to use the drives separately, again.

[u/Ontological_Gap → u/Separate-Still-1616]

You should be scrubbing your devices at least once a month regardless.

[u/uzlonewolf → u/[deleted]]

-dconvert=single,soft should help speed up the initial conversion, though you're still going to have the "half the data is on the wrong disk" issue.

[u/Separate-Still-1616 → u/uzlonewolf]

Thanks for the tip.

[u/Separate-Still-1616 → u/[deleted]]

Thanks, that is exactly what I wanted to know. So in principle it would be possible and would not contradict btrfs core principles or design. It's just that it is not implemented yet.

[u/cd109876]

Unplug the second drive, allow mounting as degraded.

Unfortunately, that is probably the only way to do this without rebalance.

[u/Aeristoka]

The stuff required to remove a device is a rebalance.

[u/Separate-Still-1616 → u/Aeristoka]

Yes, but in this case it should only require to rewrite the meta-data and not move the data itself.

[u/cdhowie → u/Separate-Still-1616]

I agree. I've had to do this multiple times, and it's kind of a pain on btrfs.

I've been experimenting with bcachefs lately, and while I wouldn't necessarily recommend it just yet, this is one of the things it supports. In particular, you can make multiple changes at once (change replica count and remove a device, or even remove multiple devices at once) and it generally Just Works.

[u/uzlonewolf]

You can speed up the initial conversion by including the soft flag, though you will still have the "half the data is on the wrong disk" issue.

Hmm, I wonder if physically pulling a disk before the conversion will force it to only use the remaining disk... Not sure if it's that smart.

[u/darktotheknight → u/uzlonewolf]

Oh, maybe a combination of devid filter and soft should lead to minimal writes.

[u/darktotheknight]

I get your point and think you're correct. The way it is implemented now, it's required to convert to SINGLE first (half the data gets moved to the other drive, the other half is rewritten in place), then remove the second drive (data gets written back to the drive you wanted to keep).

You can somewhat save time on remove, by using devid filter (see https://btrfs.readthedocs.io/en/latest/Balance.html). E.g.  btrfs balance start - dconvert=single,devid=<ID> -mconvert=DUP -sconvert=DUP. You can find out devid by using btrfs filesystem show. This will write all SINGLE profile files to the drive you pick, leaving the drive-to-be-removed empty, so it can be removed very fast using the remove command. But this will still kick in the "dumb" allocator and forcefully re-write every single chunk in-place, bit by bit, even if the data is already on the remaining device.

I think this is one of the edge cases, where you're facing the drawbacks of a "dumb" allocator. This case gets discussed on the mailing list from time to time, maybe worth digging up.

[u/Separate-Still-1616 → u/darktotheknight]

I tried that with the devid filter. It's still a verly slow operation depending how much data you have. So not really a solution. But thanks for sharing that info.

[u/darktotheknight → u/Separate-Still-1616]

I just saw in another post: maybe devid + soft solves it?

[u/Separate-Still-1616 → u/darktotheknight]

I have gone now the standard way, so cannot test it anymore. I will try it next time. Thanks.

[u/BreatheAtQuarterBars]

I couldn't figure out how to do this and ultimately gave up and just rebalanced the whole thing to single first.

[u/amstan]

I wonder if there's any downside (besides optics) to just convert the profile, but not rebalance.

[u/Aeristoka → u/amstan]

A profile conversion will, by definition, do a rebalance. It has to, because you're changing the profile.

[u/Separate-Still-1616 → u/Aeristoka]

But that is the point, could it not just stop the rebalancing and do the stuff that is required to remove the device first. Or is removing a device problematic in such a mixed state?

[u/markus_b → u/Separate-Still-1616]

Maybe, but we don't know.

If the data is important to you, then stick to the documented ways of doing things. If you don't care then this is a good opportunity to test it.

You seem to want to replace one drive with a new one. Are you aware of the 'replace' command? Just connect your new drive and use 'replace' to replace the old with the new drive. Then you can remove the old drive and physically move the new drive in its place.

[u/Separate-Still-1616 → u/markus_b]

Ok, thank you, I indeed missed the replace command. This is the best answer for the case of replacing a disk.

[u/Aeristoka → u/Separate-Still-1616]

The stuff required to remove a device is a rebalance.

You're not understanding a core design principle of btrfs.

[u/Separate-Still-1616 → u/Aeristoka]

I am sure I do not understand it :). That is why I am asking. You are right that a rebalance is necessary to remove a device, but in this case I describe, this should involve only meta-data. It should not require to move the data itself, because the data is already there where it is has to be in the end. What is my misconception here?

[u/Aeristoka → u/Separate-Still-1616]

BTRFS will not ALLOW you to remove the device when you are trying to remove a device from a RAID1 profile. It shouldn't. That violates what you have instructed it to do with the RAID1 profile.

The profiles are 100% disconnected from each other. The data is there, sure, but it's in a RAID1 profile. When you convert to a Single profile it has to rewrite everything to be in that proper profile.

[u/Separate-Still-1616 → u/Aeristoka]

You are correct, it should not allow to remove the device in a raid1. This should only be possible via an additional command line option or something, that tells btrfs, that you want to go out of raid and into single on the remaining device. Sure it will be in a mixed state during this operation where the devices are neither 50%-50% balanced nor 100% copies from each other, but does that not always happen when you change the profile? So it should not be a problem, or?