July 4, 20251 yr I recently moved to a region with somewhat unstable electrical power. I've been experiencing full blackouts as well as voltage drops below expected levels.About 3 days ago, there was a power outage, and I simply turned the server back on afterward without paying much attention to its state. However, I noticed a constant spin-down and spin-up noise from one of the HDDs, happening every 10–20 seconds. Unfortunately, I didn’t have time to investigate at that moment.Yesterday, I finally checked, and one of the HDDs is showing the error: "Unmountable: wrong or no file system". Coincidentally, this is the same drive that previously had a faulty SATA cable.I replaced the cable, but the error persists.Another issue I noticed is with ErsatzTV, which I use to create IPTV channels. It reports when media files become unavailable, and it’s now showing around 4,000 media files as missing from my total of over 10,000. I checked some of these files manually, and they are indeed gone. I believe they were on the HDD that’s now unmountable.However, shouldn’t Unraid emulate the data in such cases?I’d like to know how to proceed in this situation, and whether it's possible to recover the drive and the missing data.Off-topic: Any recommendations on what kind of UPS I should get to avoid this kind of issue in the future? Does it have to be a pure sine wave model, or can a more basic one do the job?Thank you all for your help.nashome-diagnostics-20250704-1218.zip Edited July 10, 20251 yr by Rafael
July 4, 20251 yr Community Expert Check filesystem on disk1.P.S. there appears to be a bad RAM stick:Jul 4 01:33:13 NASHOME mcelog: Fallback Socket memory error count 69 exceeded threshold: 13203 in 24h
July 4, 20251 yr Author 5 minutes ago, JorgeB said:Check filesystem on disk1.P.S. there appears to be a bad RAM stick:Jul 4 01:33:13 NASHOME mcelog: Fallback Socket memory error count 69 exceeded threshold: 13203 in 24hThe Check filesystem result:Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... sb_ifree 701, counted 700 sb_fdblocks 15208003, counted 22022919 - 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 = 3 - agno = 2 - agno = 1 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.About the memory, I'm getting a new one, but I've been using it for a few years, with this failure, something annoying, however, it hasn't caused any major problems so far, just minor problems! 🤣 Edited July 4, 20251 yr by Rafael
July 5, 20251 yr Author 7 hours ago, JorgeB said:Check filesystem on disk1.P.S. there appears to be a bad RAM stick:Jul 4 01:33:13 NASHOME mcelog: Fallback Socket memory error count 69 exceeded threshold: 13203 in 24hI try to click on "FIX" and receive this message:Phase 1 - find and verify superblock...Phase 2 - using internal log - zero log...ERROR: The filesystem has valuable metadata changes in a log which needs tobe replayed. Mount the filesystem to replay the log, and unmount it beforere-running xfs_repair. If the filesystem is a snapshot of a mountedfilesystem, you may need to give mount the nouuid option. If you are unableto mount the filesystem, then use the -L option to destroy the log andattempt a repair. Note that destroying the log may cause corruption --please attempt a mount of the filesystem before doing this.Dirty log detected. Note: While there is some risk, if it is not possible to first mount the filesystem to clear the log, zeroing it is the only option to try and repair the filesystem, and in most cases it results in little or no data loss.
July 5, 20251 yr Community Expert Solution Destroy the log, it's the only option, and it's usually safe.
July 5, 20251 yr Author 6 hours ago, JorgeB said:Destroy the log, it's the only option, and it's usually safe.After destroy log, this is result:Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_ifree 701, counted 700 sb_fdblocks 15208003, counted 22022919 - found root inode chunk Phase 3 - for each AG... - scan and 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 = 3 - agno = 2 clearing reflink flag on inodes when possible Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (5:1740302) is ahead of log (1:2). Format log to cycle 8. doneAnd run de Check Again: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.After this, I started the array on normal mode, my disk back to life with all the space used, I believe my media is back, I'm just waiting for the program to check if anything is missing. But I'm looking to this error on my logs:Jul 5 10:19:03 NASHOME kernel: ata5.00: exception Emask 0x50 SAct 0x6 SErr 0x4090800 action 0xe frozenJul 5 10:19:03 NASHOME kernel: ata5.00: irq_stat 0x00400040, connection status changedJul 5 10:19:03 NASHOME kernel: ata5: SError: { HostInt PHYRdyChg 10B8B DevExch }Jul 5 10:19:03 NASHOME kernel: ata5.00: failed command: READ FPDMA QUEUEDJul 5 10:19:03 NASHOME kernel: ata5.00: cmd 60/00:08:18:4b:12/01:00:85:00:00/40 tag 1 ncq dma 131072 inJul 5 10:19:03 NASHOME kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 5 10:19:03 NASHOME kernel: ata5.00: status: { DRDY }Jul 5 10:19:03 NASHOME kernel: ata5.00: failed command: READ FPDMA QUEUEDJul 5 10:19:03 NASHOME kernel: ata5.00: cmd 60/00:10:d8:ce:f1/01:00:80:00:00/40 tag 2 ncq dma 131072 inJul 5 10:19:03 NASHOME kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x50 (ATA bus error)Jul 5 10:19:03 NASHOME kernel: ata5.00: status: { DRDY }Jul 5 10:19:03 NASHOME kernel: ata5: hard resetting linkata5 is the same HDD with issues before.Do you know what could be happening? And thank you very much for all the help you are giving me, you are saving my life. 😅 nashome-diagnostics-20250705-1115.zip
July 6, 20251 yr Community Expert 17 hours ago, Rafael said:Do you know what could be happening?That looks more like a power/connection issue, replace both cables and see if they go away.
July 10, 20251 yr Author On 7/6/2025 at 4:59 AM, JorgeB said:That looks more like a power/connection issue, replace both cables and see if they go away.Then I will check this, but for now, my problem was solved and the data recovered! Thank you so much for your help again saved my life.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.