I lost connection to one of my shares and that it was indeed not listed in unRAID.

 

 

Quote

Mar 28 20:00:01 Tower root: mover started
Mar 28 20:00:01 Tower root: mover finished
Mar 28 20:13:09 Tower kernel: XFS (md1): Internal error XFS_WANT_CORRUPTED_GOTO at line 3504 of file fs/xfs/libxfs/xfs_btree.c.  Caller xfs_free_ag_extent+0x3b4/0x569
Mar 28 20:13:09 Tower kernel: CPU: 6 PID: 9223 Comm: shfs Not tainted 4.9.10-unRAID #1
Mar 28 20:13:09 Tower kernel: Hardware name: Supermicro Super Server/X11SSH-LN4F, BIOS 1.0a 12/29/2015
Mar 28 20:13:09 Tower kernel: ffffc90006fd7ae8 ffffffff813a353e ffff880003b10bc8 ffffc90006fd7bec
Mar 28 20:13:09 Tower kernel: ffffc90006fd7b00 ffffffff8129b917 ffffffff81263537 ffffc90006fd7ba0
Mar 28 20:13:09 Tower kernel: ffffffff8127a5b0 0000000002408240 0000000000000000 00000000ffffffff
Mar 28 20:13:09 Tower kernel: Call Trace:
Mar 28 20:13:09 Tower kernel: [<ffffffff813a353e>] dump_stack+0x61/0x7e
Mar 28 20:13:09 Tower kernel: [<ffffffff8129b917>] xfs_error_report+0x32/0x35
Mar 28 20:13:09 Tower kernel: [<ffffffff81263537>] ? xfs_free_ag_extent+0x3b4/0x569
Mar 28 20:13:09 Tower kernel: [<ffffffff8127a5b0>] xfs_btree_insert+0xe2/0x17d
Mar 28 20:13:09 Tower kernel: [<ffffffff812b2536>] ? kmem_zone_alloc+0x74/0xd0
Mar 28 20:13:09 Tower kernel: [<ffffffff81263537>] xfs_free_ag_extent+0x3b4/0x569
Mar 28 20:13:09 Tower kernel: [<ffffffff81263537>] ? xfs_free_ag_extent+0x3b4/0x569
Mar 28 20:13:09 Tower kernel: [<ffffffff81265244>] xfs_free_extent+0xd4/0x115
Mar 28 20:13:09 Tower kernel: [<ffffffff812c028a>] xfs_trans_free_extent+0x28/0x65
Mar 28 20:13:09 Tower kernel: [<ffffffff812c02e7>] xfs_extent_free_finish_item+0x20/0x32
Mar 28 20:13:09 Tower kernel: [<ffffffff8127e1a9>] xfs_defer_finish+0xe7/0x1eb
Mar 28 20:13:09 Tower kernel: [<ffffffff812a840a>] xfs_itruncate_extents+0xea/0x191
Mar 28 20:13:09 Tower kernel: [<ffffffff812a852a>] xfs_inactive_truncate+0x79/0xbf
Mar 28 20:13:09 Tower kernel: [<ffffffff812a8997>] xfs_inactive+0xa1/0xc0
Mar 28 20:13:09 Tower kernel: [<ffffffff812ae3a7>] xfs_fs_destroy_inode+0xc6/0x17a
Mar 28 20:13:09 Tower kernel: [<ffffffff81136c01>] destroy_inode+0x38/0x50
Mar 28 20:13:09 Tower kernel: [<ffffffff81136d7f>] evict+0x166/0x16d
Mar 28 20:13:09 Tower kernel: [<ffffffff811373c2>] iput+0x163/0x170
Mar 28 20:13:09 Tower kernel: [<ffffffff8112d1ba>] do_unlinkat+0x125/0x201
Mar 28 20:13:09 Tower kernel: [<ffffffff8112e60b>] SyS_unlink+0x11/0x13
Mar 28 20:13:09 Tower kernel: [<ffffffff8167d2b7>] entry_SYSCALL_64_fastpath+0x1a/0xa9
Mar 28 20:13:09 Tower kernel: XFS (md1): xfs_do_force_shutdown(0x8) called from line 236 of file fs/xfs/libxfs/xfs_defer.c.  Return address = 0xffffffff8127df9d
Mar 28 20:13:09 Tower kernel: XFS (md1): Corruption of in-memory data detected.  Shutting down filesystem
Mar 28 20:13:09 Tower kernel: XFS (md1): Please umount the filesystem and rectify the problem(s)
Mar 28 20:13:10 Tower shfs/user: err: shfs_read: read: (5) Input/output error
Mar 28 20:13:10 Tower shfs/user: err: shfs_read: read: (5) Input/output error
Mar 28 20:13:10 Tower shfs/user: err: shfs_write: write: (5) Input/output error
Mar 28 20:13:10 Tower shfs/user: err: shfs_write: write: (5) Input/output error
Mar 28 20:13:10 Tower shfs/user: err: shfs_write: write: (5) Input/output error
Mar 28 20:13:10 Tower shfs/user: err: shfs_write: write: (5) Input/output error
Mar 28 21:13:11 Tower kernel: mdcmd (138): spindown 0
Mar 28 21:13:11 Tower kernel: mdcmd (139): spindown 1
Mar 29 00:00:01 Tower Plugin Auto Update: Checking for available plugin updates
Mar 29 00:00:03 Tower Plugin Auto Update: Community Applications Plugin Auto Update finished
Mar 29 04:00:13 Tower root: /mnt/cache: 271.8 GiB (291782680576 bytes) trimmed
Mar 29 06:31:53 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog
Mar 29 06:32:38 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog
Mar 29 06:36:05 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog

 

Found this gem in syslog, any idea how to go forward would be much appreciated.

 

/Fred

You need to check filesystem on disk1 (md1)

https://lime-technology.com/wiki/index.php/Check_Disk_Filesystems#Drives_formatted_with_XFS

Thank you

 

That did not however go very well I'm afraid.

 

I tried xfs_repair -v /dev/md1 and it reported that I needed to mount it (which I can't) to replay a log and that I could try xfs_repair L.

I tried xfs_repair -vL /dev/md1 and it got stuck after the most initial report. I tried adding -P to reset the log, it did and it got stuck.

I tried the standard repair again and now it actually started going through some of the faces but eventually it got stuck again.

 

Not mountable, still. I formatted it with the naive assumption that it would restore the data from parity but that does not seem to have happened.

 

I assume I made a bobo out of something in my haste.

 

Can I force the parity to restore the data? It is not a disaster, as it's only media and the important stuff I have on multiple storage. It is however a hassle

Formatting a disk will always update parity, so even if you rebuild it will rebuild an empty disk.

Formatting a disk will always update parity, so even if you rebuild it will rebuild an empty disk.

I was kind afraid that would be the answer, not sure I agree with the way it works though. As we manually (scheduled is still under our control) perform parity checks I assumed the parity would be more, well, sacred I guess.

But I f.ed up and thank you for the information.


Skickat från min iPhone med Tapatalk

2 minutes ago, nodeadlykittens said:

not sure I agree with the way it works though

 

It's the only way it can work with real time parity.

 
It's the only way it can work with real time parity.

Yeah, sorry, I am an idiot. I did not keep my carrots separate. For some reason I had forgotten that the parity is real time, the only manual thing is the control of the parity. Thank you for setting me straight. Now I actually do know more.


Skickat från min iPhone med Tapatalk