Baregills

Members
  • Posts

    9
  • Joined

  • Last visited

Baregills's Achievements

Noob

Noob (1/14)

0

Reputation

1

Community Answers

  1. That was very scary - but it looks like it has worked!!! Thank you so much.
  2. 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.
  3. 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
  4. 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. Yes. I looked at this but I don't have a Marvel controller. I'm going to try again hoping for something different:-)
  6. 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
  7. 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
  8. Thanks to all who responded. The issue has been resolved ....... but I don't quite know how!
  9. 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?