Hi, Bruno Victal <mi...@makinata.eu> writes:
> Co-authored-by: Felix Lechner > > > Some observations and potential plans of action to improve file-system > handling > and proper NFS support within Guix. > > > Relaxing dependency field of file-system record type > =============================================================================== > > Guix currently envisions file systems to depend only on other file > systems, but that restriction should perhaps be relaxed. In some > cases, it may make sense to wait for any (shepherd) service, > i.e. not just for ones that mount directories. These could be used to place a > dependency on kerberos, etc. > > A prominent example is NFS, which should depend on 'networking but > currently doesn't. Sounds good. > Networked file-systems (such as NFS) > ------------------------------------------------------------------------------- > > The prerequisite 'file-systems should probably be split into > 'networked-file-systems and 'local-file-systems. That distinction is > already commonplace in other distributions. The stage > 'networked-file-systems would in many respects be similar to > 'file-systems but also depend on 'networking. > > We would have to watch out for some inconsistencies, however. For > networked file systems, for example, the setting (needed-for-boot #t) > may be impossible---except perhaps for thin clients. In impossible > cases, the configuration would error out. > > > Ideas to implement NFS support > ------------------------------------------------------------------------------- > > 1. Add a _netdev flag (à la systemd) > Looks ugly? Very :-). Let's try to find a more elegant way. > 2. Add a new prerequisite called 'networked-file-systems > This serves as a generic catch point for network dependent filesystems. > This is to be specified manually. (3.1 notes apply here) > 3. Partition file-systems according to field 'type into 'file-systems and > 'networked-file-systems. > As a drawback, it would only be able to handle known file-systems, > because that list would have to be hard-coded. > Cons: Automatic partition precludes the scenario that there could > be two shepherd services, one providing regular 'networked-file-systems > and a custom > one providing some 'my-custom-service symbol, where the latter is > specifically > intended for the file-system, since the file-system is forcefully grouped > into > 'networked-file-systems. I don't understand the cons, which perhaps suggests it'd be a bit of a stretched use case? > 3.1 Alternatively forego partitioning between local and network filesystems > and simply put a dependency on 'networking. The filesystem must be > decoupled from the 'file-systems symbol to prevent circular dependencies. > > Comments: > The decision criteria should be "which one is the most flexible/has the least > implicit assumptions" here. Another related idea; perhaps we could introduce a new record called 'distributed-file-system' and use this at the time of declaring the file system? That'd would automatically depend on networking in the underlying implementation; so I'd be able to specify it in my operating system like: (file-systems (cons* (file-system (device (uuid "43582534-54a1-415a-a8ac-ecc20867f7a3")) (mount-point "/boot") (type "btrfs") (options "compress-force=zstd")) [...] (distributed-file-system (device "host:/srv/nfs/jami") (mount-point "/var/cache/jami") (create-mount-point? #t) (type "nfs") (options "soft,user")) It'd allow to decouple the <file-system> and <distributed-file-system> fully, providing flexibility to add new fields to the later in the future which would make little sense for the former. It's also more declarative than the "auto-determine networkness from type" (point 2 above) heuristic. Thanks for looking into this longstanding limitation! -- Maxim