January 14, 20179 yr Author Phase 1 - find and verify superblock... - block cache size set to 1529832 entries Phase 2 - using internal log - zero log... zero_log: head block 6724 tail block 6720 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... sb_fdblocks 21440397, counted 21448589 - 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 = 3 - agno = 2 - agno = 1 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:6722) is ahead of log (1:2). Format log to cycle 4. XFS_REPAIR Summary Sat Jan 14 09:08:34 2017 Phase Start End Duration Phase 1: 01/14 09:08:33 01/14 09:08:33 Phase 2: 01/14 09:08:33 01/14 09:08:34 1 second Phase 3: 01/14 09:08:34 01/14 09:08:34 Phase 4: 01/14 09:08:34 01/14 09:08:34 Phase 5: 01/14 09:08:34 01/14 09:08:34 Phase 6: 01/14 09:08:34 01/14 09:08:34 Phase 7: 01/14 09:08:34 01/14 09:08:34 Total run time: 1 second I assume that I remount and monitor for errors?
January 14, 20179 yr Author Yeah, it is still throwing an error immediately after mounting. I won't pretend to understand why but it also changes from sdi to sdh Jan 14 09:14:32 Tower emhttp: SanDisk_SDSSDA120G_162214402015 (sdi) 117220792 Jan 14 09:14:32 Tower kernel: mdcmd (1): import 0 sde 2930266532 0 WDC_WD30EZRX-00MMMB0_WD-WCAWZ2185533 Jan 14 09:14:32 Tower kernel: md: import disk0: (sde) WDC_WD30EZRX-00MMMB0_WD-WCAWZ2185533 size: 2930266532 Jan 14 09:14:32 Tower kernel: mdcmd (2): import 1 sdf 625130776 0 WDC_WD6400AAKS-07A7B0_WD-WCASY1192692 Jan 14 09:14:32 Tower kernel: md: import disk1: (sdf) WDC_WD6400AAKS-07A7B0_WD-WCASY1192692 size: 625130776 Jan 14 09:14:32 Tower kernel: mdcmd (3): import 2 sdb 1953514552 0 WDC_WD20EARS-00J2GB0_WD-WCAYY0190051 Jan 14 09:14:32 Tower kernel: md: import disk2: (sdb) WDC_WD20EARS-00J2GB0_WD-WCAYY0190051 size: 1953514552 Jan 14 09:14:32 Tower kernel: mdcmd (4): import 3 sdd 1953514552 0 WDC_WD20EARS-00MVWB0_WD-WMAZA3921612 Jan 14 09:14:32 Tower kernel: md: import disk3: (sdd) WDC_WD20EARS-00MVWB0_WD-WMAZA3921612 size: 1953514552 Jan 14 09:14:32 Tower kernel: mdcmd (5): import 4 sdg 1465138552 0 WDC_WD15EARS-00S8B1_WD-WCAVY2854733 Jan 14 09:14:32 Tower kernel: md: import disk4: (sdg) WDC_WD15EARS-00S8B1_WD-WCAVY2854733 size: 1465138552 Jan 14 09:14:32 Tower kernel: mdcmd (6): import 5 Jan 14 09:14:32 Tower kernel: mdcmd (7): import 6 Jan 14 09:14:32 Tower kernel: mdcmd (: import 7 Jan 14 09:14:32 Tower kernel: mdcmd (9): import 8 Jan 14 09:14:32 Tower kernel: mdcmd (10): import 9 Jan 14 09:14:32 Tower kernel: mdcmd (11): import 10 Jan 14 09:14:32 Tower kernel: mdcmd (12): import 11 Jan 14 09:14:32 Tower kernel: mdcmd (13): import 12 Jan 14 09:14:32 Tower kernel: mdcmd (14): import 13 Jan 14 09:14:32 Tower kernel: mdcmd (15): import 14 Jan 14 09:14:32 Tower kernel: mdcmd (16): import 15 Jan 14 09:14:32 Tower kernel: mdcmd (17): import 16 Jan 14 09:14:32 Tower kernel: mdcmd (18): import 17 Jan 14 09:14:32 Tower kernel: mdcmd (19): import 18 Jan 14 09:14:32 Tower kernel: mdcmd (20): import 19 Jan 14 09:14:32 Tower kernel: mdcmd (21): import 20 Jan 14 09:14:32 Tower kernel: mdcmd (22): import 21 Jan 14 09:14:32 Tower kernel: mdcmd (23): import 22 Jan 14 09:14:32 Tower kernel: mdcmd (24): import 23 Jan 14 09:14:32 Tower kernel: mdcmd (25): import 24 Jan 14 09:14:32 Tower kernel: mdcmd (26): import 25 Jan 14 09:14:32 Tower kernel: mdcmd (27): import 26 Jan 14 09:14:32 Tower kernel: mdcmd (28): import 27 Jan 14 09:14:32 Tower kernel: mdcmd (29): import 28 Jan 14 09:14:32 Tower kernel: mdcmd (30): import 29 Jan 14 09:14:32 Tower kernel: md: import_slot: 29 empty Jan 14 09:14:32 Tower emhttp: import 30 cache device: sdc Jan 14 09:14:32 Tower emhttp: import flash device: sda Jan 14 09:14:42 Tower kernel: XFS (sdh1): xfs_log_force: error -5 returned. Jan 14 09:15:12 Tower kernel: XFS (sdh1): xfs_log_force: error -5 returned.
January 14, 20179 yr Ok, so I got a brand new syba sy-pex40039 controller and added the script from the forum to make sure unraid plays nice with it. What is this script you mention? Your controller uses an ASMedia ASM1061, which is directly supported by unRAID. You don't need a script.
January 14, 20179 yr Author This script: http://lime-technology.com/forum/index.php?topic=19882.0 tower-diagnostics-20170114-0954.zip
January 14, 20179 yr Community Expert Log is after a reboot but everything looks normal. The script shouldn't cause issues but like John posted it's not needed for the asmedia, so you can remove it.
January 14, 20179 yr That thread was started well over four years ago. unRAID has come a long way since then.
January 14, 20179 yr Author Log is after a reboot but everything looks normal. The script shouldn't cause issues but like John posted it's not needed for the asmedia, so you can remove it. Yeah I just rebooted to see if it would help. It still fails. Here is another diag. tower-diagnostics-20170114-1008.zip
January 14, 20179 yr Community Expert Just in case remove the script, reboot and run xfs_repair again, if it still doesn't fix better to format the disk.
January 14, 20179 yr Author It looks like one of my VMs was automatically passed through the SATA controller card. I presume that starting that VM is possibly causing issues since the card is passed through but also being used by UNRAID? I just don't understand why this is a thing. Why would anyone want to automatically alter their VM config when a new device is added to the host machine?
January 14, 20179 yr Community Expert Look at your system devices, when there's an hardware change they can swap id's, e.g., you were passing through a NIC that was device 03:00.0 and after changing something it can become 02:00.0, and now 03:00.0 is a controller, so check your VM xml.
January 14, 20179 yr Author Look at your system devices, when there's an hardware change they can swap id's, e.g., you were passing through a NIC that was device 03:00.0 and after changing something it can become 02:00.0, and now 03:00.0 is a controller, so check your VM xml. Looks like this might be it. My VM no longer has access to the OTA Tuner I had installed. So it must have swapped the tuner card for the sata. That is a pretty significant issue for someone running multiple VMs.
April 5, 20179 yr Author On 1/14/2017 at 11:13 AM, johnnie.black said: Look at your system devices, when there's an hardware change they can swap id's, e.g., you were passing through a NIC that was device 03:00.0 and after changing something it can become 02:00.0, and now 03:00.0 is a controller, so check your VM xml. Well now I am no longer able to pass through the Tuner to the VM. I edited the XML with the correct device information but now I get a "This device cannot start. (Code 10)" in the VM under device manager. I don't believe how user unfriendly this whole process is.... tower-diagnostics-20170405-10060642.zip
April 5, 20179 yr Author 15 minutes ago, guigz said: Well now I am no longer able to pass through the Tuner to the VM. I edited the XML with the correct device information but now I get a "This device cannot start. (Code 10)" in the VM under device manager. I don't believe how user unfriendly this whole process is.... tower-diagnostics-20170405-10060642.zip Rebooting the server fixed the issue. But I still don't understand WTF is happening. It makes no sense (to me) that something that works fine suddenly stops working without any type of material change....
Archived
This topic is now archived and is closed to further replies.