January 18, 20233 yr Hi all, Very new to all this so please bear with me, last night while searching thru some server files on a separate computer, windows couldn't find my shares. Shut down the windows computer and restarted it and Disk 1 came up with a 'unmountable: wrong or no file system' message. Tried a different sata port and new cable but still nothing. Also can no longer see any of the files that would have been on the drive. Will add the diagnostics below but please talk slow as I have a very, very basic understanding of what I'm doing
January 18, 20233 yr Author Just to show how basic, I cant get the zip file to attach, what the hell am I doing wrong!!??🙄
January 18, 20233 yr Community Expert Looks like it's a forum problem https://forums.unraid.net/topic/133863-forum-attachments-not-working/#comment-1216484 tower-diagnostics-20220526-0944.zip
January 18, 20233 yr Author Sorry, an unknown server error occurred when uploading this file. (Error code: -200)
January 18, 20233 yr Community Expert Since it's a forum issue you can post the diags on dropbox, goole drive, etc and post the link here.
January 18, 20233 yr Author Is there anything in the zip file I can open and copy/paste as text that would help?
January 18, 20233 yr Author Sorry I dont have either of those and while trying to get google drive organised, thats kicking back with an issue!! Its really not my day🙄
January 18, 20233 yr Community Expert We need diags after array start please, forum attachments should be working now, but if not use wesendit again.
January 18, 20233 yr Author This is a case of a little bit of knowledge being a dangerous thing. I thought if I replaced the drive and did a parity rebuild everything would be fine but it stalled about 5% in, so I put the original drive back in and if I start the array it is going to try and do a parity rebuild again and I'm worried 1) itll wipe the original drive and 2) I've already gone to far to save the data
January 19, 20233 yr Author This is the report Phase 1 - find and verify superblock... - block cache size set to 527120 entries Phase 2 - using internal log - zero log... zero_log: head block 262496 tail block 262479 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... block (2,468703-468716) multiply claimed by cnt space tree, state - 4 block (2,9384387-9384400) multiply claimed by cnt space tree, state - 2 agf_freeblks 45486949, counted 45486922 in ag 2 agf_freeblks 36321250, counted 36320029 in ag 0 agi_freecount 7894, counted 7891 in ag 0 sb_fdblocks 269167766, counted 275982655 - 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 a free inode 1795285099 is in use, would correct imap and clear inode imap claims a free inode 1795285101 is in use, would correct imap and clear inode - agno = 1 - agno = 2 data fork in ino 4298782906 claims free block 537347853 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... free space (2,477286-477299) only seen by one free space btree free space (2,9396032-9396045) only seen by one free space btree free space (2,9396090-9396103) only seen by one free space btree free space (2,9396158-9396171) only seen by one free space btree - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 entry "Screenshots" in shortform directory 4298784859 references free inode 1795285101 would have junked entry "Screenshots" in directory inode 4298784859 entry "Lake.Placid.Legacy.2018.1080p.WEBRip.x264-[YTS.AM].mp4" in shortform directory 1795285098 references free inode 1795285099 would have junked entry "Lake.Placid.Legacy.2018.1080p.WEBRip.x264-[YTS.AM].mp4" in directory inode 1795285098 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 Maximum metadata LSN (1:264338) is ahead of log (1:262496). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Jan 19 21:35:41 2023 Phase Start End Duration Phase 1: 01/19 21:35:26 01/19 21:35:28 2 seconds Phase 2: 01/19 21:35:28 01/19 21:35:28 Phase 3: 01/19 21:35:28 01/19 21:35:41 13 seconds Phase 4: 01/19 21:35:41 01/19 21:35:41 Phase 5: Skipped Phase 6: Skipped Phase 7: Skipped Total run time: 15 seconds
January 19, 20233 yr Community Expert Run it again without -n or nothing will be done, if it asks for it use -L
January 19, 20233 yr Author I should do this, yes? The Options field is initialized with -n which specifies check-only. If repair is needed, you should run a second Check pass, setting the Options blank; this will permit xfs_repair to fix the file system
January 19, 20233 yr Author this is the report now, unsure of next step?? 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 block (2,468703-468716) multiply claimed by cnt space tree, state - 4 block (2,9384387-9384400) multiply claimed by cnt space tree, state - 2 agf_freeblks 45486949, counted 45486922 in ag 2 agf_freeblks 36321250, counted 36320029 in ag 0 agi_freecount 7894, counted 7891 in ag 0 sb_fdblocks 269167766, counted 275982655 - 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 a free inode 1795285099 is in use, correcting imap and clearing inode cleared inode 1795285099 imap claims a free inode 1795285101 is in use, correcting imap and clearing inode cleared inode 1795285101 - agno = 1 - agno = 2 data fork in ino 4298782906 claims free block 537347853 - 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 = 2 - agno = 3 - agno = 1 entry "Screenshots" in shortform directory 4298784859 references free inode 1795285101 junking entry "Screenshots" in directory inode 4298784859 entry "Lake.Placid.Legacy.2018.1080p.WEBRip.x264-[YTS.AM].mp4" in shortform directory 1795285098 references free inode 1795285099 junking entry "Lake.Placid.Legacy.2018.1080p.WEBRip.x264-[YTS.AM].mp4" in directory inode 1795285098 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 ... disconnected inode 1795285105, moving to lost+found disconnected inode 1795285106, moving to lost+found disconnected inode 1795285107, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 4298784859 nlinks from 4 to 3 Maximum metadata LSN (1:264338) is ahead of log (1:2). Format log to cycle 4. done
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.