jpsollie
commented
11 months ago Try installing bcachefs tools. It has a bcachefs migrate option to convert in place. Not sure which options are currently supported, but ext4 is definitely one of them
Open TurkeyMan opened 11 months ago
jpsollie
commented
11 months ago Try installing bcachefs tools. It has a bcachefs migrate option to convert in place. Not sure which options are currently supported, but ext4 is definitely one of them
TurkeyMan
commented
11 months ago What about an ext4 raid though? That seems much harder to convert in place... Also doesn't answer anything about bcachefs expansion options?
jpsollie
commented
11 months ago I did not know ext4 supports raid at FS level ... I assume you have a /dev/MD device, you simply keep using it
TurkeyMan
commented
11 months ago Oh yeah, fair point. I was thinking more on btrfs (another parallel thread claims it is also is/intended to be supported).
With bcachefs looking like it may finally land in the kernel soon, and my need to build a new storage pool, I'm keen to lean in on bcachefs for the future. That said, this pool is a bit too active to try it with custom kernels and stuff before it lands in the official distros.
I'm wondering, what is the state of migration options? Is there any possibility to support fs conversion like ext -> btrfs, which can convert in place? In which case, maybe I could create an ext filesystem now, and then convert it when that is working?
Failing that, I'll need to migrate data from one fs to the new one, and I don't have heaps of extra drives to build 2 parallel fs's. I guess I'll need to do a typical juggling act by creating a smaller pool, migrate some data, and then pull drives from the old pool and expand the new one as I go. What is the state of replication and erasure coding migration? How can bcachefs handle a couple of example scenarios: 2-drive, 2x replication (a la raid1) -> 3-drives migrate to 2+1 erasure coding (ie raid5)? Expand parity: 3-disk 2+1 erasure coding -> 2+2 (ie, migrate raid5 -> raid6). Expand stripe width: ie 2+2 -> 4+2?
I suspect that each of these migrations is possible; it may be as simple as updating a piece of config metadata and new data will be written with the new policy, but I suspect existing data to retain its original layout? If this is the case; what is the technique to sweep all data on the disk and rewrite it with the newest policy? For instance, migrating 2x replication to erasure coding may recover a lot of redundant space.
Sorry; several questions in there, but I didn't want to spam the issues tracker... Perhaps this could be published somewhere, as I'm sure these questions will come up again and again as people see that bcachefs is nearing kernel acceptance.