[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Herding file-systems

From: Bruno Victal
Subject: Herding file-systems
Date: Wed, 8 Mar 2023 14:54:40 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

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 
   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 
   intended for the file-system, since the file-system is forcefully grouped 

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.

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 
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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]