Shadey1

Yeah I'd done this weeks ago, seemed to need removing and readding. Weirdly kodi is now double scanning anything new, so I need to work that out, I wonder if it's because the app data moved drive but I'll do some digging

EDIT: Ignore that, I removed each one and remapped them. It's working fine. How very odd. Thanks again for all the help! Yeah it all looked the same, I double checked and moved app data over to disk 1 again. It wouldn't let me delete anything on disk 7 so I formatted it, it took a few minutes and then the array was back up and running with app data having repopulated onto disk 7 by itself. The only issue is that I still cannot access the array from my windows machines still

Ok, it's running a scan now! I'll let you know when it's done. Thanks again

Amazing, my docker works now. Thank you! (EDIT: I installed duplicate-file-handler to check the state of the drive and it just hangs, I then checked the docker images and it's putting them on disk 7, so it's filling up and breaks the dockers again. I think I need to move them to another drive in that case) I still have this issue though, and a disk7 full of the stuff I moved to disk1 Is it as simple as formatting disk 7 now and it should stop getting confused? Mapped drive: Network location (with the right password)

Jul 7 18:54:46 Wintermute ool www[13295]: /usr/local/emhttp/plugins/dynamix/scripts/reiserfs_check 'start' '/dev/md7p1' 'WDC_WD40EZRZ-00GXCB0_WD-WCC7K7PFVDZK' '' Nothing again, both for CLI and GUI. It seems to start to run then ignore it all. I tried deleting a file off disk 7 and it shows a permissions error. or it deletes and hides it until you reboot. I saw this in the logs last reboot

I've rebooted the server a few times, and it didn't even start the first 2 tries, now this. Jul 7 16:37:29 Wintermute ool www[12116]: /usr/local/emhttp/plugins/dynamix/scripts/reiserfs_check 'start' '/dev/md7p1' 'WDC_WD40EZRZ-00GXCB0_WD-WCC7K7PFVDZK' '' or reiserfsck 3.6.27 Will read-only check consistency of the filesystem on /dev/md7p1 Will put log info to 'stdout' ########### reiserfsck --check started at Mon Jul 7 16:37:29 2025 ########### Replaying journal: Replaying journal: Done. Reiserfs journal '/dev/md7p1' in blocks [18..8211]: 0 transactions replayed Or via CLI Also worth noting that I checked all the cables in the machine, nothing loose.

And now this after the restart. I think it's because the drive is full, but I can't see an easy way to confirm it moved all the files other than scrolling 2 screens side by side right now I've worked out a way to do it. Top level file structure and 'calcultate' Movies is 3 files different, no big deal, Disk 1 (the newer is the largest) The only area of significant difference is 'appdata' which appears to be about 0.9gig larger on the old drive. I suspect this is down to it still updating as I'm doing stuff, but to the old drive! That's also insanely large for a small database of watched episodes etc! I tried to delete some things from both drives via the unraid GUI, but the stuff on disk 7 just stays, no error, nothing. It does remove on disk 1 though! I'm thinking at this stage it's wipe disk 7, and maybe repoint the docker images to disk 1?

I also ran it on disk 1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. After that I was unable to start the array again, no error just nothing after pressing start. Rebooted unraid and it works again.

Hey, I decided it was time to stop ignoring the reiserfs is depreciated message and do something about it I took the opportunity to move out a 2tb for a 6tb and add more storage. I move everything I can to the other drives using unbalanced. It can't move a few episodes but I'm not bothered, I pull the drive, add the new one and let it rebuild. it makes it resierfs without asking me what file system I wanted (so I think I missed something here). After the rebuild I finish moving the remaining files to Disk 7, spin the server down, format disk 1 for xfs and try to move everything over from disk 7. The plan being to repeat the cycle for the next few weeks and update every drive as I go. Something odd happens here, the move command fails at some stage and I restart it, and complete the move but disk 7 never gets any space back, and as you can see disk 1 is now fuller than disk 7 was! At the same time this has happened I start to see other odd behaviour, all the machines running kodi suddenly can't see the mariadb docker which keeps all the played statuses etc Trying to connect to the server via windows on 3 separate machines gets this: The docker images appear to run until you try to access them, and after they stop you get this: The log on //unraid I've tried to rerun new docker safe permissions thinking it was that and it's all looking fine. I wanted to install a plugin to check for duplicates and free up space on disk 7 but no dockers will install and I can't manually look at the shares as I can't access them via windows. System log I'm not sure where to turn next so any help is very apprecaited! I was leaning towards formatting disk 1 and trying again, but I'm worried the mariadb is broken as well Thanks!

Just wanted to say thanks again, just rebuilding parity but it looks like it's going well. Next thing on the pad is the reiserFS issues, but at least I have a while to sort that!

Ah thank you, that makes sense, I've ordered a drive and I'll get that running asap Typical that it dies the second I buy a new one.

Thank you! So am I right in thinking then that: Step 1 is take out the replacement drive since parity failed. Step 2 replace the parity drive Step 3 New drive to expand space And thank you again for helping, I find I don't have to think about my server for so long that when I do I question all the basics again!

WDC_WD60EFRX-68L0BN1_WD-WX21DC74D05N-20230713-2207.txtWell it jumped from 20% to complete really quickly. Took 90-120 mins Staring at it, I've realised I don't know how to interpret that at all these days!

Cool, I'm running the long smart test on the parity drive now. I'll report back in about 12 hours I guess! Thank you

Finished while I was at work.

Yeah it's sat here, it hadn't failed I just needed more space

That's me being dumb, I thought I had. Sorry about that! wintermute-diagnostics-20230712-0631.zip

I need some help please! Parity ran Sunday or Monday night, and was fine 0 errors. I then replaced a small (and old 13y+ drive) Tuesday, let unraid rebuild and saw this when I checked in this morning. I had some loose cables when I first booted back up, reseated them all and added the drive to the array. That's a lot of errors! WDC_WD60EFRX-68L0BN1_WD-WX21DC74D05N-20230712-0631 parity (sdc).txt syslog.txt

I realise this might be the dumbest question yet...but where do I run the MSR script! open a console? Stick it in extra commands? I got about an extra 500H/s just by running in privileged so I want to see what this ryzen can do 🤪 EDIT: I've installed user scripts, set the query and run it. Restarted the docker image, MSR not set Rebooted a few times and tried it, still nothing. EDIT EDIT: Dumb dumb here just reread the script, it'll show as not loading but will. I have the exact same Hash rate 🤦‍♂️ After some digging at https://monerobenchmarks.info/index.php It's doing about the best it can! Whoop