racquemis

Had this happen on some of my disks when i experienced a crash while it was writing to the disk. If it was an XFS filesystem try this: Data recovery | Unraid Docs

Great, that is fortunate. That is something easily fixed. I'll look into replacing the cabling and PSU if the problem occurs again. Thanks for having a look.

Diagnostics attached. It seems the 6TB is being dropped by the controller during parity sync. I thought the drive was still accessible but it was only cached directory and file listings. After the diagnostics i rebooted and the 6TB was gone. Reseated the power and sata connector and drive is found again. Not sure if it's the cabling or the controller. It seems the 6TB is still good. Restarted the server and the entire disk was missing, reconnected the cabling and restarted and the drive is seen again. Running parity sync again. Hopefully it doesnt fail again mid sync. unraid-diagnostics-20251025-1040.zip

I just need some advice on how to proceed in my situation. My curious son detached one of the drive bays in my server while the unraid array was running. This caused unraid to drop one of my 12TB drives from the array and contents of the missing drive to be emulated. I re-attached the drive to the array and parity sync started to reconstruct this data disk again. During parity sync one of my other drives started to throw errors and parity sync halted. Now this 6TB drive has not completely failed. it is still online. So i was thinking of just creating a new config, mark the parity as good. Then take the array offline, and swap the failed 6TB drive with a new one and rebuild. I was thinking that even if some files where rebuild corrupted i could maybe salvage that file from the failing 6TB drive. Is this a good approach? or are there any other suggestions?

Like Kilrah said, you can set how you want it. If you have a finite amount of space you could take the amount of space you want to reserve in bytes, divide it by HEAD_BYTES + TAIL_BYTES and you will have the value you need to use for MAX_FILES. It will then cache the most recently accessed files up the number specified. The value for HEAD_BYTES is determined by the bitrate of your files. I use 65MB for large 4K video files which seems enough to bridge the time it takes to spinup the drive. For smaller videos files it can be less. You can estimate the HEAD_BYTES by just dividing the video filesize by the runtime in seconds and multiply by the number of seconds it takes to spinup your drive. TAIL_BYTES i would just keep at 1MB, it seems fine for most situations. You can experiment with the HEAD_BYTES size, after a change in the configuration the script should re-cache the files. If you notice that the video starts instantly but freezes after a couple of seconds that is a sign that the HEAD_BYTES is configured to small. I got 120TB of video files cached resulting in a cache size of around 1.44TB. i use 60 and 65MB for the head cache.

Since power isn't cheap, I run my large Unraid array with all drives spun down by default. However, this created the annoyance of waiting 8 to 10 seconds, staring at loading spinners, while the hard drive containing the media file spun up. I tried my best at a solution to suit my own situation, i have not looked that hard if there are existing solutions, i just enjoyed having a small project again. Sharing it in the belief it might be useful for others. It probably isn't anywhere near perfect, but it works, at least on my setup. Tested with Plex VideoCacheFS. VidCacheFS is a Python FUSE filesystem that presents a mount point that mirrors a chosen “backing” media directory or directories. Behind the scenes it pre‑copies small slices of each media file to SSD storage—the beginning (“head” segment) and the ending (“tail” segment)—along with lightweight file metadata for fast listings and opens, and maintains in‑memory directory caches to accelerate repeated lookups without touching the backing disks. When a read targets bytes inside the cached segments, VidCacheFS serves them instantly from SSD while concurrently executing a dummy read to the backing disk to trigger it to spinup. The drive will be then ready to serve data when the read requests depletes the cache. This ensures instant and seamless playback of media files. It also watches for changes to the directories, new files are automatically cached, deleted files will removed from the cache, metadata cache will be updated on change. Multiple mount points can be defined and for each mount point you can configure head/tail cache sizes and cache limits. Cache eviction happens on basis of LRU (Least Recently Accessed) Requirements are: - 'Python 3 for UNRAID' plugin - Python packages fusepy and inotify - 'CA User Scripts' Plugin - Dynamix Cache Dirs plugin could be helpful The script and instructions can be found on Github: https://github.com/racquemis/VidCacheFS-Unraid