March 12, 20179 yr So everything was great in my Unraid world until a few days ago i upgraded from version 6.1X to 6.32. Everything seemed OK, but since then i noticed my backup software on my mobile phone complaining that it couldnt write to the unraid server sometimes. I have just had a chance to have a look and sure enough my pc on the same LAN network cant write to some folders. So i restarted unraid which made no difference. Then I put unraid in maintenance mode and ran the file system checker on my drives which are all XFS. All looked ok to me on all but 1 drive, and it showed a diffrent result to the rest. So i tried running the command with just the -v switch from the GUI and this is the result. Not available Phase 1 - find and verify superblock... - block cache size set to 251280 entries Phase 2 - using internal log - zero log... zero_log: head block 12582 tail block 12582 - scan filesystem freespace and inode maps... - 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 - 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 = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:71270) is ahead of log (1:12582). Format log to cycle 4. So that last bit looks wrong to my untrained eye. What should i do now?? Cheers Des
March 12, 20179 yr Author Here are my diagnostic files.S-----------e.cfg disk.cfg docker.cfg domain.cfg go ident.cfg network.cfg share.cfg smart-one.cfg super.dat docker.txt syslog.txt no qemu log files a-----a.cfg m--------e.cfg S-----------e.cfg HGST_HDN724040ALE640_PK1334PBGTHZNX-20170312-0150.txt SanDisk_Cruzer_Fit_4C532000070728119385-0-0-20170312-0150.txt SanDisk_SDSSDA240G_151987404336-20170312-0150.txt ST8000AS0002-1NA17Z_Z840AS05-20170312-0150.txt ST8000AS0002-1NA17Z_Z840FDHC-20170312-0150.txt WDC_WD60EFRX-68MYMN0_WD-WX31D3408887-20170312-0150.txt cmdline.txt df.txt ethtool.txt folders.txt ifconfig.txt iommu_groups.txt lsmod.txt lsof.txt lspci.txt lsscsi.txt lsusb.txt memory.txt ps.txt vars.txt unRAID-6.3.2.txt
March 12, 20179 yr Author Ok, reran the file system check with -nv and the fault has gone, so suspect the checker "fixed" the problem the first time? Anyhow, i restarted the array in normal mode and now i can copy to the server again on the directory i couldn't before. Anyone know what would of caused this? Should i be concerned?
March 12, 20179 yr Author Should I be OK to do a parity check after this event? Thanks in advance des.
March 12, 20179 yr 20 hours ago, Dieseldes said: Here are my diagnostic files.S-----------e.cfg disk.cfg ... unRAID-6.3.2.txt Please don't do this again. Just post the zip file. We don't want each separate file without any folder context, we want the complete zip as a single file. 19 hours ago, Dieseldes said: Anyone know what would of caused this? Should i be concerned? Filesystem corruption is often caused by an unclean shutdown. Shutdown or reboot only from the webUI if possible. The array must be stopped so the buffers are flushed (writing completed). If you don't have an UPS you should consider getting one. 6 minutes ago, Dieseldes said: Should I be OK to do a parity check after this event? Thanks in advance des. YES
March 12, 20179 yr Author 5 minutes ago, trurl said: Please don't do this again. Just post the zip file. We don't want each separate file without any folder context, we want the complete zip as a single file. Filesystem corruption is often caused by an unclean shutdown. Shutdown or reboot only from the webUI if possible. The array must be stopped so the buffers are flushed (writing completed). If you don't have an UPS you should consider getting one. YES OK thanks for the feedback. I have no idea how the zip file got split out into the individual files. Sorry about that. My microserver runs on a 12v psu from a 200 amp battery which powers it for a few days at normal load. The battery is charged when the mains is on (99.98%) of the time so the server never sees a mains failure. I also always shut the server down from the guinea and before the upgrade to 6.3x it had been up for 180 ish days. Based on the a over any other thoughts as to why the corruption would of happened? I will run a parity check now just to be sure how things are.
March 13, 20179 yr Author Parity check completed finding zero errors so looks like I'm all good. Thanks des.
Archived
This topic is now archived and is closed to further replies.