assur191

Thanks again for the responses. I will go ahead and rebuild disk 17 and repair the filesystem on disk 3. However, I just want to confirm that I should first rebuild 17, then repair 3. Will that order result in the least amount of lost data?

Thanks all for your feedback. I rebooted the server and checked connections, and now I'm showing the message: The drive is now showing "healthy" under SMART, where it was "error" before. Is there any way I can just re-enable the drive without rebuilding, then fix the filesystem on drive 3? I have attached the new diagnostics here. Also, regarding the Marvell controllers, are they any suggestions on what I should replace them with? tower-diagnostics-20201009-1018.zip

Thank you, ChatNoir. I have attached my diagnostics here. tower-diagnostics-20201008-0840.zip

Hello All, I have an array of 22 drives and 1 parity drive, all xfs formatted. Simultaneously Disk 2 is showing "Unmountable: no filesystem" and Disk 17 is showing disabled, with contents emulated. I would like to try to restore Disk 2 and also replace Disk 17. I would appreciate any feedback on in which order I should resolve these issues, or what approaches I may take. I have attached a syslog I just captured after stopping and restarting the array. Please let me know any additional information I can provide. syslog.txt

Thank you for the information. I could have sworn I had it set to "Only" before. I was under the impression that "Only" required any new data to go to the cache drive, but it still used the Mover. Regardless, I changed it to "yes", and it's not working. Thank you.

Hello, I recently completed the process of converting a couple disks from Reiser to XFS. Now, when I run the mover, it skips over my only share "Media". The other three shares are on my cache drive. Oct 2 08:48:39 Tower logger: mover started Oct 2 08:48:39 Tower logger: skipping "Media" Oct 2 08:48:39 Tower logger: skipping "appdata" Oct 2 08:48:39 Tower logger: skipping "apps" Oct 2 08:48:39 Tower logger: skipping "downloads" Oct 2 08:48:39 Tower logger: mover finished I have the "Media" share set to Use cache disk "Only", and I deleted all the hidden Apple directories as suggested in another thread. Could someone please give me some direction on this issue? My cache is filling up. Thanks. tower-diagnostics-20151002-0855.zip

If you are copying files from a corrupt filesystem, then it's likely that there will be problems when trying to copy some files. Thanks again. So would it make sense to copy what I can to a new drive (create a backup of sorts), then --rebuilt-tree the old drive and try to copy over what can be saved from that to the new drive?

Thanks, trurl. That's what I was afraid of. If I were to copy the contents of the bad drive to a new drive with XFS format, are there any potential issues that I'm not aware of?

So I relocated the SATA expansion card to an open PCIe slot, and was able to rebuild. However, I now get permission errors, and after running reiserfsck, I was told to run --rebuild-tree. I really don't want to do that, since I've lost a lot of data before with that. If I were to rebuild onto a new drive, would that resolve the reiserfs errors and move over all the files?

I was reading in another post, that connecting drives to SATA expansion cards, as well as directly to the motherboard is not a good idea. Could this be causing my issue?

The power supply is a Corsair AX850

Hello, I've been having trouble getting one particular drive (or really, one particular drive slot) to stay green. I have a NORCO case, and I replaced a backplane, as I was having that issue no matter what drive I plugged into the old backplane. I rebuilt a drive on the new backplane, and it was good for a while, but now it's back to being red-balled. I tried re-building to the same drive, and tried rebuilding to a different drive as well, but both are red-balling before the rebuild completes. My suspicion now is that the SATA extender card is at fault. The 2nd backplane the card is connected to has issues with 2 of the 4 slots as well. The card is a Super AOC-SASLP-MV8. I have another of those as well, but that one is working well. I would like to be able to determine if the extender card is the issue for sure before replacing it. I have attached the diagnostic zip from my version 6.0.1 unRaid server. The failing drive is Disk 13. Any feedback is appreciated. tower-diagnostics-20150826-0821.zip

Thank you. I will re-rebuild the drive and capture the reports. Those reiserfs errors seem to be popping up sometimes when I move files out of the lost+found folder and back into the array. I ran new permissions per an earlier response, but that didn't stop the errors.

I have attached the most recent syslog. Unfortunately, I didn't think to create a syslog after the rebuild. Should I rebuild again and capture a syslog after? syslog.zip

I rebuilt the drive after running reiserfsck. Not only did I rebuild the drive, which did not resolve the red ball, but I replaced it and put the new drive into a different drive bay. I am able to fully access the contents of the drive, but it's still red-balled, and I am unable to test parity.

Thanks, I ran this command, but the drive still shows up red-balled. Should I go ahead and run the "Trust My Array" procedure?

The syslog is attached. I see a number of reiserfs warnings that seem to be triggered when I'm moving files from the "lost+found" folder back to the array. syslog.zip

So I rebuilt the drive, and I still got a red ball. I ended up replacing the drive, and plugging it into a different slot, but I still show a red ball. The drive is mounted as part of the array, and I have access to it, but it shows as red. I have a hard time believing that the replacement drive is also bad, considering it had been working just fine as my previous parity drive. I ran reiserfsck --check and it found no errors. I have also attached a smart report on the new drive. Any suggestions on how to proceed? It seems like the next best step is to run the "Trust My Array", but I want to make sure that's what I need to d. Thanks. smart.txt

I did put it into maintenance mode and specified it with /dev/md12. So it looks like parity should be fine. In that case I will just rebuild the second drive from parity, and hopefully that will bring the drive back online. Thanks all for your help.

Thank you. Yeah, it's red. The whole array showed yellow, so that's what I was referring to. So at this point, it looks like my best bet is to rebuild the drive from parity. However, since I had to do a resierfsck rebuild on another drive prior to this one, I'm pretty sure parity isn't completely valid. Will I be OK to do a rebuild from parity, or am I going to have to use the "Trust My Array" procedure and potentially lose data? Thanks again.

Thank you. The requested files are attached. smart.txt

I did run in maintenance mode, and I can access all the contents of the rebuilt drive, but it's still showing as faulty. I just re-ran reiserfsck --check, and got the following error: reiserfsck --check started at Wed Jan 28 12:30:12 2015 ########### Replaying journal: Done. Reiserfs journal '/dev/md14' in blocks [18..8211]: 0 transactions replayed The problem has occurred looks like a hardware problem. If you have bad blocks, we advise you to get a new hard drive, because once you get one bad block that the disk drive internals cannot hide from your sight,the chances of getting more are generally said to become much higher (precise statistics are unknown to us), and this disk drive is probably not expensive enough for you to you to risk your time and data on it. If you don't want to follow that follow that advice then if you have just a few bad blocks, try writing to the bad blocks and see if the drive remaps the bad blocks (that means it takes a block it has in reserve and allocates it for use for of that block number). If it cannot remap the block, use badblock option (-B) with reiserfs utils to handle this block correctly. bread: Cannot read the block (460587008): (Input/output error). Aborted I'm tempted to just replace this drive, but I had to do a rebuild on another drive right before this one failed, and I'm sure my parity is out of sync. I just upgraded my system, and the specs are below: System: ASUSTeK COMPUTER INC. - SABERTOOTH 990FX R2.0 CPU: AMD FX-8370 Eight-Core @ 4 GHz Cache: 384 kB, 8192 kB, 8192 kB Memory: 8192 MB (max. 32 GB) Network: eth0: 1000Mb/s - Full Duplex Is there any way I can still save this drive, or do I replace it and hope for the best? Thanks.

I am running unRAID 6 beta 12, and have attached my system log to my initial post.

Hello, I recently had an issue with one of my drives (4tb WD green), where it was listed as unformatted. I ran reiserfsck --check, and it told me to run with --rebuild-tree, which I did. The first time, it aborted, but finished the second time. However, the unraid GUI is still showing the drive as faulty. I re-ran reiserfsck --check, and it found no corruptions. Also, I ran the long SMART self-test on the drive, and it found no errors. Could someone please let me know what I should do next? Thanks. unraid_log_20150127.txt

Thank you. I didn't even think about that, but it worked as you said.