Re: Herding file-systems

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Bruno Victal <mirai@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