May 7, 20188 yr so i come home from work to find my server freshly rebooted, parity REBUILD running and one of my drives in a state of ___ at first i think "odd, but but no biggie" but then i see that the unmounted drive is not emulated. is the parity rebuild including the data on the problem drive? or is it being written out of the parity drive? what should i do? attached diagnostics and screenshot. tower-diagnostics-20180507-2146.zip
May 8, 20188 yr Unmountable doesn't mean unreadable. Your disk needs to be readable to rebuild the parity disk but it doesn't need to be mountable. I'd wait for the rebuild to complete and then try to repair the file system on disk5. Your diagnostics won't give any clue as to why your server rebooted. Is it configured to start up in the event of power returning after an outage?
May 8, 20188 yr Author yes, it's set to start on power on. another thing that's out of the ordinary is that the speed of the parity operation is extremely slow - usually a check takes about 25 hours, but now it's reporting an estimated finish in 65 DAYS! is there some way to see what's holding it up? Quote Total size: 4001 GB Elapsed time: 12 hours, 10 minutes Current position: 128 GB (3,2 %) Estimated speed: 686,0 KB/sec Estimated finish: 65 days, 3 hours
May 8, 20188 yr Author 1 hour ago, EvilSpice said: yes, it's set to start on power on. another thing that's out of the ordinary is that the speed of the parity operation is extremely slow - usually a check takes about 25 hours, but now it's reporting an estimated finish in 65 DAYS! is there some way to see what's holding it up? Figured it out, it was one of the data drives connected through a card rather than directly to the motherboard. Parity check now running smoothly Quote Total size: 4001 GB Elapsed time: 20 minutes Current position: 144 GB (3,6 %) Estimated speed: 115,9 MB/sec Estimated finish: 9 hours, 15 minutes see you in 9 hours!
May 9, 20188 yr Author ok, parity operation completed and parity is valid. disk 5 is still unmountable, and btrfs check that i ran in array maintenance mode returns the following: Quote parent transid verify failed on 2000794763264 wanted 3690873 found 3688106 parent transid verify failed on 2000794763264 wanted 3690873 found 3688106 Ignoring transid failure checking extents checking free space cache checking fs roots checking csums checking root refs ERROR: transid errors in file system Checking filesystem on /dev/md5 UUID: 248a6b28-d662-4eb6-a911-ad5420d88c57 found 1400662179840 bytes used, error(s) found total csum bytes: 1365679824 total tree bytes: 1851359232 total fs tree bytes: 245202944 total extent tree bytes: 31244288 btree space waste bytes: 247700249 file data blocks allocated: 15423872286720 referenced 1397984464896 what's my next step? if i'm willing to accept some data loss, as most of the recent activity on that disk was downloading video content, what's the best course of action to regain access to the filesystem? attaching diagnostics (btw, i'm aware of the read errors on disk 2) tower-diagnostics-20180509-1148.zip
Archived
This topic is now archived and is closed to further replies.