entries in "omero fs repos"

[dsudar]

Hi all,

I just moved my omero.data.dir to a new location for space reasons. As part of that I noticed the "omero fs repos" command so ran that to see what it says. It reports some extra entries that give me some concern:

Code: Select all

Created session a05a28bd-eb09-425d-a997-82df75ba34d8 (dsudar@localhost:4064). Idle timeout: 10 min. Current group: Sandbox
# | Id     | UUID                                 | Type    | Path
---+--------+--------------------------------------+---------+-----------------------------------------------------------
0 | 17     | ScriptRepo                           | Script  | /usr/local/OMERO/OMERO.server-5.2.8-ice35-b57/lib/scripts
1 | 18     | c90b38eb-6c5d-4f84-9b0f-6d206861b646 | Public  | /data/share/OMERO.data
2 | 32001  | eea50f53-f0a2-42cb-a57e-a098368e6637 | Managed | /data/share/OMERO.data/ManagedRepository
3 | 970951 | 4904ab06-32bb-42e6-bd41-116583b768ad | Public  | /data/OMERO.data/ManagedRepository
4 | 970952 | d4067eee-ca48-4e3b-8a8a-15057440f2fd | Public  | /data/OMERO.data
(5 rows)


Those last 2 entries still refer to the old location of the data dir. Those entries were there even before I did the move so they probably have been there for quite a while. Anything worrisome or anything I should do about those?

Thanks,
- Damir

[jmoore]

Hi Damir,

I just moved my omero.data.dir to a new location for space reasons. As part of that I noticed the "omero fs repos" command so ran that to see what it says. It reports some extra entries that give me some concern
...
Those last 2 entries still refer to the old location of the data dir. Those entries were there even before I did the move so they probably have been there for quite a while. Anything worrisome or anything I should do about those?

Not particularly. We can help you to clean them up if you'd like. I seem to remember a debugging session regarding these previously that would likely give us some context.

Fundamentally, if they were there before the migration and everything's working, then at most they are taking up a few rows in the DB, so it's not an issue. If you have any reason to believe something is amiss, we can dig deeper.

All the best,
~Josh.

[dsudar]

Hi Josh,

So far I don't see anything amiss with how it runs. The old location of the repo is still there but tomorrow morning I will delete it and re-purpose that disk subsystem. If nothing strange happens after that I guess we can just leave those entries in place.

If removing those entries is easy and without danger, would it make sense to do so anyway?

Thanks for your advice on this.
Cheers,
Damir

[jmoore]

Before the DB entries (as opposed to the storage locations) can be gotten rid of is to see if they are still linked to anything in the DB. As in https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=8302&p=18224&hilit=fs+repos#p18227, use:

Code: Select all

SELECT count(id), repo FROM originalfile WHERE mimetype <> 'Repository' AND repo IS NOT NULL GROUP BY repo;


to find out.

Cheers,
~Josh

[dsudar]

Hi Josh,

Thanks again and looks like I'm not in trouble per the discussions you pointed me to.

My omero fs repos says:

Code: Select all

# | Id     | UUID                                 | Type    | Path                                                                                                 
---+--------+--------------------------------------+---------+-----------------------------------------------                                                       ------------
0 | 17     | ScriptRepo                           | Script  | /usr/local/OMERO/OMERO.server-5.2.8-ice35-b57/                                                       lib/scripts
1 | 18     | c90b38eb-6c5d-4f84-9b0f-6d206861b646 | Public  | /data/share/OMERO.data                                                                               
2 | 32001  | eea50f53-f0a2-42cb-a57e-a098368e6637 | Managed | /data/share/OMERO.data/ManagedRepository                                                             
3 | 970951 | 4904ab06-32bb-42e6-bd41-116583b768ad | Public  | /data/OMERO.data/ManagedRepository                                                                   
4 | 970952 | d4067eee-ca48-4e3b-8a8a-15057440f2fd | Public  | /data/OMERO.data                                                                                     
(5 rows)


and the SELECT command says:

Code: Select all

omero_database=> SELECT count(id), repo FROM originalfile WHERE mimetype <> 'Repository' AND repo IS NOT NULL                                                        GROUP BY repo;
count |                 repo
-------+--------------------------------------
51688 | eea50f53-f0a2-42cb-a57e-a098368e6637
    24 | ScriptRepo
(2 rows)


So that looks good per what you said to Jacques.

Then following your instructions to Jacques:

Code: Select all

omero_user@omero:/data/share/OMERO.data$ find /data/share/OMERO.data/.omero -name repo_uuid -exec cat {} \;
$c90b38eb-6c5d-4f84-9b0f-6d206861b646

and

Code: Select all

find /data/share/OMERO.data/ManagedRepository/.omero -name repo_uuid -exec cat {} \;
$eea50f53-f0a2-42cb-a57e-a098368e6637

so the active ones are #1 and #2 (in addition to the one for the scripts).

Now since #3 and #4 are not doing any harm (as you had surmised) and since the instructions to remove them look a little scary, I'm thinking to let them be. Sounds okay?

Now how those came into being, the history of this server is somewhat similar to Jacques' story where it started as OMERO 4, upgraded many times, moved to a larger disk subsystem once before, etc. So hard to pinpoint when that happened.

But thanks much for putting my mind at ease.
Cheers,
- Damir

[jmoore]

Now since #3 and #4 are not doing any harm (as you had surmised) and since the instructions to remove them look a little scary, I'm thinking to let them be. Sounds okay?

Sounds okay. But if you do want to give it a try, just take a database dump first
~Josh.