I probably should have been paying more attention.

Thought about doing a full backup of the unRaid system and clean install, but trusted the system to do the update through the plugins.

 

Not sure if there were any precautions I could have taken to prevent?

Including diagnostic logs. Not sure if LimeTech can or will see them or could benefit from them to prevent possible re-occurrence?

 

As for my troubleshooting steps so far...

 

Using an Intel 240GB SSD for cache drive.

I did have a previous backup of the unRaid filesystem.

Restored that, with no luck.

 

Then resorted to the diagnostic files and identified the drive and ran a disk check:

btrfs check --repair /dev/sdb1

 

With the following result:

enabling repair mode
parent transid verify failed on 248856576 wanted 660126 found 660124
parent transid verify failed on 248856576 wanted 660126 found 660124
Ignoring transid failure
parent transid verify failed on 248840192 wanted 660127 found 660126
parent transid verify failed on 248840192 wanted 660127 found 660126
Ignoring transid failure
parent transid verify failed on 248872960 wanted 660124 found 660126
parent transid verify failed on 248872960 wanted 660124 found 660126
Ignoring transid failure
parent transid verify failed on 248905728 wanted 660124 found 660126
Ignoring transid failure
repair mode will force to clear out log tree, Are you sure? [y/N]: y
parent transid verify failed on 248905728 wanted 660124 found 660126
Ignoring transid failure
extent-tree.c:2694: btrfs_reserve_extent: Assertion `ret` failed.
btrfs(btrfs_reserve_extent+0xc70)[0x44f214]
btrfs(btrfs_alloc_free_block+0x50)[0x44f2c7]
btrfs(__btrfs_cow_block+0x19d)[0x43eca8]
btrfs(btrfs_cow_block+0xec)[0x43f6ff]
btrfs[0x444e11]
btrfs(btrfs_commit_transaction+0xec)[0x446a60]
btrfs(cmd_check+0x623)[0x42b516]
btrfs(main+0x155)[0x40a75d]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x2b14ffb337d0]
btrfs(_start+0x29)[0x40a2e9]

 

Looking online into possible solutions with raw data backup and transid failure.

 

Any suggestions, I welcome them!

Thanks!

mu-diagnostics-20170212-0417.zip

the great news is...

I was able to do a recovery mnt with:

mount -t btrfs -o recovery,nospace_cache,clear_cache /dev/sdb1 /mnt/disk1/intel

 

All the data is there.

I'll be making a backup, formatting the drive, and then rebuild it.

 

Hopefully the drive unmountable error was an anomaly.

 

Any insights from the log files are appreciated!

Diagnostics are after a reboot, so no info on what happened, next time grab them before rebooting.

 

PS: btrfs check --repair should only be used as a last resort and only if mount read-only and/or btrfs restore fail, as these are non destructive and --repair can sometimes make the issue worse.

Gotcha on the diagnostics. Will be more vigilant next time.

 

Definitely on the btrfs check --repair

Really did not want to do that, but at that point, had no other choice.

I am much better prepared to handle such an event in the future.

 

Appreciate all your help!