Jump to content

Cant access web gui after transfering 500gb data and a few restarts


karlpox

Recommended Posts

Hi,

 

Need help getting access to web gui again. All I did was transfer 500gb of data to the unraid server, after maybe 20seconds of doing this the file transfer freezes and I rebooted both server ang source of data PC. I rebooted about 5 times each trying to figure things out and now I no longer have access to my web gui.

 

I got the syslog from my USB. I did a diagnostic on the server by plugging it to a monitor.

syslog.txt

syslog.txt

Link to comment

Hi Johnnie.black,

 

I did what you said. and heres what I got.

 

Phase 1 - find and verify superblock...
        - block cache size set to 324824 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 1544354 tail block 1520767
        - scan filesystem freespace and inode maps...
Metadata corruption detected at xfs_agf block 0xaea851b1/0x200
flfirst 118 in agf 2 too large (max = 118)
agf 118 freelist blocks bad, skipping freelist scan
sb_icount 905152, counted 905600
sb_ifree 155, counted 95
sb_fdblocks 254455625, counted 238421612
        - 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 = 1
        - agno = 3
        - agno = 2
        - agno = 0
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

        XFS_REPAIR Summary    Tue Apr 18 12:14:25 2017

Phase		Start		End		Duration
Phase 1:	04/18 12:10:24	04/18 12:10:24
Phase 2:	04/18 12:10:24	04/18 12:10:32	8 seconds
Phase 3:	04/18 12:10:32	04/18 12:12:53	2 minutes, 21 seconds
Phase 4:	04/18 12:12:53	04/18 12:12:54	1 second
Phase 5:	Skipped
Phase 6:	04/18 12:12:54	04/18 12:14:25	1 minute, 31 seconds
Phase 7:	04/18 12:14:25	04/18 12:14:25

Total run time: 4 minutes, 1 second

I then logged into SSH and did a  xfs_repair -v /dev/md4 and got this error.

 

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.

What do I do next?

 

 

Link to comment

You're are having issues on multiple disks, first thing to do is to power down and remove all disks from the Marvell controller (first 4 white ports), these are know to be problematic on those boards, use the Intel PCH ports only.

 

After doing that power back on then grab and post new diags.

Link to comment
root@sobnology:~# xfs_repair -L /dev/md4
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...
Metadata corruption detected at xfs_agf block 0xaea851b1/0x200
flfirst 118 in agf 2 too large (max = 118)
sb_icount 905152, counted 905600
sb_ifree 155, counted 95
sb_fdblocks 254455625, counted 238421619
        - 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
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 (1:1544351) is ahead of log (1:2).
Format log to cycle 4.
done

 

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...