Minio.sys big file?

Pydio Cells
1

Hey,

Recently, I have set up a backup system with duplicity
when it uploaded, I found it very long: more than 80gb for the pydio folder. But I don’t have more than 30gb of data. I searched why, and the /pydio/.minio.sys/tmp folder contains more than 50gb of data!
Can I empty it?
What is this folder ? I can’t find anything in the doc

Thanks!

2

Hello,

It could be the temp folder for uploading a file. Could you please try to upload a big file and monitor the process and the temp file in this folder?

3

Thanks for your answer. Can you tell me how I can monitor in just one folder ?

4

Hello,

I didn’t monitored the process but I monitored the file size inside the temp folder. When i upload a file, it creates new file.

Can I delete them ?

5

Has this ever been solved? I have the same problem. The .minio.sys/tmp grows up to 800GB when I start the resync of a datasource. The datasource itself is on disc and has only 85GB. The log has entries which show that s3://ip-of-cells-server/datasource is being analysed and finshes with S3 Walk Operation + Stats took {"d": "1h39m7.674269552s"}
Is there any way to turn of minio ?

6

Is there any way to turn of minio ?

If you want to be able to upload / download files, nope.

Yet, the tmp directory is used by minio for multipart transfer. When a transfer fails, parts are not deleted so that if you retry later, you already have some of the parts that were correctly uploaded.
So, if you have no pending transfer, you can empty this tmp subfolder.

7

Does that mean, if nobody is uploading into that data source (because that would be me), that somebody must be downloading data and that keeps failing? Is there any way to check if a transfer failed. There must be constantly failing transfers, because tmp is growing steadily.

8

I checked the tmp folder again and the only files in different sizes appear to be originated from a very large zip file (29GB). When such a file is growing, would that be an indication that somebody is downloading the large zip file? Or could that be caused by a resync as well?

9

Interesting!

My own .minio.sys/tmp has just a hundred directories or so, all of them empty except two (and one of those two is a zero-byte file), so it doesn’t worry me much. It only takes 432K — most of it coming from the directory structure itself, I imagine. The directory names, as well as the files, are merely UUIDs, no description whatsoever.

On the other hand, .minio.sys/multipart has close to 5000 (!) directories, again, all of them empty, summing up a total of 20 MBytes (!) — that’s just for the directories (again, their names are just UUIDs).

It’s not the amount of space that worries me, of course. I just wonder if it’s ‘normal’ to have such a huge number of empty directories. I’m assuming that these were once used for uploading files, but, once uploaded, the file itself gets deleted — but the ‘temporary directory’ is not.

Is this a problem or can it be safely ignored?

Also, assuming that nobody is transferring files at the moment, can all these superfluous directories be safely removed, or the fact that they’re UUIDs mean that they’re actively being tracked by ‘something’ (I’d guess the Minio subsystem), which would therefore get utterly confused if all those directories simply disappeared from the (physical) filesystem?