Since the last week, for the first time in many years, I have a proper workstation-class computer. It contains many mass storage bays and I am now facing a new question.
My initial idea is to deploy a Guix system to one SSD and then successively transfer parts of the file system tree to new drives as I decide to buy them. One of the reasons for this is that I am not experienced with storage objects like RAID, and would like to take my time playing with them before proper use. However, I am currently using the workstation off of a USB stick and need to decide on an interim solution based on a real SSD. In the systems I had installed on my laptops so far, I use filesystem labels to identify how to mount each of system partitions. While it is trivial to set up on a single storage device, it is no longer obvious how to design a complex storage solution with redundancy and replacement of parts. The core of the problem is that `guix system reconfigure` immediately switches to the new system generation and it is not documented how it deals with changed filesystem and device paths. NixOS has a CLI option which clearly handles this complexity by building a new generation, pointing a new boot entry to it, but *not* switching to it immediately. It would be a nice addition to the guix interface, too, but I do not expect it to be implemented soon enough for me. Suppose that I have a Guix System deployed all in one SSD. Next suppose that I define a new filesystem for `/gnu/store` on another SSD. How would the guix daemon handle this change? Would it try to use the new path immediately? Or would it read the new filesystem layout only on the next boot? Is there are a possibility of changing drives without race conditions? Guix Community Member, Marek Pasnikowski
