March 27, 20197 yr Hi, not sure if this a correct way to get help here, but "unraid support" lead me here so... will try. I was doing: Deleting directory (rm -r some_dir). Using ssh i've logged in to unraid instance. Then went to directory ("cd /mnt/disk5/todo/"). And there do a delete operation. An now I have this error. Now: Did a few reboots, but always unmarked "write correction to parity" I don't see shares from that disk (disk5/sdc/WDC WD30EFRX-68EUZN0) in "shares" tab. Unable (or i don't know how) I would like to: I would like to be able to access my data. Best case: i would like to just do something to have my shares back Worst case: I have spare disk (larger than broken one). And i think I would be able to just copy data to that one, format oryginal one and move them back. But still have no idea how to achive that. Basically have no idea what to do to just... see my shares Any advices are welcome. Thank You in advance. sfejer-diagnostics-20190327-2252.zip Edited March 28, 20197 yr by Pawel
March 27, 20197 yr Community Expert Not entirely clear what you have done but disk5 is unmountable. Post a screenshot of Main - Array Devices
March 28, 20197 yr Author @trurl I cannot do that. "Check is only available when array is Started in Maintenance mode" After going to maintenance mode all my drives are in unassigned section. So don't have option to do fs check.
March 28, 20197 yr Author @trurl sfejer-diagnostics-20190328-0755.zip Edited March 28, 20197 yr by Pawel
March 28, 20197 yr Community Expert 7 hours ago, Pawel said: After going to maintenance mode all my drives are in unassigned section. So don't have option to do fs check. This doesn't make any sense, can you post diags and/or screenshot after this?
March 28, 20197 yr Author @johnnie.black Cant download diagnostics... after hitting download nothing happens. EDIT: Guessing that this can be an issue: Filesystem Size Used Avail Use% Mounted on rootfs 4.1G 4.1G 0 100% / tmpfs 34M 263k 34M 1% /run devtmpfs 4.1G 0 4.1G 0% /dev tmpfs 4.2G 0 4.2G 0% /dev/shm cgroup_root 8.4M 0 8.4M 0% /sys/fs/cgroup tmpfs 135M 2.0M 133M 2% /var/log /dev/sdb1 16G 582M 15G 4% /boot /dev/loop0 8.6M 8.6M 0 100% /lib/modules /dev/loop1 5.2M 5.2M 0 100% /lib/firmware Will try to free some space Edited March 28, 20197 yr by Pawel
March 28, 20197 yr Author @johnnie.black SwapFile plugin was doing some mess - it was trying to create swap on /mnt/cache/tmp_cache/. And this folder wasn't mounted so created file took all available disk space. Now i was able to do check: 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... invalid start block 4177215269 in record 158 of bno btree block 1/5 agi unlinked bucket 59 is 264772539 in ag 1 (inode=2412256187) sb_icount 238784, counted 196928 sb_ifree 864, counted 1234 sb_fdblocks 181033632, counted 184201565 - 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 = 0 - agno = 1 - agno = 3 - agno = 2 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 2412256187, would move to lost+found Phase 7 - verify link counts... would have reset inode 2412256187 nlinks from 0 to 1 No modify flag set, skipping filesystem flush and exiting.
March 28, 20197 yr Author @johnnie.black 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. And i have no idea if it still running or not Guessing that now i should run it with '-L' flag? Edited March 28, 20197 yr by Pawel
March 28, 20197 yr Community Expert 4 minutes ago, Pawel said: Guessing that now i should run it with '-L' flag? Yes.
March 28, 20197 yr Author @johnnie.black 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... invalid start block 4177215269 in record 158 of bno btree block 1/5 agi unlinked bucket 59 is 264772539 in ag 1 (inode=2412256187) sb_icount 238784, counted 196928 sb_ifree 864, counted 1234 sb_fdblocks 181033632, counted 184201565 - 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 = 2 - agno = 1 - agno = 3 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 2412256187, moving to lost+found Phase 7 - verify and correct link counts... Maximum metadata LSN (11:1332552) is ahead of log (1:2). Format log to cycle 14. done Reboot to normal mode? EDIT: Nice!. Got my shares back. Thank You @johnnie.black, @trurl Edited March 28, 20197 yr by Pawel
March 28, 20197 yr Community Expert 2 hours ago, Pawel said: SwapFile plugin was doing some mess - it was trying to create swap on /mnt/cache/tmp_cache/. And this folder wasn't mounted so created file took all available disk space. Actually, it was taking all available rootfs, which is in RAM like the rest of the OS, and needed by the OS. That will definitely break some things. Glad you got it sorted.
Archived
This topic is now archived and is closed to further replies.