jmztaylor

So that turned out to be the same issue also. This devolved into flash drive becoming read only and not booting anymore. I reflashed it, restored backup, and everything is actually working correctly this time. I have the original files from the flash drive if they would be helpful in figuring out what got corrupted if it wasn't just the flash drive itself

I have another pc with same mb/ram/cpu. I swapped out those 3 and haven't seen a single issue. The other pc doesn't use the sata ports. So hopefully this is the end of this.

Still not quite solved. Pulled that disk and switched to a different PSU. All sata cables were replaced also. And it stayed at ata7 but switched to disk 1. Now its only happening in one loop instead of consistent like before. And according to the logs only happened twice since this boot yesterday. Jul 19 04:49:02 Tower emhttpd: read SMART /dev/sdf Jul 19 04:59:27 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error Jul 19 04:59:27 Tower kernel: ata7.00: failed command: READ FPDMA QUEUED Jul 19 04:59:27 Tower kernel: ata7.00: cmd 60/00:00:d8:ce:58/02:00:5e:00:00/40 tag 0 ncq dma 262144 in Jul 19 04:59:27 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 19 04:59:27 Tower kernel: ata7.00: cmd 60/00:f8:d8:cc:58/02:00:5e:00:00/40 tag 31 ncq dma 262144 in Jul 19 04:59:27 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 19 04:59:27 Tower kernel: ata7.00: status: { DRDY } Jul 19 04:59:27 Tower kernel: ata7: hard resetting link Jul 19 05:12:03 Tower emhttpd: spinning down /dev/sdj

Yeah thats where I am going with this. If I remember right one of my wd 4tb drives was a warranty claim and is a refurb. So I am just going to try that route and leave it out, as I haven't seen a single issue since pulling it completely

Its a 700w psu that only has about a year of usage on it. I swapped around every drive and cable, pulled the GPU in case that was the issue, and moved the problem drive to a different sata controller. Nothing would make the issue go away. I pulled the drive completely and no longer seeing any errors on any drive. I don't want to lose that much storage but tired of dealing with this issue.

Replaced both. Went back through the process of repairing filesystem. Said it was corrected. Parity check started on array start. Logs are showing this now Kul 15 13:05:08 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 15 13:05:08 Tower kernel: ata7.00: configured for UDMA/133 Jul 15 13:05:08 Tower kernel: ata7: EH complete Jul 15 13:05:14 Tower kernel: ata7.00: exception Emask 0x10 SAct 0x1c000 SErr 0x400000 action 0x6 frozen Jul 15 13:05:14 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error Jul 15 13:05:14 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:14 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:14 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:14 Tower kernel: ata7.00: cmd 61/80:80:a8:d2:ad/00:00:7d:01:00/40 tag 16 ncq dma 65536 out Jul 15 13:05:14 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:14 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:14 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 15 13:05:14 Tower kernel: ata7.00: configured for UDMA/133 Jul 15 13:05:14 Tower kernel: ata7: EH complete Jul 15 13:05:20 Tower kernel: ata7.00: exception Emask 0x10 SAct 0xfc4 SErr 0x400000 action 0x6 frozen Jul 15 13:05:20 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error Jul 15 13:05:20 Tower kernel: ata7: SError: { Handshk } Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: cmd 61/40:10:c8:e5:ba/05:00:7d:01:00/40 tag 2 ncq dma 688128 out Jul 15 13:05:20 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:20 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: cmd 61/20:30:08:eb:ba/01:00:7d:01:00/40 tag 6 ncq dma 147456 out Jul 15 13:05:20 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:20 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:20 Tower kernel: ata7.00: cmd 61/38:58:a8:ad:bb/04:00:7d:01:00/40 tag 11 ncq dma 552960 out Jul 15 13:05:20 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:20 Tower kernel: ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Jul 15 13:05:20 Tower kernel: ata7.00: configured for UDMA/133 Jul 15 13:05:20 Tower kernel: ata7: EH complete Jul 15 13:05:25 Tower kernel: ata7: limiting SATA link speed to 3.0 Gbps Jul 15 13:05:25 Tower kernel: ata7.00: exception Emask 0x10 SAct 0x2020 SErr 0x400000 action 0x6 frozen Jul 15 13:05:25 Tower kernel: ata7.00: irq_stat 0x08000000, interface fatal error Jul 15 13:05:25 Tower kernel: ata7: SError: { Handshk } Jul 15 13:05:25 Tower kernel: ata7.00: failed command: WRITE FPDMA QUEUED Jul 15 13:05:25 Tower kernel: ata7.00: cmd 61/40:28:50:36:24/05:00:7f:01:00/40 tag 5 ncq dma 688128 out Jul 15 13:05:25 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:25 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:25 Tower kernel: ata7.00: cmd 61/40:68:90:3b:24/05:00:7f:01:00/40 tag 13 ncq dma 688128 out Jul 15 13:05:25 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error) Jul 15 13:05:25 Tower kernel: ata7.00: status: { DRDY } Jul 15 13:05:25 Tower kernel: ata7: hard resetting link Jul 15 13:05:25 Tower kernel: ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Jul 15 13:05:25 Tower kernel: ata7.00: configured for UDMA/133 Jul 15 13:05:25 Tower kernel: ata7: EH complete

reformatted the drive. Invalidated parity. Let it rebuild parity. And now 5 days later same thing happening. tower-diagnostics-20260714-1004 2.zip

I have already moved too much stuff around and off of disk7. I will just finish moving everything and add it back and format it. Is this a possible drive issue or just something got messed up?

root@Tower:~# xfs_repair -v /dev/mapper/md7p1 Phase 1 - find and verify superblock... - block cache size set to 1503144 entries Phase 2 - using internal log - zero log... zero_log: head block 2063886 tail block 2063868 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If the filesystem is a snapshot of a mounted filesystem, you may need to give mount the nouuid option. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this.

Its not emulated. /mnt/disk7 does not exist. Even though the webui says emulated. I can verify the files on disk7 do not exist in the shares they were assigned.

I did but its still not wanting to mount it without formatting it. Just for ease, I am able to mount it with unassigned plugin and moving everything off of it right now. I will just add it to the array again and format it when done

It wasn't replaced as after repair it was functioning again. Currently if I try to assign the disk to the array it wants to format it and doesn't even emulate the contents.

attached tower-diagnostics-20260708-1017 2.zip

I got it back up for a few days but the same exact thing happened today.

Noticed a disk was offline. Shut it down, verified all connections and started it back up. Met with Unmountable: wrong or no file system. Nearly every reboot has caused a parity re read lately so that is not good timing. Also unable to start in maintenance mode. Check the box, hit start and it just reloads the page. Got it into maintenance mode after a couple reboots. Disk 7 xfs check says Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now. Clicking fix results in Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... writing modified primary superblock sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If the filesystem is a snapshot of a mounted filesystem, you may need to give mount the nouuid option. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. tower-diagnostics-20260702-1337 2.zip