Rogue/orphaned mount points in oc_mounts?

binarydad · June 23, 2021, 7:40pm

When querying oc_mounts, I see there are some rogue mount points that I don’t believe are needed. Most are from old tests.

My question is, can I simply remove the orphaned mount records that don’t have a mount ID value of 22, 24, 21, 26, 28, or 30? Or, is there a OCC method that will clean this up more elegantly for me? Thanks.

When I compare it against files_external:list, I see only 6 (as expected) are being used.

tflidd · June 26, 2021, 8:31am

I had a similar problem with external storage mounts that I tried a long time ago where the storages even don’t exist any more. There were some occ routines but they didn’t really clean that (you can work with those on the files_external:list).

Before I deleted the mount points, I checked the filecache table for related entries and deleted them first. In my case, I deleted them because the storage didn’t exist any more.

You could try to check on the bug tracker, perhaps create a bug report and see if they implement something in future version. I had some problem with other external mount points, so I just repaired it and didn’t try to follow through with a bug report.

Don’t forget to backup your system before you do any manual changes.

meonkeys · November 14, 2022, 12:27am

What were the repair steps? I think I might be running into something similar.

github.com/nextcloud/server

Large number of DB queries during execution of a single API call

opened 07:58PM - 18 Jul 22 UTC

closed 09:20PM - 27 Aug 22 UTC

starypatyk

0. Needs triage performance 🚀

When diagnosing [slow loading of chat messages in Nextcloud Talk application](ht…tps://github.com/nextcloud/talk-android/issues/2228) I have noticed that in my environment (NC 24.0.3, MySQL database), during execution of a **single** API call (retrieve chat messages), NC sends **over 2000 DB queries**. I use the following call (same as the Nextcloud Talk Android app): ``` https://<server>/ocs/v2.php/apps/spreed/api/v1/chat/<room-token>?lastKnownMessageId=<msgid>&includeLastKnown=1&limit=100&setReadMarker=1&timeout=0&lookIntoFuture=0 ``` Most of the queries (over 2100 from about 2500) are: ``` INSERT INTO `oc_mounts` (`storage_id`,`root_id`,`user_id`,`mount_point`,`mount_id`,`mount_provider_class`) SELECT ?,?,?,?,?,? FROM `oc_mounts` WHERE `root_id` = ? AND `user_id` = ? HAVING COUNT(*) = 0 ``` There are about 1300 records in the **x_mounts** table. Majority of them (about 1100) have **NULL** in the **mount_provider_class** column. This causes code in the [**registerMounts** method of the **UserMountCache** class](https://github.com/nextcloud/server/blob/42bcbe269f09bac30251ac102f202fc0091602c9/lib/private/Files/Config/UserMountCache.php#L94) to ignore the existing cache entries and try to re-add them - [see **addToCache** call](https://github.com/nextcloud/server/blob/42bcbe269f09bac30251ac102f202fc0091602c9/lib/private/Files/Config/UserMountCache.php#L120). However, the correct records are **not** added to the **x_mounts** table, since records with the same **root_id** and **user_id** already exist (the ones with **NULL** in the **mount_provider_class** column). And the same situation occurs on each subsequent API call. As I understand the **mount_provider_class** column [has been added recently](https://github.com/nextcloud/server/pull/30978). However, it seems that all the records that existed earlier in the **x_mounts** table, get **NULL** in the new column after upgrade. This in turn leads to the observed behaviour. I am not sure how the issue should be fixed. - Is it safe to delete all records from the **x_mounts** table? Will they be recreated properly by the **registerMounts** code? - If yes to above - should the upgrade delete the records after adding the column?

tflidd · November 14, 2022, 9:28am

In my case it was old stuff that I wanted to delete anyway, so I could just delete the entries (and it didn’t constantly add new entries). If these are used mounts, that is more complicated and I’d check with the developers (you have posted already on github).
The fix they are talking about went into NC 24.0.7, you are still using 24.0.6 that does not have this fix!

meonkeys · November 14, 2022, 4:40pm

Ah, maybe the first thing to try is upgrading to 24.0.7 then. Thanks!

meonkeys · November 14, 2022, 4:53pm

Updated to v24.0.7. I think that fixed it!

meonkeys · November 16, 2022, 6:22am

…or perhaps not.

I am still noticing some slow responses. I added a comment to that same bug, asking for more help.

github.com/nextcloud/server

Large number of DB queries during execution of a single API call

opened 07:58PM - 18 Jul 22 UTC

closed 09:20PM - 27 Aug 22 UTC

starypatyk

0. Needs triage performance 🚀

When diagnosing [slow loading of chat messages in Nextcloud Talk application](ht…tps://github.com/nextcloud/talk-android/issues/2228) I have noticed that in my environment (NC 24.0.3, MySQL database), during execution of a **single** API call (retrieve chat messages), NC sends **over 2000 DB queries**. I use the following call (same as the Nextcloud Talk Android app): ``` https://<server>/ocs/v2.php/apps/spreed/api/v1/chat/<room-token>?lastKnownMessageId=<msgid>&includeLastKnown=1&limit=100&setReadMarker=1&timeout=0&lookIntoFuture=0 ``` Most of the queries (over 2100 from about 2500) are: ``` INSERT INTO `oc_mounts` (`storage_id`,`root_id`,`user_id`,`mount_point`,`mount_id`,`mount_provider_class`) SELECT ?,?,?,?,?,? FROM `oc_mounts` WHERE `root_id` = ? AND `user_id` = ? HAVING COUNT(*) = 0 ``` There are about 1300 records in the **x_mounts** table. Majority of them (about 1100) have **NULL** in the **mount_provider_class** column. This causes code in the [**registerMounts** method of the **UserMountCache** class](https://github.com/nextcloud/server/blob/42bcbe269f09bac30251ac102f202fc0091602c9/lib/private/Files/Config/UserMountCache.php#L94) to ignore the existing cache entries and try to re-add them - [see **addToCache** call](https://github.com/nextcloud/server/blob/42bcbe269f09bac30251ac102f202fc0091602c9/lib/private/Files/Config/UserMountCache.php#L120). However, the correct records are **not** added to the **x_mounts** table, since records with the same **root_id** and **user_id** already exist (the ones with **NULL** in the **mount_provider_class** column). And the same situation occurs on each subsequent API call. As I understand the **mount_provider_class** column [has been added recently](https://github.com/nextcloud/server/pull/30978). However, it seems that all the records that existed earlier in the **x_mounts** table, get **NULL** in the new column after upgrade. This in turn leads to the observed behaviour. I am not sure how the issue should be fixed. - Is it safe to delete all records from the **x_mounts** table? Will they be recreated properly by the **registerMounts** code? - If yes to above - should the upgrade delete the records after adding the column?