-
Posts
43837 -
Joined
-
Last visited
-
Days Won
137
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by trurl
-
-
12 minutes ago, trurl said:
Nothing can move open files. Disable Docker and VM Manager in Settings.
Also, Mover ignores any share where there is no Mover Action specified, which is what you have for all of those.
appdata shareUseCache="only" # Share exists on cache, disk4 domains shareUseCache="only" # Share exists on disk4 isos shareUseCache="only" # Share exists on disk4 P-------e shareUseCache="no" # Share exists on disk3 P---------V shareUseCache="no" # Share exists on disk4 system shareUseCache="only" # Share exists on disk4
They need to be Primary:cache; Secondary:array; Mover Action:array->cache
-
53 minutes ago, goinsnoopin said:
Last check incomplete on Tue 26 Mar 2024 06:30:01 AM EDT (yesterday), finding 25752 errors.
Error code: -4That seems to correspond with when parity check was paused.
Mar 26 06:30:01 Tower kernel: mdcmd (39): nocheck pause Mar 26 06:30:01 Tower kernel: Mar 26 06:30:01 Tower kernel: md: recovery thread: exit status: -4
Later on syslog says
Mar 27 00:30:01 Tower kernel: md: recovery thread: check P Q ... ... Mar 27 03:57:12 Tower kernel: md: sync done. time=12431sec Mar 27 03:57:12 Tower kernel: md: recovery thread: exit status: 0
-
Attach Diagnostics to your NEXT post in this thread.
-
Nothing can move open files. Disable Docker and VM Manager in Settings.
Attach Diagnostics to your NEXT post in this thread
-
Start the array with disk3 unassigned and post new diagnostics.
Do you have a spare to rebuild disk3 to?
-
Parity knows nothing about filesystems, it is all just bits.
Rebuild will result in the same bits on the disk, so can't fix corruption
Attach Diagnostics to your NEXT post in this thread.
-
5 minutes ago, kcossabo said:
I have no VM, but it is enabled.
Then libvirt.img is an open file in the system share.
-
appdata, domains, and system shares have files on the array. In fact, you have domains configured to be moved to the array.
Ideally, appdata, domains, and system shares would have all files on fast pool such as cache with nothing on the array, so Dockers/VMs will perform better and so array disks can spin down since these files are always open.
Mover won't replace files, so if something exists on both cache and the array you will have to decide which to keep. Dynamix File Manager plugin will let you work with folders and files directly on the server and can help you figure that out.
And, from your previous diagnostics, it looks like default 20G docker.img would be more than enough. After you get those shares moved and configured correctly, you can delete, recreate at 20G, reinstall containers.
https://docs.unraid.net/unraid-os/manual/docker-management/#re-create-the-docker-image-file
https://docs.unraid.net/unraid-os/manual/docker-management/#re-installing-docker-applications
-
vdisks are sparse files but it can grow to the space you have allocated for it.
-
32 minutes ago, kcossabo said:
changed it to the cache, and invoked the mover
Nothing can move open files. You have to disable Docker and VM Manager in Settings before these can be moved.
-
Only drives connected when the array is started are counted.
-
1 hour ago, HOLISTICAGENT said:
the terms i accepted 25 days ago
What terms? Did you already buy?
-
Do you have adblocker or anything else that might interfere with browser?
-
Probably better to start your own thread with your diagnostics instead of posting to an old thread for an old version that is already marked solved.
-
What happens if you boot in SAFE mode?
On 3/25/2024 at 3:50 PM, rvijay007 said:Trying to manually invoke the Mover never seems to move any files
Doesn't look like there is anything for mover to do currently.
However, you need to reconfigure system share so it gets moved to cache. And nothing can move open files, so you have to disable Docker and VM Manager in Settings to get those moved.
-
Looks like you have some corruption on disk22
Mar 27 10:15:10 Balor kernel: XFS (md22p1): Filesystem has been shut down due to log error (0x2). Mar 27 10:15:10 Balor kernel: XFS (md22p1): Please unmount the filesystem and rectify the problem(s).
Also, disks 24, 26, 27 empty or nearly so. Is that expected?
-
Do you have a current backup of flash?
-
-
/usr is a folder in the OS, which is in RAM.
The user shares are at /mnt/user.
The system user share only has docker.img and libvirt.img in a default setup. This is actually specified in Docker and VM Manager settings and so is under user control.
And of course there is nothing to prevent users from putting other things in the system share so no way for me to know whether you had anything else in there or not.
appdata, domains, and system user shares by default are setup to live on cache pool, so Dockers/VMs will perform better and so array disks can spin down since these files are always open. This is also under user control since you can change this and specify other shares or disks for these, in Docker and VM Manager settings, and even for specific containers or VMs.
Best if you don't enable Docker or VM Manager until you have cache or other fast pool setup, or these will get created on the array instead.
- 1
-
9 minutes ago, Civic1201 said:
Is it safe to delete them using mc?
yes
- 1
-
-
8 minutes ago, Civic1201 said:
I want to keep that shares on my cache drives only
You should want appdata, domains, and system shares with nothing on the array so Dockers/VMs will perform better and so array disks can spin down since these files are always open.
On the User Shares page, you can click Compute... for a share to see how much of each disk/pool is used by a particular user share.
-
That shows that those shares have some files on cache. It doesn't show that appdata, domains, and system no longer have any files on the array.
-
9 minutes ago, MrCrispy said:
even standard SATA has much higher write speeds. There are posts here where people have done plenty of tests and the conclusion was the smb and FUSE in unraid was to blame, without that they got much higher speeds, without using any cache.
Realtime parity updates are the reason writes to the array cannot be as fast as SATA or even HDD speeds.
https://docs.unraid.net/unraid-os/manual/storage-management/#array-write-modes
And also the reason Unraid can allow different sized disks in the array.
Basic license - external USB drive
in General Support
Posted
The quoted post seems to be gone, and it was made by a user that has only made incorrect posts since joining yesterday. ChatGPT?