[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Herding file-systems
From: |
Maxim Cournoyer |
Subject: |
Re: Herding file-systems |
Date: |
Fri, 10 Mar 2023 09:49:28 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
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