Path specific file sytem setup

[AndyScherzinger]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Description

The objective of this issue is to introduce path-scoped mount setup so mount providers no longer have to provide all mounts for a user when setting up for a specific path. To achieve this, the SetupManager should resolve mounts for a specific path by consulting the mounts table to retrieve the closest parent with a mount, call the responsible mount provider to initialize it, and finally stop registering mounts itself.

For this reason Mount Providers will need a getMountsForPaths method.

It may also be necessary to have the mount schema track parent–child relationships to make looking up the nearest ancestor efficient.

Note: the changes mentioned here MUST happen in a non-breaking format. It is NOT an option to edit existing interfaces. For this purpose new interfaces can be created and extend the existing ones.

[salmart-dev]

1. Scope of changes

To keep reviews as simple as possible, changes were intentionally kept to the minimum. The overall setup flow remains close to the existing one: when setting up a path, the system first attempts to load cached mounts for the given path and, if requested, for its children.

2. Avoiding Duplicate Mount Setup

To prevent setting up the same mounts multiple times, additional tracking was introduced for mount point changes and setup paths.
Because full provider setups and partial provider setups can now coexist, partially provided mounts must be discarded when a full setup is performed (for example via setupForUser or setupForProvider).

3. Partial Mount Support

The existing SetupManager::setupForPath function was extended to support partial mount lists from mount providers implementing IPartialMountProvider.

These providers receive:

• the path for which setup is requested
• cached mount point information
• cached root metadata

This allows providers to return only the mounts relevant to that path.

4. Implications for Providers and Performance

Since full setups are still performed in certain situations (e.g. periodically, when loading the user’s root, etc.), and working with the assumption that mounts are eventually guaranteed to be available, providers implementing IPartialMountProvider can safely take shortcuts. In particular, they can avoid expensive scan operations and instead trust the mount point list they receive, returning a reduced set of mounts.