Either your server has an extremely long uptime, or your syslog could be potentially being spammed with error messages. A reboot of your server will at least temporarily solve this problem, but ideally you should seek assistance in the forums and post your

 

I have no idea what fix common problems is talking about and was hooping i can get help from smarter people.

tower-diagnostics-20211103-1219.zip

Your log is spammed by mover logging.

 

You should disable it (scheduler page), it is only useful for debuging issues with the mover.

 

Then reboot is the simplest way to clear the logs are they are on RAM.

Unrelated, but I realized the your mover is trying to move a lot of stuff from your Pool "plexssd" and cannot:

• either because the file is open (docker image or other Plex appdata)
• or because the file already exist on the destination

I guess that you should check your shares settings so that the files are where they are supposed to be (set to cache:Prefer I guess) and clean up the duplicate files.

Do you know how to do that or do you need help on this ?

Turned of mover logging will reboot server when I get home. Also I have a separate cache pool for plex. I wanted plex metadata on it not on the shares. But it made a library share and deleted the files on it thinking I did not need it. So how can I keep the files on it when I click mover to move stuff on my main cache drive that I use as an ingest server.

If I can get help with that my issues might get fixed

47 minutes ago, Live527 said:

I have a separate cache pool for plex. I wanted plex metadata on it not on the shares. But it made a library share and deleted the files on it thinking I did not need it.

All pools are part of user shares so you don't want to delete them since that would be deleting them from the pool.

 

Your system share is set to cache-yes instead of cache-prefer or cache-only. And so it has files on the array. You want that share all on cache and set to stay on cache. Your dockers/VMs will not perform as well if this share is on the array, and they will keep array disks spunup since these files are always open.

 

47 minutes ago, Live527 said:

library share

That share has files on the array and on plexssd, but it isn't configured to use that pool. And it is cache-yes, which would make it get moved to the array. You want it to be Use cache pool: Prefer and Select cache pool: plexssd

 

Nothing can move open files, and mover won't move duplicates. You have to go to Settings - Docker and disable dockers before you can get these moved where they belong.

 

You can see how much of each disk is used by each user share by clicking Compute... for the share on the User Shares page, or using the Compute All button at the bottom.

 

 

 

 

Here is some screenshots of how it's set up now and explain to me how I can fix it.

1 minute ago, Live527 said:

explain to me how I can fix it

I think you must have posted that while I was posting my explanation. Ask if you have questions.

 

Also, not sure what is filling your log space since the syslog isn't that large. What do you get from the command line with this?

du -h -d 1 /var/log

 

As of resetting my server it's back to 1% used

This is what I get now

What fix I was talking about was the plexssd thing. I wanted the metadata only on that or dose the plex docker container always make a backup library folder. If so how to I get it to be on the parity drive as it has the icon saying it not protected

It isn't a backup library folder, it IS your library folder. User shares are simply the top level folders of all array and pools, so you have a Library folder that spans that plexssd and some array disks. If you want it all on the array so it is protected by parity, then you will have to move it off that pool and set it to not use cache. But, your plex won't perform as well with it on the array, and it will keep array disks spunup.

 

Here is how I have my dockers setup with multiple pools. I have a "cache" pool which is used for caching user share writes. I have a "fast" pool which has my appdata, domains, and system shares on it. My plex appdata and all my other docker appdata is in the appdata share on that "fast" pool, and I use the CA Backup plugin to backup my appdata, so I don't need it protected by parity.

So looking at the pictures I sent I have everything set up correctly right.

4 minutes ago, Live527 said:

So looking at the pictures I sent I have everything set up correctly right.

It isn't they way I would do it, and it doesn't get all of your Library share onto the array.

ok confused now how should it be set up

I have a two cache pools plus the array. How do I get it all set up correctly.

i have the same issue, attaching my diagnostics.

 

i will do the same as advice given (disable mover logging and reboot*), but wondering if someone can take a look through and see if anything stands out as incorrect to them

 

thanks.

 

 

*i have had issues recently while downloading a lot that things have been stuck on the cache, so i have been overusing the Mover, as well as having to manually move things from the cache disk. i always feel like i'm doing something i shouldn't be when doing this, though.

tower-diagnostics-20211213-1800.zip

Corruption on cache, and corrupt docker.img, probably cause by overfilling. Syslog entries from these have filled your log space.

 

And your docker.img is almost certainly larger than needed. If you have had problems filling docker.img, making it larger won't fix that, it will only make it take longer to fill. The usual reason for filling docker.img is applications writing to paths that aren't container paths in the mappings, case-sensitive.

 

2 hours ago, gellux said:

while downloading a lot that things have been stuck on the cache, so i have been overusing the Mover, as well as having to manually move things from the cache disk. i always feel like i'm doing something i shouldn't be

It is impossible to move from fast cache to slower array as fast as you can write to cache. Mover is intended for idle time. If you need to write more than cache can hold at one time, don't cache.

And further examination of diagnostics indicates your cache drive is actually failing, which would explain all that.

 

 

10 hours ago, trurl said:

Corruption on cache, and corrupt docker.img, probably cause by overfilling. Syslog entries from these have filled your log space.

 

And your docker.img is almost certainly larger than needed. If you have had problems filling docker.img, making it larger won't fix that, it will only make it take longer to fill. The usual reason for filling docker.img is applications writing to paths that aren't container paths in the mappings, case-sensitive.

 

It is impossible to move from fast cache to slower array as fast as you can write to cache. Mover is intended for idle time. If you need to write more than cache can hold at one time, don't cache.

 

re: corruption. thanks very much. yes i did make the .img larger but i just assumed this was what happened - that it filled up over time and i was buying more time. i don't know what is writing to it, in that case. going over my container paths i've been as careful as i can with them and i only run a handful of containers. is there a way to identify the problem without going in and out of each settings?

 

re: cache writing. yes i didn't mean that, i meant what i'd been doing is downloading enough to fill the cache, then invoking the mover, then download more. the mover wasn't always moving as scheduled - hourly - and sometimes it would only move half of the disk to the array. occasionally it seemed in qbittorrent that i had overfilled the cache, and qbt set it to go to /incomplete/ which is on the cache, so when i changed that to the correct destination, it moved off the cache to the array. once or twice, though, i've had to do it manually with filezilla.

 

re: cache failing. damn. well i suppose i shouldn't be surprised with my abuse of it. maybe santa might bring a new one.

 

thanks very much for your help. any further advice is much appreciated.

6 hours ago, gellux said:

any further advice is much appreciated.

Don't attempt to use that failing cache. Best if you replace ASAP. Next best would be to remove it after moving whatever you can to the array, but if you run dockers/VMs without cache or other fast pool, they will be on the array and you will have a little work to do to get them moved off after you get cache going.

i don't have any VMs and i just use the cache for downloading, so i can just... not. i will replace the disk. i can't seem to do a SMART test on it, for some reason. the button flashes once and reverts back to START, but below SMART Overall Health says Failed, so thanks for alerting me to that.

 

after reading a few threads here i'm wondering if my set up has been relying too much on the cache overall too. i had wanted a /download share which took care of processing all incoming traffic, then moving it onto the array all at once. largely this has been successful except occasional folders getting stuck as i mentioned.

i also wanted to use a /transcode share which i believe i set up following spaceinvader's tutorials so that Plex would use a fast cache disk rather than the array disks to play on the connected TV. i don't think this works at all, and in fact when Plex uses original quality, it stalls and buffers so i had to make it use either 1080p 4MBs or 720p. i thought this would be transcoding on the cache, but it seems not. i don't know where it happens, but streaming works fine now.

i've identified this drive: https://smile.amazon.co.uk/Samsung-MZ-V7E1T0BW-V-NAND-Express-Solid/dp/B07CGJNLBB?sa-no-redirect=1&th=1 

does it sound applicable to my needs?

thanks

6 hours ago, gellux said:

identified this drive

very nice!

Hi, I have this issue on a newly built server.  Not sure whether to add here or create as a new topic due to age of post. Issue seems to occur in the final stages of setting up a Windows 10 VM.  Everything goes fine until I passthrough a RTX4080 (with HDMI audio and VBIOS). The GPU doesn't passthrough, all cpu cores run at 100% and fix common problems shows this error.  Any guidance would be appreciated. Diagnostics attached. Thanks 

zeus-diagnostics-20230424-0710.zip

26 minutes ago, Vatrinus said:

Hi, I have this issue on a newly built server. 

Apr 23 23:03:03 ZEUS kernel: vfio-pci 0000:01:00.0: BAR 1: can't reserve [mem 0x80000000-0x8fffffff 64bit pref]

 

This is what's filling up the log, google this error, I believe there are some solutions.