Re: Herding file-systems

[Liliana Marie Prikler]

Am Mittwoch, dem 08.03.2023 um 14:54 +0000 schrieb Bruno Victal:
> 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 fair so far.

> 
> 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.
And here I see potential for possible over-engineering.  Since all our
file-systems are already handled by shepherd, I see no need in
"herding" them, as the title implies.  What is needed, OTOH, is a way
to inject shepherd dependencies, e.g. on networking, but possibly also
on other file systems (*cough* loop devices *cough*).

> Name collision for mounts on the same path
> =====================================================================
> One additional concern is the naming of Shepherd services for file
> systems.  We can no longer just create the name from mount point
> alone since those names would collide with filesystems that can mount
> over the same path.
Uhm, why should we allow this?

> The concern is not as far fetched as it may initially appear.
> Examples would be FUSE filesystems and OverlayFS, but there are
> probably others.  Some FUSE file systems are specifically mounted
> over an existing mount point in order to provide additional services
> like transparent access for compressed archives.
> 
> Regarding OverlayFS, it's worth noting that it can mount multiple
> times over itself, though personally I don't know what the
> applications are for this kind of scenario, merely that it can be
> done.
In which cases should these mounts be created by the operating system
rather than a cheeky user, though?

> fstab serialization criteria
> =====================================================================
> 
> It's worth revisiting why/what are the issues (and whether they're
> still relevant) that made us exclude certain file-system declarations
> from being serialized to /etc/fstab. [1]
> Excluding serialization for certain types isn't a problem but there
> should be an escape hatch option to forcefully serialize them to
> /etc/fstab.
This appears a somewhat separate concern to the rest here and I'd
suggest investigating it separately, as this escape hatch can easily be
added without thinking about the broader picture of network file
systems.

Cheers