Herding file-systems

[Bruno Victal <mirai@makinata.eu>]

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.


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?

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.

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.


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.

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.


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.


Footnotes
===============================================================================

[1]: https://issues.guix.gnu.org/60246


Cheers,
Bruno