Netbug

I have no idea. That was completely unexpected because disk 1 should be pretty much empty (I moved all data off of it). Changing the docker location seems to have remedied it. Thank you very much. I'd really love to know why it's doing the parity rebuild. It takes so long and it's rebuilding a disk that shouldn't have anything on it to start with. With my luck, it will rebuild it as reiserfs

Sorry about the lack of clarity. Just getting tired. Here's a screenshot of "main" at present.

Thanks for the quick reply. I think I'm going to have to wait for the parity check to finish and then cross my fingers. The procedure I linked is what I was following, but honestly, I may have fallen off the path as it got a little complicated. Form memory, what I did was use unBALANCE to move the data off of the disk I wanted to convert (disk 1 in this case), stop the array, unassign the drive, format the drive, start the array and begin the rebuild. I'm sure I've messed something up. Just starting to get frustrated with all the complications I'm causing for myself in trying to get the system back to stability.

I was attempting to convert a disk from reiserfs to xfs using the instructions here. However, now it's running a parity-sync/rebuild for some reason and I've lost all my docker containers. I'm not that smart, I know, but unRAID has given me more trouble in the past month than I thought possible. tower-diagnostics-20170807-1514.zip All the data APPEARS to still be there in the "appdata" directory.

Oh, one further question, is there a set of instructions for how to replace the SATA controller? I assume the disks will need to be re-assigned in their proper positions after the controller is replaced.

That's got it. Sorry, I was 100% sure i saw it as unmountable when I left the house this morning. It's reconstructing now. I really appreciate all the help. So as of right now, I've got a new motherboard, RAM, and processor on the way, I will be getting two additional hot-swap bays and a controller. Now I need to add to that a second SATA controller. An expensive week. Thank you again.

Sorry, but how? I don't get the option at the bottom that I would normally get to have the drive rebuilt to. It just shows as "Unmountable."

Ok. I'll add it to the list of hardware I need to replace ($500 on hard drives this week alone ). For now, though, how do I go about safely getting the disk to be read by the array again?

I am using hot-swap bays. The cages you recommend are actually the cages I'm using. They've been very good so far, but I suppose the wires could be loose somehow. I'm not quite sure what you mean by the SASLP; is that the SATA controller? At this point, it is detecting the drive again, and as you said, there don't appear to be any errors with the drive. How can I get it back in the array?

After upgrading my parity drive to 4TB and one of my data drives from 1TB to 4TB, I'm now getting a red X on another drive. Screenshot I ran a SMART test on the drive (results attached). So, 2 questions... Is this ANOTHER drive I need to replace (4 drives swapped in one weekend is getting expensive)? How can I get the drive back into the array and have the data rebuilt? From my digging (and apparently I encountered a similar problem before), I need to create a new config under "Tools." Is this correct? How do I go about doing that while preserving/rebuilding my data? Thanks. tower-smart-20170802-2338.zip tower-diagnostics-20170803-0710.zip

reiserfsck 3.6.24 ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ************************************************************* Will rebuild the filesystem (/dev/md4) tree Will put log info to 'stdout' Replaying journal: Replaying journal: Done. Reiserfs journal '/dev/md4' in blocks [18..8211]: 0 transactions replayed ########### reiserfsck --rebuild-tree started at Sun Jul 30 11:58:34 2017 ########### Pass 0: Loading on-disk bitmap .. ok, 710588517 blocks marked used Skipping 30567 blocks (super block, journal, bitmaps) 710652013 blocks will be read 0%....20%....40%....60%....80%....100% "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 710652013 Leaves among those 707296 - leaves all contents of which could not be saved and deleted 3 Objectids found 52820 Pass 1 (will try to insert 707293 leaves): Looking for allocable blocks .. finished 0%....20%....40%....60%....80%....100% Flushing..finished 707293 leaves read 707116 inserted - pointers in indirect items pointing to metadata 17 (zeroed) 177 not inserted non-unique pointers in indirect items (zeroed) 8738 Pass 2: 0%....20%....40%....60%....80%....100% Flushing..finished Leaves inserted item by item 177 Pass 3 (semantic): Flushing..finished Files found: 48850 Directories found: 3970 Broken (of files/symlinks/others): 3 Pass 3a (looking for lost dir/files): Looking for lost directories: Flushing..finished Pass 4 - finished Deleted unreachable items 2116 Flushing..finished Syncing..finished ########### reiserfsck finished at Sun Jul 30 17:36:34 2017 ########### ####### Pass 0 ####### init_source_bitmap: Bitmap 148 (of 32768 bits) is wrong - mark all blocks [4849664 - 4882432] as used init_source_bitmap: Bitmap 187 (of 32768 bits) is wrong - mark all blocks [6127616 - 6160384] as used init_source_bitmap: Bitmap 219 (of 32768 bits) is wrong - mark all blocks [7176192 - 7208960] as used init_source_bitmap: Bitmap 269 (of 32768 bits) is wrong - mark all blocks [8814592 - 8847360] as used init_source_bitmap: Bitmap 299 (of 32768 bits) is wrong - mark all blocks [9797632 - 9830400] as used block 197502071: The number of items (51605) is incorrect, should be (1) - corrected block 197502071: The free space (35554) is incorrect, should be (3824) - corrected pass0: vpf-10110: block 197502071, item (0): Unknown item type found [947344967 3556836352 0xf8ee16 ??? (12)] - deleted block 298786712: The number of items (42945) is incorrect, should be (1) - corrected block 298786712: The free space (38560) is incorrect, should be (3792) - corrected pass0: vpf-10110: block 298786712, item (0): Unknown item type found [1933574144 33590472 0xf6608c00 ??? (11)] - deleted block 464804857: The number of items (43888) is incorrect, should be (1) - corrected block 464804857: The free space (55352) is incorrect, should be (3792) - corrected pass0: vpf-10110: block 464804857, item (0): Unknown item type found [672006200 3224626137 0xd665f600 ??? (4)] - deleted 52818 directory entries were hashed with "r5" hash. ####### Pass 1 ####### ####### Pass 2 ####### ####### Pass 3 ######### vpf-10680: The file [48996 50180] has the wrong block count in the StatData (2882088) - corrected to (2857800) vpf-10680: The file [45136 47361] has the wrong block count in the StatData (2181896) - corrected to (2181880) vpf-10680: The file [49040 50737] has the wrong block count in the StatData (3216016) - corrected to (3216000) vpf-10680: The file [49092 50387] has the wrong block count in the StatData (2827632) - corrected to (2803344) vpf-10680: The file [45995 46331] has the wrong block count in the StatData (2597248) - corrected to (2597232) vpf-10680: The file [42522 45990] has the wrong block count in the StatData (4573952) - corrected to (2036032) vpf-10680: The file [48573 48574] has the wrong block count in the StatData (9153128) - corrected to (32048) vpf-10680: The file [2926 2927] has the wrong block count in the StatData (7166128) - corrected to (1669584) vpf-10680: The file [43173 43175] has the wrong block count in the StatData (1456664) - corrected to (1416104) ####### Pass 3a (lost+found pass) #########

Okie dokie. I'll be patient. It's still at 0% after 40 minutes though. reiserfsck 3.6.24 ************************************************************* ** Do not run the program with --rebuild-tree unless ** ** something is broken and MAKE A BACKUP before using it. ** ** If you have bad sectors on a drive it is usually a bad ** ** idea to continue using it. Then you probably should get ** ** a working hard drive, copy the file system from the bad ** ** drive to the good one -- dd_rescue is a good tool for ** ** that -- and only then run this program. ** ************************************************************* Will rebuild the filesystem (/dev/md4) tree Will put log info to 'stdout' Replaying journal: Replaying journal: Done. Reiserfs journal '/dev/md4' in blocks [18..8211]: 0 transactions replayed ########### reiserfsck --rebuild-tree started at Sun Jul 30 11:58:34 2017 ########### Pass 0: Loading on-disk bitmap .. ok, 710588517 blocks marked used Skipping 30567 blocks (super block, journal, bitmaps) 710652013 blocks will be read 0%....

Okie dokie. It's running. Looks like it will take a while.

Erm... I think I've messed something up along the way here... reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/md4 Will put log info to 'stdout' ########### reiserfsck --check started at Sun Jul 30 11:47:51 2017 ########### Replaying journal: Replaying journal: Done. Reiserfs journal '/dev/md4' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. Bad root block 0. (--rebuild-tree did not complete)

Okie. Running that again now with the --check flag first.

I replaced the bad drive (Disk 4), and ran the parity check. It said it was repairing (left it to do so overnight). But I'm still showing the disk as "unmountable" What did I do wrong? How do I rebuild that disk?

Ok. I think I understand now. Mostly. I went and bought a 3TB drive and just replaced disk 4. It is now rebuilding that drive. I assume, since it's doing a rebuild, it's going to put it back to reiserfs, which is annoying, but unavoidable at this point. I have 2 4TB drives on the way that should arrive on Wednesday. When they arrive, I'll replace the smallest drive in the array with one of them, and replace the parity drive (using the instructions you linked) with the other one. That SHOULD give me enough room to use unBALANCE and free up enough space to convert the file systems of the remaining drives to xfs. Fingers crossed. That's good information to have. I believe that I need to get a new SATA controller anyways as I'm almost out of ports on this one (if I recall correctly). I'll look into a different make/model when I do. Thank you.

Ah! ok. That makes sense. I'll need somewhere to mount the parity drive then while it is copying. Can I do it as follows then? Remove one of the other drives (say disk 4) Place the new drive in that spot Do the parity duplication Remove the old parity drive Put the new parity drive where the old one was Then put the old parity drive where disk 4 was and rebuild after a pre-clear?

I'm so sorry. Forgive my confusion here. How can I do a parity swap, when disk 4 is missing? Like, how can it rebuild when both disk 4 (unmountable) and the parity drive (removed to swap) are missing? Can it still use the data from that drive even when it's unmountable?

Sorry, I'm still a little confused by the next step. If drive 4 is unmountable, do I not have to replace that BEFORE I can replace the parity? I will have to purchase a third drive (3TB) if that is the case. How can it rebuild the parity drive if one from the array is unmountable?

Ordered 2 Seagate BarraCuda 4TB 3.5-Inch SATA III 6 Gb/s Internal Hard Drive (ST4000DM005) . They should arrive tomorrow with Prime. Do I replace the parity drive first? I'm not sure what to do here since their larger than my parity drive at present.

Well shit. Now disk 4 is "unmountable" I'm gonna go out right now and buy a replacement drive. Do I need to pre-clear for it to repair when I put it in?

This is what it gave me for disk 2: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - 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 = 2 - agno = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. Does that mean it's ok? It's really hard to interpret these logs

Should I run the --rebuild-tree command as it suggests?

Here are the results: reiserfsck 3.6.24 Will read-only check consistency of the filesystem on /dev/md4 Will put log info to 'stdout' ########### reiserfsck --check started at Sat Jul 29 10:26:17 2017 ########### Replaying journal: Trans replayed: mountid 142, transid 184259, desc 6013, len 6, commit 6020, next trans offset 6003 Replaying journal: | | 0.1% 1 trans Trans replayed: mountid 142, transid 184260, desc 6021, len 1, commit 6023, next trans offset 6006 Replaying journal: | / 0.2% 2 trans Trans replayed: mountid 142, transid 184261, desc 6024, len 1, commit 6026, next trans offset 6009 Trans replayed: mountid 142, transid 184262, desc 6027, len 1, commit 6029, next trans offset 6012 Trans replayed: mountid 142, transid 184263, desc 6030, len 1, commit 6032, next trans offset 6015 Trans replayed: mountid 142, transid 184264, desc 6033, len 1, commit 6035, next trans offset 6018 Trans replayed: mountid 142, transid 184265, desc 6036, len 13, commit 6050, next trans offset 6033 Replaying journal: | - 0.6% 7 trans Replaying journal: Done. Reiserfs journal '/dev/md4' in blocks [18..8211]: 7 transactions replayed Checking internal tree.. finished Comparing bitmaps..Bad nodes were found, Semantic pass skipped 6 found corruptions can be fixed only when running with --rebuild-tree ########### reiserfsck finished at Sat Jul 29 10:38:16 2017 ########### block 5504537: The level of the node (47074) is not correct, (1) expected the problem in the internal node occured (5504537), whole subtree is skipped block 1946122: The level of the node (2) is not correct, (1) expected the problem in the internal node occured (1946122), whole subtree is skipped block 4800674: The level of the node (47801) is not correct, (1) expected the problem in the internal node occured (4800674), whole subtree is skipped block 558244350: The level of the node (40478) is not correct, (1) expected the problem in the internal node occured (558244350), whole subtree is skipped block 5174938: The level of the node (59681) is not correct, (1) expected the problem in the internal node occured (5174938), whole subtree is skipped block 5174937: The level of the node (25567) is not correct, (1) expected the problem in the internal node occured (5174937), whole subtree is skipped vpf-10640: The on-disk and the correct bitmaps differs. So disk 4 definitely needs replacing then? Should I run the same test on disk 2?