Everything posted by Baregills
-
One of my disks has gone AWOL!
Thanks for the assistance. Running with the -n option as set (as default), the following is produced. <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... - 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 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 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... Maximum metadata LSN (1:2016718) is ahead of log (1:2014534). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting> Running without -n produces:- <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 to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. 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.> I don't know how to proceed from here.
-
One of my disks has gone AWOL!
I was accessing my array quite happily in the night whilst creating a new larger parity disk, but when I checked the log, I saw there were a number of errors. I rebooted hoping that might clear the problem but it did not. I have no idea what has gone wrong since all my disks are relatively new. I have attached the diagnostics hoping that somebody can help me restore my system. tower-diagnostics-20240417-0933.zip
-
5 parity errors that will not go away.
Thanks, but I think the angels are with me. I came upon a post discussing a similar (but not exact) problem somebody was having. They developed the idea that forcing a write of some data to the suspect drive, the issue could be resolved. The logic of this eludes me, but such a simple action was worth a try. And voila, the parity was clear and my concerns gone. (I am however not too keen on deleting that data I wrote - just in case). I appreciate your help and suggestions which I will bear in mind for the future.
-
5 parity errors that will not go away.
Yes. I looked at this but I don't have a Marvel controller. I'm going to try again hoping for something different:-)
-
5 parity errors that will not go away.
Thanks. Yes, I selected correcting check. I have done another run since my initial post and this clearly shows that the error was corrected yet returned for the next (final) run. parity.rtf
-
5 parity errors that will not go away.
I am a new user and since the beginning I have encountered repeated parity errors, five of them each time I run a parity check. I looked here in the forum and found others having similar issues, but could not identify anything applying to my configuration. Assuming that one of my disks may have an issue, I replaced the drive that I identified as the likely culprit. This changed the result of the parity check, but it still gave five errors but now at different places on the drive. I ran the check twice on each configuration (output included here). I'm struggling to know what next to try.parity.rtfparity.rtfparity.rtf
-
How to force connection from Mac Studio to installed 10 Gbe NIC by ethernet rather than wifi.
Thanks to all who responded. The issue has been resolved ....... but I don't quite know how!
-
How to force connection from Mac Studio to installed 10 Gbe NIC by ethernet rather than wifi.
I have just set up my new Unraid server with a 10 Gbe NIC as the only network connection. Everything is generally working as it should, but I have experienced occasions where the Mac connects via wifi rather than the 10 Gbe connection. Obviously that does not perform very well. I can see no way to block a wifi connection. Is there such a setting?