Hi Marek, On Thu, Jan 23 2025, Marek Paśnikowski wrote:
> successively transfer parts of the file system tree to new drives With the caveat below, it should be no problem. Unless you use automounts or otherwise rely on entries in /etc/fstab during operation, all drives are mounted at boot---although you may eventually care when at boot. > I use filesystem labels So do I, except on Mdadm component devices. > it is no longer obvious how to design a complex storage solution with > redundancy and replacement of parts. Maybe this example helps. [1] The Guixers also have configurations for machines at the MDC [2] which probably use Btrfs or ZFS. Due to its alphabetical position, the latter is also known as "the last word in filesystems." > `guix system reconfigure` immediately switches to the new system That's true in the sense that the root profile changes and that Shepherd services are updated (although not restarted) but for most common setups it won't affect the mounted drives until the next boot. It'll require some thinking ahead. Most likely you will have to use the mount command manually in some cases. > it is not documented how it deals with changed filesystem and device > paths. That would be kernel thing. Generally speaking, files that are open stay open. > suppose that I define a new filesystem for `/gnu/store` on another > SSD. That's a special case, i.e. the caveat from above, that requires great care. Not all filesystem paths are created equal. Even experienced Guixers pull their hair over it. I would start with /home or /efi. Kind regards, Felix P.S. If you require redundancy, my recommendation is to look toward Mdadm instead of Btrfs. As the former maintainer of Mdadm in Debian, I'm biased but in my experience RAID support in Btrfs may not give you the recovery experience you might be looking for. In particular, I don't think Btrfs will, by default, assemble degraded arrays. In Guix, that is also broken for Mdadm unless you apply my patch. [3] [1] https://codeberg.org/lechner/system-config/src/commit/f7ef81c743abf86746541937d9ca5761b1647693/host/wallace-server/operating-system.scm#L1266-L1324 [2] https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra [3] https://issues.guix.gnu.org/64259
