flixxx

Anyone can offer any suggestions?

I noticed on the bootup log the following line Apr 9 05:42:02 kenny kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks Is that a concern? What does it mean?

Since I upgraded to version 6.12 i have random crashes, difficult to replicate causing the server to be completely unresponsive remotely and physically there (the screen won't even turn on or keyboard respond) forcing me to reboot. Things I have tried; - Ensured Docker is set to IPVLAN - Upgraded from 6.12.6 to 6.12.9 - Enabled the syslog server I have another crashed on April 9th, what seems to be at around 3:32 am, the logs don't seem to provide anything of help. I have attached my diagnostics and the syslog, any help or input would be appreciated. Previous to yesterdays crash, the 2 times before that, I do know what the last thing i did was before it crashed: I have a windows VM running Blueiris and i logged into it to check the cameras. Yesterdays though, i did not perform that action. kenny-diagnostics-20240409-0554.zip syslog-192.168.1.110.log

I have not, i will try that the moment the parity ends. I do have a silly issue, since i run this headless. The last time i plugged my monitor in, it works when it's booted up, but during boot up (BIOS, POST, etc...) the screen doesn't work so i never see the menu to run memtest. I never bothered to try to fix it - any recommendation on what to look for?

I ran a second parity check and once again it has thousands of errors. I ran a filesystem check (with the -n), and then without the -n and the following was returned (with -n): 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 - 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 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. I am running another parity check now, here is the latest diagnostics kenny-diagnostics-20240204-1954.zip

I will run another check. The last time i checked the filesystem it made a huge mess of my array - bunch of files got lost, etc.... How can I ensure i don't lose anything? Ok, i can certainly do that after i fix this issue

Monthly parity check this month (1st of every month) had thousands of errors it corrected. I shutdown the server, checked the cable connections to be sure. Rebooted and ran a parity check (without sync) and it found an additional 4 errors - what could it be? attached diagnostics kenny-diagnostics-20240204-0647.zip

Thank you, can you point me where in my diagnostics file you discovered that I may be having this issue? Also, i have updated to the latest version of deluge, how do i ensure this is fixed? (I've been on this unraid version for as long as i can remember)

Hello, this morning i couldn't load my unraid dashboard. All the containers seemed to have still been working - I was able to access the ones that had a webgui through their proper links but the dashboard was non responsive. here are my logs, i had to log in through SSH to get them kenny-diagnostics-20231208-0745.zip

I've narrowed down the problem to the docker Codeproject AI. When i turn it off, it jumps back to about 140MB/s. With it on it crawls to about 20 MB/s Total CPU load with it on goes to a max of 20%, docker stats commands shows it peak at 2%. I just tried pinning cpu on that particular docker to all except 0/1 and it seems to get a bit better to 95 MB/s. Still gonna play around with it - i've had this docker running for at least a year with no issue and the config hasn't changed.

Attached is an updated diagnostics 24 hours after parity has started. I have a scheduler to check parity every month and for years it wouldn't take more than 1.5 days. I upgraded to a 20TB and this is the behaviour now - hoping to get to the bottom of it. kenny-diagnostics-20231122-0703.zip

Nevermind, found the issue. I had the syslog server running and pointing to the unraid while i was troubleshooting other things a couple of days ago and forgot to turn it off. The moment i turned it off, the speed jumped and it will complete at a reasonable time. It dropped back down again - will continue to monitor and post diags in a few hours

Thanks, yes i stopped it because i was running a short self test and was taking very long and i thought it might have something to do with it. I restarted it now and will keep it, still showing at about 17-20MB/s

Hello, I recently upgraded my parity from a 4TB to 20TB hard drive. Precleared it, did the parity write. Now, I want to ensure it's correct before i install any new hard drives. I am running a parity check (without write correction) and it's running extremely slow - 18MB/s, 12 days to finish. With my 4 TB, it would take a little over a day. I've attached the diagnostics while parity check is running. kenny-diagnostics-20231121-0707.zip

Hello, I have a TimeMachine backup on the server setup. After updating to Sonoma, I was plagued with problems and did a restore - it would take 4 hours to do it over the network. I thought I can transfer the files to an external hard drive and speed up the process. when I run the command rsync -a SRC(unraid folder) DEST(unassigned mounted disk) I get the error "chown....failed: Operation not permitted" I did some digging and because my external hard drive is formatted as exFAT, the permissions don't transfer over. My question is; Is there a better way to copy the time machine backup over to an external hard drive for it to be used on my mac?