Hacker News Reader

Comment by jeroenhd | Hacker News Reader

I believe that is also the method [btrfs-convert](https://btrfs.readthedocs.io/en/latest/Convert.html) uses. A cool trick that tool uses is to keep the ext4 structures on disk (as a subvolume), which allows reverting to ext4 if the conversion didn't go as planned (as long as you don't do anything to mess with the ext4 extents, such as defragmenting or balancing the filesystem, and you can't revert after deleting the subvolume of course).

View on HN

I tried that on a system in 2020 and it just corrupted my new FS. Cool idea though.

My conversion went fine, but there were so many misaligned sectors and constant strange checksum errors (on files written after the conversion). With the cherry on top being that if there’s more than X% of checksum errors, btrfs refuses to mount and you have to do multiple arcane incantations to get it to clear all its errors. Real fun if you need your laptop for a high priority problem to solve.

Lesson learned: despite whatever “hard” promises a conversion tool (and its creators) make, just backup, check the backup, then format and create your new filesystem.

I've never had the conversion corrupt a filesystem for me (plenty of segfaults halfway through, though). It's a neat trick for when you want to convert a filesystem that doesn't have much on it, but I wouldn't use it for anything critical. Better to format the drive and copy files back from a backup, and you probably want that anyway if you're planning on using filesystem features like snapshots.

Windows used to feature a similar tool to transition from FAT32 to NTFS. I'd have the same reservations about that tool, though. Apple also did something like this with an even weirder conversion step (source and target filesystem didn't have the same handling for case sensitivity!) and I've only read one or two articles about people losing data because of it. It can definitely be done safely, if given enough attention, but I don't think anyone cares enough to write a conversion tool with production grade quality.

You don't understand. You did get a btrfs that worked normally. /s

I believe you are right. You can only convert back to the metadata from before. So any new or changed (different extents) files will be lost or corrupted.

So best to only mount ro when considering to rollback. Otherwise it's pretty risky.

No, it also covers the data. As long as you don't delete the rollback subvolume, all the original data should still be there, uncorrupted.

Even if you disable copy-on-write, as long as the rollback subvolume is there to lay claim to the old data, it's considered immutable and any modification will still have to copy it.

I understood it as "it doesn't touch/ignore the data". But I guess we mean the same thing.

You are right. All of the old files will be in areas btrfs should consider used. So it should correctly restore the state from before the migration. Thanks!

Reply on news.ycombinator.com