Use oc_mounts as authoritative fstab-like list

[PVince81]

Currently oc_mounts is populated when a user's filesystem is getting set up.
This means that when setupFS is called, it will ask all mount providers to provide mounts.
This also means that the share mount provider will have to read the shares from oc_share, every time!

How about making it work differently: the oc_mounts becomes a fstab-like list and setupFS only ever mounts what's written in there. The table must then be populated at a different time, for example whenever a share is created or an external storage added, or a user added to a group, etc. (which is likely a big challenge). Or this could be done in a background job.

@DeepDiver1975 @butonic @owncloud/filesystem

[butonic]

a share might not be created until a user accepts the share.

[PVince81]

Ref: #19153

[guruz]

I think @DeepDiver1975 proposed something similar to that at the conf.

I think this was also the discussion when twitter scaled up:
SELECTing all tweets from all people you follow when you load the timeline in the client
vs.
All your followers INSERT their tweets into your timeline each time they tweet and then you just need to SELECT your own timeline..

[PVince81]

This will become even more important once we merge #25422 which moves the external storage logic to core, because. In the past only people who had files_external enabled would likely have a performance decrease because the oc_external_* config tables need to be read every time the FS is mounted.
Now when moving the code to core, external storages are always enabled, so even people who don't use it would get a performance decrease.

If we have a fstab-like table then the minimum required for setting up a usable FS is reading the fstab table (oc_mounts ?). And only once someone uses the API to access any of the mounts, we might need to read the external storage config or share info to resolve it. But I guess that even that could be cached somehow.

[PVince81]

Another advantage of this idea is that users could really move around any kinds of mounts because their origin would be tracked in oc_mounts anyway, like moving a received system-wide mount: #26671 (comment)

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.