September 26, 20178 yr In Fix Common Problems I was made aware of errors from a SMART test. I replicated with the extended self-test (the short test found no errors). The errors are #187, Reported Incorrect (10) and #198 Offline uncorrectable (16). Will running reiserfsck possibly fix these or are they mechanical problems (which, presumably, would indicate I should replace the drive?)? I have attached the SMART report. Thank you. tower-smart-20170926-1259.zip
September 26, 20178 yr Community Expert Quote Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 60% 27932 2935384520 Replace disk.
September 26, 20178 yr Author Damn it, JB, I knew you were going to say that! The problem is that, if I'm going to replace it I had might as well just get a 6TB drive and use it for parity (for future-proofing). The current parity drive is 4TB and the affected drive in question is 3TB. What should be my course of action (i.e. sequence of steps)? Thanks again.
October 5, 20178 yr Author HELP. I went through the parity swap procedure, introducing a 6tb drive as parity (to replace a 4tb parity drive) and to remove a failed 3tb drive. This seemed to work fine, but after the procedure finished, ANOTHER drive failed (it was X'd out and i could not get it to be recognized). So, I replaced THAT 2tb drive with a new 4tb drive. The parity process completed and, after all of this, the new 4tb drive ( which replaced the 2tb drive) is apparently blank. So, the old disk contents did not get copied over, apparently. Fortunately, I can mount the old 2tb drive as an Unassigned Device (via the Main unRAID page I can drill down through the folders and apparently see files). So.... how do i copy over or merge the files on the old drive that never got built into parity? Screenshot attached (Disk 4 is the new 4tb drive without any data on it). THANK YOU. tower-diagnostics-20171005-1357.zip
October 5, 20178 yr Author Here, btw, is what the screen looked like when the Parity-Sync/Data-Rebuild process was 99.9% done: note that Disk 4 is crossed out and there are 486M Errors. This would explain why the disk 4 data never made it over to parity, I imagine. I suppose there is no way to reinsert the old drive back into the array, do a parity sync, remove it (i suppose it was crossed off for a reason, though there are no SMART errors) and re-sync? Tower-Main.pdf
October 5, 20178 yr Community Expert Most likely a misstep somewhere, like formatting an unmountable disk, but you can copy the data from the old disk to the new disk in the array. 24 minutes ago, smellthebean said: but after the procedure finished, ANOTHER drive failed Looks like the errors on disk4 happened during disk2 rebuild, not after, did you by any chance saved the diagnostics from the parity swap/rebuild and before rebooting?
October 5, 20178 yr Author I am sorry, I did not copy the diagnostics prior to the ones i attached above. What is the best way to copy the data from the old disk to the new? If I go to add the old disk to the array I get the WARNING all data will be erased message.
October 5, 20178 yr Community Expert You can't add it to the array like that, on the screenshot before you had the old disk mounted using the UD plugin, that's the best way to copy the data, mount it again and copy the data, e.g. using midnight commander, from /mnt/disks/old_disk_mount_point to /mnt/disk4 Also note that if the errors on disk4 happened during disk2 rebuild there will be corrupt data on the rebuilt disk.
October 5, 20178 yr Author Is midnight commander a Community App? I am not finding it. thanks johnnie.black
October 5, 20178 yr Author got it. I ended up using a single command cp command w log output. Should I run parity when this finishes? Perhaps I should check the log first?!
October 5, 20178 yr Community Expert 6 minutes ago, smellthebean said: Should I run parity when this finishes? Parity is updated real-time.
October 9, 20178 yr Author I am just getting back to this now, sorry. It took about 24 hours, but it appears that all contents were copied from the old disk 4 to the new one. however, when i open a sharepoint, I see no files. Is there some utility I run to 're-align' or re-map the files to their new locations? Thanks.
October 9, 20178 yr Author Thanks johnnie.black. File attached. Also, some observations: when i mount the tvshare via disk4 on my mac (when I mount it directly, i.e., smb://10.x.x.x/tvshare, I see no contents at all) I see folders with red warning icons (screenshot attached). l. This means, almost always, that I don't have permissions to view their contents (and that is, in fact, the dialog that is generated when I try to open them). On the command line, however, I am able to access a sharepoint and see its contents. So it would be appear that, perhaps, the issue is only one of repairing permissions? That's the optimistic view, at least. tower-diagnostics-20171009-0954.zip
October 9, 20178 yr Community Expert There's filesystem corruption on disk2, likely from this: On 05/10/2017 at 8:47 PM, johnnie.black said: Also note that if the errors on disk4 happened during disk2 rebuild there will be corrupt data on the rebuilt disk. Run reiserfsck on it, but for sure there will be some or a lot of corrupt files: https://wiki.lime-technology.com/Check_Disk_Filesystems#Drives_formatted_with_ReiserFS_using_unRAID_v5_or_later
October 9, 20178 yr Author results from running on disk2. should i run the --rebuild-tree? Reiserfs journal '/dev/md2' in blocks [18..8211]: 6 transactions replayed Checking internal tree.. / 1 (of 72)/ 1 (of 160)/ 3 (of 100)block 37224458: The level of the node (15540) is not correct, (1) expected the problem in the internal node occured (37224458), whole subtree is skipped / 2 (of 160)/ 4 (of 145)block 453330764: The level of the node (7086) is not correct, (1) expected the problem in the internal node occured (453330764), whole subtree is skipped / 3 (of 160)/ 1 (of 143)block 453327915: The level of the node (3988) is not correct, (1) expected the problem in the internal node occured (453327915), whole subtree is skipped / 4 (of 160)block 138662205: The level of the node (4287) is not correct, (2) expected the problem in the internal node occured (138662205), whole subtree is skipped / 2 (of 72)/ 1 (of 157)block 365779662: The level of the node (65280) is not correct, (2) expected the problem in the internal node occured (365779662), whole subtree is skipped / 3 (of 72)block 290553865: The level of the node (57693) is not correct, (3) expected the problem in the internal node occured (290553865), whole subtree is skipped finished Comparing bitmaps..vpf-10640: The on-disk and the correct bitmaps differs. Bad nodes were found, Semantic pass skipped 6 found corruptions can be fixed only when running with --rebuild-tree ###########
October 9, 20178 yr Community Expert 4 minutes ago, smellthebean said: should i run the --rebuild-tree? Yes
October 9, 20178 yr Community Expert After --rebuild-tree finishes and If you still have old disk2 you should copy all data you can from it, and replace those files on the rebuilt disk, every file you can copy from the old disk without a read error should be OK.
October 9, 20178 yr Author i haven't yet attempted to run the rebuild. i attempted to restart in regular mode before that, just to see exactly what IS on the old disk (which is still available via Unassigned Devices). I am at this point i am having difficulties rebooting. I'll keep you posted.
October 9, 20178 yr Author well, i can't even boot now. I've given it about an hour. I've unattached the Unassigned drive, but no luck.
October 9, 20178 yr Author I was finally able to figure it out: reloading the web page would never work; trying it on another browser did. This is not the first time I've had this problem: to be honest, each browser (Chrome, Safari, Firefox) has its weirdnesses wrt various menus, clickables, etc. Chrome is mostly unusable. So, running now. "Skipping 38019 blocks... 699190841 blocks will be read". Apparently bitmap is wrong for those 38k blocks?
Archived
This topic is now archived and is closed to further replies.