cosmos72
commented
6 years ago Hello @rcombs
Yes, the main drawback of fstransform is the long time conversion takes.
Your idea would help in this respect, only I think it's a LOT of work and requires intimate knowledge of the target file system. For example, btrfs has such a tool, maintaned by btrfs authors themselves.
Unluckily, I do not have the resources to embark upon such a task in my spare time.
Some time ago I started a different (and hopefully much lighter) approach to speed up fstransform: Currently, fstransform copies each file twice: once by fsmove inside a huge loop-mounted file, and once by fsremap to its final position. Using minimal file system knowledge, it is possible to move each file only once: fsmove will only preallocate blocks for the file inside the huge loop-mounted file, and fsremap will move each file directly from the initial file system to its final position, then remove the preallocate bit from file's inode.
The fact that this improvement is not yet finished, can give you an idea of my limited time.
macOS 10.13 converts HFS+ volumes to APFS automatically, by default, in-place, and quickly during installation. My understanding is that it does this by rewriting the filesystem data, without actually changing the files' positions on-disk. I'm not sure if this is practical for all possible FS switches (differences in block size, alignment requirements, fragmentation capabilities, etc), but I would expect it should be at least for some, and that the approach should improve performance on almost any filesystem if applied per-file.
This approach has the disadvantage of requiring much more filesystem-specific handling (possibly enough to make the endeavor impractical), but the advantage of being much faster, and potentially safer: since only the filesystem structure is modified, it can be backed up ahead of time using little space, and restored if necessary.