Ok a few things. Messages are bytes to kilobytes in size. You aren’t going to see a drastic change. Mongo likely won’t even free anything since it’s already using compression.
To free space you’ll need to probably hit files.
Second… deleting messages does not delete rooms. So of course your rooms still exist.
If a message still shows up there in the room list the last message is stored on the room. If for some reason you don’t like seeing the last message on mobile… you can turn it off in settings with a setting called store last message.
I never knew that mentioning someone was a faux pas? You are on the rocketchat team so thought it logical to mention you. This is what I thought mentions were for…to get someone’s attention who would be most qualified to speak on a topic.
I didn’t ask about deleting rooms, don’t know how you got that from my post? If I wanted to delete the room I would have deleted it. I was asking about deleting the messages from the harddrive whilst keeping the room, thus clearing the messages from disk without having to delete and create the room again (and have to create new invite links on for it each time).
I guess I will just have to find a mongo solution to it then. I just don’t want thousands upon thousands of redundant messages hanging around the server, I want them cleaned from the machine. And what about for security purposes if you don’t want that stuff remaining around, there are many legitimate reasons for that.
Most of the time I spend here helping is in personal time trying to help the community I came from. It’s not a big deal just a request not to pull someone specifically in. Kinda the difference of answering something cause you now feel you have to vs seeing and wanting to. that’s all really.
The way you phrased it seemed like the rooms being there still might still be a problem. At any rate… deleting messages unless deleting billions of messages isn’t really going to free up that much disk space.
The prune message feature does actually prune the messages. You could for sure confirm that in the database. In the room list you see the last message sent in each channel because of the feature called “store last message” it simply updates on the room with the last message so you can see the last message at a glance instead of having to have each client hammer the server and database figuring it out.
It not clearing out when you prune all messages is it sounds like a bug that needs reported.
But if you do want that to go away turning that feature off will stop the storing of last message on the room. Just note it definitely can alter the experience.
But if disk cleanup is your goal I’d recommend storing your files on either file system or an s3 compatible store (I use backblaze cheap and newly s3 compatible b2 service for my personal server). Storing in gridfs if sending a lot of files will lead to a lot of bloat. Mongo isn’t the greatest at storing files. Nor should it be I guess.
I don’t get the same behavior as you regarding the last message being visible after prune. It clears all the messages from the room and says ‘start of conversation’ however on the rooms tab the exact number of total messages never changes as a result of pruning.
I would have been (more) happy to store the files in a more conventional way (which I would have been more familiar with as frankly mongodb is confusing to me) I was just following the the docker guidelines and tutorials from rocketchat as that was the advised way to go at the time of starting out.
Can I still seamlessly switch to conventional storage going forward with the existing server without too much disruption or would I need to roll a whole new server? The messages aren’t critically important but the server settings would be nice to keep and not have to redo all over.
If I am using docker for mongo and rocketchat do I need to make both again locally on HD in this case or can rocketchat still run from docker whilst having the storage on normal HD space?
Ah! Ok so similar to what I thought was happening. There is a count also incremented on the room to prevent having to query… that number must not be getting reset. So would be a bug. Likely slipped through our testing because we typically leave that feature to show count off. Larger servers can suffer performance issues with it on.
Yeah… hard to cover ever scenario unfortunately. We probably need more branching off into post setup suggestions for longer term installs. Gridfs we ship with on because does let people get up and running the quickest.
Yup can just swap to a new one and old files will keep loading from gridfs. Then all new ones would load from your new file store.
The only time it won’t work between stores is if you switch between two of exact same type. In those scenarios you’d have to copy/combine into the new one of that type.
If switching to s3 compatible you don’t have to change a thing outside. Just change the settings in file upload section in admin.
If you want to use filesystem… you’ll need to modify the docker-compose to mount the folder into the Rocket.Chat container. Then stop and bring up the rocket.chat container. Leaving the mongo one alone