falloutboy12

alright - didn't ask for -L - is that the end of it? Everything should be better now? Phase 1 - find and verify superblock... - block cache size set to 1524864 entries Phase 2 - using internal log - zero log... zero_log: head block 1360010 tail block 1360010 - scan filesystem freespace and inode maps... agi unlinked bucket 3 is 8163203 in ag 3 (inode=3229388675) agi unlinked bucket 23 is 2626775 in ag 0 (inode=2626775) - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 imap claims in-use inode 2714806 is free, correcting imap data fork in regular inode 2735687 claims used block 627747 correcting nextents for inode 2735687 bad data fork in inode 2735687 cleared inode 2735687 data fork in ino 3211142 claims free block 401082 imap claims in-use inode 3211142 is free, correcting imap data fork in regular inode 3211143 claims used block 401711 correcting nextents for inode 3211143 bad data fork in inode 3211143 cleared inode 3211143 imap claims in-use inode 3211145 is free, correcting imap data fork in regular inode 3211146 claims used block 401719 correcting nextents for inode 3211146 bad data fork in inode 3211146 cleared inode 3211146 data fork in regular inode 3211147 claims used block 401727 correcting nextents for inode 3211147 bad data fork in inode 3211147 cleared inode 3211147 data fork in regular inode 3211148 claims used block 400189 correcting nextents for inode 3211148 bad data fork in inode 3211148 cleared inode 3211148 data fork in regular inode 3211149 claims used block 400197 correcting nextents for inode 3211149 bad data fork in inode 3211149 cleared inode 3211149 data fork in regular inode 3211150 claims used block 660128 correcting nextents for inode 3211150 bad data fork in inode 3211150 cleared inode 3211150 data fork in ino 3302425 claims free block 412880 imap claims in-use inode 3302425 is free, correcting imap data fork in regular inode 3302460 claims used block 412633 correcting nextents for inode 3302460 bad data fork in inode 3302460 cleared inode 3302460 data fork in regular inode 4181410 claims used block 1175114 correcting nextents for inode 4181410 bad data fork in inode 4181410 cleared inode 4181410 - agno = 1 - agno = 2 - agno = 3 Metadata CRC error detected at 0x45fb48, xfs_dir3_block block 0xaeca65a0/0x1000 bad directory block magic # 0x68747470 in block 0 for directory inode 3223453471 corrupt block 0 in directory inode 3223453471 will junk block no . entry for directory 3223453471 no .. entry for directory 3223453471 problem with directory contents in inode 3223453471 cleared inode 3223453471 - 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 entry "chapter11.jpg" in shortform directory 3223590863 references free inode 3223590893 junking entry "chapter11.jpg" in directory inode 3223590863 entry "fe1dc1fbc9cecacfdf0dc799f740d609ded305f0.jpg" at block 1 offset 2080 in directory inode 2737768 references free inode 2735687 clearing inode number in entry at offset 2080... entry "tv.plex.agents.music_223b88388d86c873bcc5cffec5b8abd3841f5b61" in shortform directory 4181415 references free inode 4181410 junking entry "tv.plex.agents.music_223b88388d86c873bcc5cffec5b8abd3841f5b61" in directory inode 4181415 entry "tracks" in shortform directory 1077963293 references free inode 3223453471 junking entry "tracks" in directory inode 1077963293 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 bad hash table for directory inode 2737768 (no data entry): rebuilding rebuilding directory inode 2737768 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 2224209, moving to lost+found disconnected dir inode 2226443, moving to lost+found disconnected dir inode 2238408, moving to lost+found disconnected dir inode 2246231, moving to lost+found disconnected dir inode 2251383, moving to lost+found disconnected inode 2626775, moving to lost+found disconnected inode 2714806, moving to lost+found disconnected inode 3211142, moving to lost+found disconnected inode 3211145, moving to lost+found disconnected inode 3302425, moving to lost+found disconnected dir inode 2152484929, moving to lost+found disconnected dir inode 2152486609, moving to lost+found disconnected inode 2152499600, moving to lost+found disconnected inode 2152505220, moving to lost+found disconnected dir inode 2152527136, moving to lost+found disconnected dir inode 2152530303, moving to lost+found disconnected dir inode 2152570879, moving to lost+found disconnected dir inode 2152574983, moving to lost+found disconnected inode 3229388674, moving to lost+found disconnected inode 3229388675, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 2212737 nlinks from 2 to 13 resetting inode 1076033303 nlinks from 3 to 2 resetting inode 2294004 nlinks from 1 to 2 resetting inode 3223583600 nlinks from 1 to 2 resetting inode 3223590892 nlinks from 1 to 2 resetting inode 3223590895 nlinks from 1 to 2 resetting inode 3223852970 nlinks from 3 to 2 resetting inode 2153007510 nlinks from 320 to 319 resetting inode 2153052351 nlinks from 3 to 2 resetting inode 2153056247 nlinks from 3 to 2 resetting inode 1077963293 nlinks from 3 to 2 resetting inode 3224811785 nlinks from 3 to 2 XFS_REPAIR Summary Thu Jul 6 06:34:15 2023 Phase Start End Duration Phase 1: 07/06 06:32:46 07/06 06:32:46 Phase 2: 07/06 06:32:46 07/06 06:32:52 6 seconds Phase 3: 07/06 06:32:52 07/06 06:33:33 41 seconds Phase 4: 07/06 06:33:33 07/06 06:33:33 Phase 5: 07/06 06:33:33 07/06 06:33:33 Phase 6: 07/06 06:33:33 07/06 06:34:14 41 seconds Phase 7: 07/06 06:34:14 07/06 06:34:14 Total run time: 1 minute, 28 seconds done

Thanks Jorge for your help - here are results of xfs_repair -nv from gui: Phase 1 - find and verify superblock... - block cache size set to 1524864 entries Phase 2 - using internal log - zero log... zero_log: head block 1360010 tail block 1360010 - scan filesystem freespace and inode maps... agi unlinked bucket 23 is 2626775 in ag 0 (inode=2626775) agi unlinked bucket 3 is 8163203 in ag 3 (inode=3229388675) - 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 imap claims in-use inode 2714806 is free, correcting imap data fork in regular inode 2735687 claims used block 627747 correcting nextents for inode 2735687 bad data fork in inode 2735687 would have cleared inode 2735687 data fork in ino 3211142 claims free block 401082 imap claims in-use inode 3211142 is free, correcting imap data fork in regular inode 3211143 claims used block 401711 correcting nextents for inode 3211143 bad data fork in inode 3211143 would have cleared inode 3211143 imap claims in-use inode 3211145 is free, correcting imap data fork in regular inode 3211146 claims used block 401719 correcting nextents for inode 3211146 bad data fork in inode 3211146 would have cleared inode 3211146 data fork in regular inode 3211147 claims used block 401727 correcting nextents for inode 3211147 bad data fork in inode 3211147 would have cleared inode 3211147 data fork in regular inode 3211148 claims used block 400189 correcting nextents for inode 3211148 bad data fork in inode 3211148 would have cleared inode 3211148 data fork in regular inode 3211149 claims used block 400197 correcting nextents for inode 3211149 bad data fork in inode 3211149 would have cleared inode 3211149 data fork in regular inode 3211150 claims used block 660128 correcting nextents for inode 3211150 bad data fork in inode 3211150 would have cleared inode 3211150 data fork in ino 3302425 claims free block 412880 imap claims in-use inode 3302425 is free, correcting imap data fork in regular inode 3302460 claims used block 412633 correcting nextents for inode 3302460 bad data fork in inode 3302460 would have cleared inode 3302460 data fork in regular inode 4181410 claims used block 1175114 correcting nextents for inode 4181410 bad data fork in inode 4181410 would have cleared inode 4181410 - agno = 1 - agno = 2 - agno = 3 Metadata CRC error detected at 0x45fb48, xfs_dir3_block block 0xaeca65a0/0x1000 bad directory block magic # 0x68747470 in block 0 for directory inode 3223453471 corrupt block 0 in directory inode 3223453471 would junk block no . entry for directory 3223453471 no .. entry for directory 3223453471 problem with directory contents in inode 3223453471 would have cleared inode 3223453471 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 1 - agno = 2 bad directory block magic # 0x68747470 in block 0 for directory inode 3223453471 corrupt block 0 in directory inode 3223453471 would junk block no . entry for directory 3223453471 no .. entry for directory 3223453471 problem with directory contents in inode 3223453471 would have cleared inode 3223453471 entry "chapter11.jpg" in shortform directory 3223590863 references free inode 3223590893 would have junked entry "chapter11.jpg" in directory inode 3223590863 data fork in regular inode 2735687 claims used block 627747 correcting nextents for inode 2735687 bad data fork in inode 2735687 would have cleared inode 2735687 entry "fe1dc1fbc9cecacfdf0dc799f740d609ded305f0.jpg" at block 1 offset 2080 in directory inode 2737768 references free inode 2735687 would clear inode number in entry at offset 2080... data fork in regular inode 3211143 claims used block 401711 correcting nextents for inode 3211143 bad data fork in inode 3211143 would have cleared inode 3211143 data fork in regular inode 3211146 claims used block 401719 correcting nextents for inode 3211146 bad data fork in inode 3211146 would have cleared inode 3211146 data fork in regular inode 3211147 claims used block 401727 correcting nextents for inode 3211147 bad data fork in inode 3211147 would have cleared inode 3211147 data fork in regular inode 3211148 claims used block 400189 correcting nextents for inode 3211148 bad data fork in inode 3211148 would have cleared inode 3211148 data fork in regular inode 3211149 claims used block 400197 correcting nextents for inode 3211149 bad data fork in inode 3211149 would have cleared inode 3211149 data fork in regular inode 3211150 claims used block 660128 correcting nextents for inode 3211150 bad data fork in inode 3211150 would have cleared inode 3211150 data fork in regular inode 3302460 claims used block 412633 correcting nextents for inode 3302460 bad data fork in inode 3302460 would have cleared inode 3302460 data fork in regular inode 4181410 claims used block 1175114 correcting nextents for inode 4181410 bad data fork in inode 4181410 would have cleared inode 4181410 entry "tv.plex.agents.music_223b88388d86c873bcc5cffec5b8abd3841f5b61" in shortform directory 4181415 references free inode 4181410 would have junked entry "tv.plex.agents.music_223b88388d86c873bcc5cffec5b8abd3841f5b61" in directory inode 4181415 entry "tracks" in shortform directory 1077963293 references free inode 3223453471 would have junked entry "tracks" in directory inode 1077963293 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 entry "fe1dc1fbc9cecacfdf0dc799f740d609ded305f0.jpg" in directory inode 2737768 points to free inode 2735687, would junk entry bad hash table for directory inode 2737768 (no data entry): would rebuild would rebuild directory inode 2737768 entry "tv.plex.agents.music_223b88388d86c873bcc5cffec5b8abd3841f5b61" in shortform directory inode 4181415 points to free inode 4181410 would junk entry - agno = 1 entry "tracks" in shortform directory inode 1077963293 points to free inode 3223453471 would junk entry - agno = 2 - agno = 3 entry "chapter11.jpg" in shortform directory inode 3223590863 points to free inode 3223590893 would junk entry - traversal finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 2224209, would move to lost+found disconnected dir inode 2226443, would move to lost+found disconnected dir inode 2238408, would move to lost+found disconnected dir inode 2246231, would move to lost+found disconnected dir inode 2251383, would move to lost+found disconnected inode 2626775, would move to lost+found disconnected inode 2714806, would move to lost+found disconnected inode 3211142, would move to lost+found disconnected inode 3211145, would move to lost+found disconnected inode 3302425, would move to lost+found disconnected dir inode 2152484929, would move to lost+found disconnected dir inode 2152486609, would move to lost+found disconnected inode 2152499600, would move to lost+found disconnected inode 2152505220, would move to lost+found disconnected dir inode 2152527136, would move to lost+found disconnected dir inode 2152530303, would move to lost+found disconnected dir inode 2152570879, would move to lost+found disconnected dir inode 2152574983, would move to lost+found disconnected inode 3229388674, would move to lost+found disconnected inode 3229388675, would move to lost+found Phase 7 - verify link counts... would have reset inode 1076033303 nlinks from 3 to 2 would have reset inode 2294004 nlinks from 1 to 2 would have reset inode 1077963293 nlinks from 3 to 2 would have reset inode 2626775 nlinks from 4294967295 to 1 would have reset inode 3223583600 nlinks from 1 to 2 would have reset inode 3223590892 nlinks from 1 to 2 would have reset inode 3223590895 nlinks from 1 to 2 would have reset inode 3223852970 nlinks from 3 to 2 would have reset inode 2153007510 nlinks from 320 to 319 would have reset inode 2153052351 nlinks from 3 to 2 would have reset inode 2153056247 nlinks from 3 to 2 would have reset inode 3224811785 nlinks from 3 to 2 would have reset inode 3229388675 nlinks from 4294967295 to 1 No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Jul 6 05:31:33 2023 Phase Start End Duration Phase 1: 07/06 05:30:06 07/06 05:30:06 Phase 2: 07/06 05:30:06 07/06 05:30:11 5 seconds Phase 3: 07/06 05:30:11 07/06 05:30:52 41 seconds Phase 4: 07/06 05:30:52 07/06 05:30:53 1 second Phase 5: Skipped Phase 6: 07/06 05:30:53 07/06 05:31:33 40 seconds Phase 7: 07/06 05:31:33 07/06 05:31:33 Total run time: 1 minute, 27 seconds

After a power loss and now noticing I have a ups that needs to be replaced, my server went through an unclean shutdown and has never been the same since. I'm running Plex and Transmission dockers and not much else - a very simple setup but I am now having trouble getting plex to behave - I keep having the appdata and apps share disappearing. I tried to shut off my old Plex install and start from scratch using the linuxserver Plex install instead. However, that also causes problems every time I attempt to add my media back in and it starts indexing, the shares on the cache drive will again disappear. If i start up the server and start the new plex instance, I will be able to get into plex interface and see parts of the files that were indexed. I also took an appdata backup but I'm not sure if I'm just backing up corrupt data at this point. I checked and to my novice eyes, I don't see anything wrong with the cache drive (samsung). However am seeing problems in the logs for that drive that I think point to a corrupt file system: Jul 4 15:37:14 UNRAID emhttpd: read SMART /dev/sdb Jul 4 08:29:18 UNRAID emhttpd: shcmd (2251): mount -t xfs -o noatime,nouuid /dev/sdb1 /mnt/cache Jul 4 08:29:18 UNRAID kernel: XFS (sdb1): Mounting V5 Filesystem Jul 4 08:29:19 UNRAID kernel: XFS (sdb1): Ending clean mount Jul 4 09:03:59 UNRAID kernel: XFS (sdb1): Metadata corruption detected at xfs_dir3_data_reada_verify+0x53/0x64 [xfs], xfs_dir3_data_reada block 0xaeca65a0 Jul 4 09:03:59 UNRAID kernel: XFS (sdb1): Unmount and run xfs_repair Jul 4 09:03:59 UNRAID kernel: XFS (sdb1): First 128 bytes of corrupted metadata buffer: Jul 4 09:03:59 UNRAID kernel: XFS (sdb1): Metadata CRC error detected at xfs_dir3_block_read_verify+0x7c/0xf1 [xfs], xfs_dir3_block block 0xaeca65a0 Jul 4 09:03:59 UNRAID kernel: XFS (sdb1): Unmount and run xfs_repair Jul 4 09:03:59 UNRAID kernel: XFS (sdb1): First 128 bytes of corrupted metadata buffer: Jul 4 09:03:59 UNRAID kernel: XFS (sdb1): metadata I/O error in "xfs_da_read_buf+0x9a/0xff [xfs]" at daddr 0xaeca65a0 len 8 error 74 I've tried reviewing the similar items in the forums for this type of issue but I suffer from being a novice at this stuff and not great at understanding my server well enough to make any headway on my own. I attempted an xfs_repair -n but it said it couldn't find a matching block or something - I can't quite remember the result other than it took a few hours and reported that it could not fix itself. Any help would be greatly appreciated! unraid-diagnostics-20230706-0959.zip

I should button this up - replaced all SMR disks and I'm entirely on XFS now and have seen a much better speed and all around more functional server. Thanks for all the help!

I've also rolled back to 6.9.2 after a failed attempt to upgrade to 6.10.2. My usb allocations were somehow messed up - maybe something similar to this where drivers were causing problems reading from the flash drive? Anyway, just wanted to say you're not alone with mystery items just causing inoperable servers with this latest upgrade. I'm gonna watch for some resolution before I consider upgrading - I don't know lots of things but I do know I don't have the time or knowledge to figure this one out on my own...

OK so until I get the parity drive off SMR, I can expect to see 20/mb and under? I didn't realize it was that bad and I got those drives before I knew about the SMR problem. Time to spend more money I guess...

Mostly moving Disk 2 to Disk 3 since there are errors on a couple disks: #ATTRIBUTE NAMEFLAGVALUEWORSTTHRESHOLDTYPEUPDATEDFAILEDRAW VALUE Parity: 187Reported uncorrect0x0032055055000Old ageAlwaysNever45 Disk 1: 199UDMA CRC error count0x003e200200000Old ageAlwaysNever4 Disk 2: 5Reallocated sector count0x0033095095036Pre-failAlwaysNever236 Main Errors column shows all zeros.

Right - so that gets me back to my slowness question - as I'm facing the prospect of moving several TB several times to try to convert these disks, the rates I'm getting right now are going to make this take several months if I'm doing the math right...

right - I'm out of disk slots for my license - I'm moving all the files off this disk, swapping in the new disk so I can preclear and all that which will be several days from what I can remember. As for why I'm on Reiser, I think that was the default when I set up this server ten years ago?

I'm using the clear then remove method to preserve parity.

Hi All - Very much fumbling through this but I've recently moved hardware for my unraid server from an old junky box to a new (to me) Dell R710 server. I've gone through the difficult of getting an H200 card and flashing it to IT mode and updated the SBR to work in the integrated slot. I've moved over my unraid boot stick and all six disks and the array is up and running, but I'm seeing some very slow speeds as I am trying to empty a disk to replace it and I'm not sure where to start. I noticed the slowness when I was using the unbalance plugin - here's an example of what type of speed was being reported in that process. It seems like that plugin is a little unreliable though at reporting transfer metrics since the elapsed time is way off, so next I tried to get stats at the terminal and got this: root@UNRAID:/mnt/disk2/VIDEO/Kids# pv -pra /mnt/disk2/VIDEO/Kids/Cinderella\ \[2015\].mkv > /mnt/disk1/VIDEO/Kids/Cinderella\ \[2015\].mkv [ 246KiB/s] [23.0MiB/s] [=====================================================================================================================================================> ] 87% These speeds seem very slow to me but maybe it's supposed to take several days to clear the contents of a 2TB drive? Mover is off, no parity check is in process - not sure what else might be contending other than two docker images for transmission and plex. I've got diagnostics as well if that helps: Please don't assume anything - there could be several very rookie missteps in this process that I've done. I'm not good with linux and I'm not good with hardware either Thanks in advance for any suggestions...

Thanks johnnie - I've uninstalled preclear - do you think it's safe to reboot?

A couple days back I updated using the gui update function. The server came back online and shares were working at that time. I believe it was the March 11th or 12th when I did that update to 6.4.1. Today I went to check for docker updates and tried to complete one but got an error. Now as I look over at shares I am noticing all my shares seem to be gone. I'm nervous to just reboot and see if it fixes itself. The server is up the gui is functional the network is otherwise OK. Please help! Docker containers: Plex and transmission Plugins preclear and statistics and I just installed Fix common problems. Smart scans seem OK so I don't think it's disks but I haven't configured this server for several years so I'm clueless! Thanks in advance for any help... unraid-diagnostics-20180317-1026.zip

I am also having issues with this plugin using the included script on an 8tb samsung ST8000DM004 with the CPU pegged at 100% and stuck at 49% pre-read

I'm having a problem that I hope is something simple but right now I can't get openssh to reinstall after restart. Can anyone point me in the right direction? I am going in to pckg manager and installing openssh every time I restart my server. It seems like most other packages are working as expected... ALso, please let me know if you need other information than my syslog. Thanks in advance for any help... syslog-2013-11-20.txt