ZipsServer

Sorry for taking so long to respond. The parity build and then work got in the way. I almost made the mistake of using non-matching PSU cables. Its kinda stupid the cables aren't made to the same specs... The 10TB are not appearing at all. I can hear them spin up when I plug power in, but otherwise they are not identified in BIOS or /dev/sd*. I also tried powering both 10TB drives from the original power supply that they were working with (so not a 3.3V issue). So for whatever reason, both 10TB drives started to error and then just died. I purchased these at the same time in 2020 and they are just a few months past their warranty.... These are my first drives to fail. I still have some 3TB REDs from 2013 doing 300k read/writes a day.

Hi, it's me again. So I bought a new HBA (LSI 9211-8i), new SFF-8087 cables, and a new 650W PSU just to power the HDDs. All the new gear appears to work well. However, the 10TB drives that were previously problematic are no longer appearing. They seem to be completely dead. I have tried them on both PSUs and both HBAs. Are there any other ways to confirm they are completely dead? While waiting for the new gear to arrive I managed to transfer all the data from the 10TB disks to other disks in the array. I then removed them from the system and had them sitting on a shelf. EDIT: Good news is that I am building parity with no issues. mastertower-diagnostics-20220917-1641.zip

@trurl I actually just swapped drives around in the cage that seems to be problematic. Only disk2 is unmountable now. I am going to try to move disk2 out of that cage... maybe 2 or more slots in that cage are bad.... or maybe I need to buy some compressed air? But to your original question, yes I think, if the actual superblock is bad then I can use fsck to restore one of the backups. However it seems like if the hardware problems is resolved then I might not have to worry about that. (Had similar issues with my external drives when the USB header was loose.) mastertower-diagnostics-20220902-2225.zip

Update: I am now having disk errors with both disk2 and disk3. The log said they had bad super blocks and were unmountable. So the issue now exists even with the parity drive completely removed. I just ordered a new LSI 9211-8i with SAS breakout cables, but it sounds like I should also purchase a new PSU? Any recommendations for powering 10-15 SATA drives? Most PSUs don't even to seem to come with cabling for that many drives... EDIT: I may also accept recommendations on how to move away from those ICY Dock cages (if they are the problem) to something more quiet. I have this Xigmatek case

Just realizing I have been an unraid user for 10 years now..... @trurl I just looked back at my Newegg history..... It is a Rosewill 550W 80+ Gold purchased back in 2012, along with the mobo and other components.... might be time to replace some parts? @kizer No, only using the standard power cables that came with the PSU. The drive cage could be suspect. I am using the ICY DOCK MB974SP (also purchased in 2012)

@JorgeB Correct, I connected disk3 to onboard SATA with a different generic SATA cable. The power cable was the same. I have not moved power cables around. disk3 and the other drives with errors are all in the same hot-swap cage so the power cables are connected to the hot-swap cage. @itimpi I don't have any brown out or similar problems when I spin up all the drivers at once, so I doubt power rating is the problem. It is a 8+ year old system that has been running 24/7 most of the time so maybe the PSU is going bad? Although it is connected to a battery backup with a power conditioner on it.

I swapped the parity disk and disk1 between hot swap cages. Now disk1, disk2, and disk3 are erroring. disk1, 2, and 3 are all in hotswap cage 1 which are all connected to the HBA card on port/connector 0 via a SAS breakout cable. Maybe the SAS cable randomly went bad? I could order a new HBA with new SAS cables. I probably need to do this anyway so I can get my external drives properly added to the array. Any other things to check before deciding to buy new equipment? mastertower-diagnostics-20220831-2028.zip

I have not replaced any cables, I did not swap the power cables, nor have I used different SAS cables to connect the drives to the HBA. However, I did swap the drives around in the hot swap cages at the very beginning before I posted in the forum... which would have swapped both sata and power connections. And then I also connected the drives straight to the MB as requested, which was the most recent configuration The fact that there are only errors when I try to add a parity disk still doesn't make sense to me. Is there anyway to check the HBA or MB for problems?

@JorgeB Same behavior this time, however I think I got the diags before it spammed the syslog too much. The array runs perfectly normally without the parity disk. I have now copied all data from disk2/3 onto other disks in the array with now issues. Googling some of the errors returns this, which suggest these problems are from bad sata cables.... but I am not sure how to interpret this in the context of these errors only happening when I add a parity drive... mastertower-diagnostics-20220830-2152.zip

Not sure what happened, but somehow the disks were unmounted and the array stopped mastertower-diagnostics-20220829-2208.zip

Switched disk2 and disk3 to the SATA connection on the mobo. There seems to be problems preventing disks from being unmounted and the array from stopping. (failed command: READ FPDMA QUEUED) diags attached. probably going to have to hard shutdown mastertower-diagnostics-20220829-2204.zip

Thanks everyone. Last night I ran an rsync command to copy all the contents from disk3 to another disk(8). That completed with zero errors. So it does seem to be something weird with adding the parity disk. I will update the LSI firmare and then retry adding parity. EDIT: Updated LSI (wow that was easier than the first time I did it years ago, thanks JorgeB!) but I am still running into the same issues with disk2 and disk3 when adding parity. diags attached mastertower-diagnostics-20220829-2146.zip

I am going to keep the parity disk out of the mix for the moment, move all the data off disk2 and disk3, reformat disk2 and disk3, and then try adding parity back in. Any thoughts or insight on this series of events of plans?

Yes, I know external disks are not recommended for the array or pools. It is an unfortunate stop gap measure at the moment. However, I am running all of those external pools in btrfs single disk mode so there is no RAID. I tried adding a parity disk back to the setup, but disk2 and disk3 are still erroring out when trying to build parity. I have attached new diags. This makes no sense since the smart test showed no problems and the disks do not error when there is no parity disk. mastertower-diagnostics-20220828-2025.zip

Tried moving them from disk3 to disk9. I used "rsync -av --remove-source-files /mnt/disk3/folder-path /mnt/disk9/" which I entirely regret now. disk3 was not disabled at that time, but there were I/O errors which is why I was trying to move those files off. rsync started to give errors that it couldn't copy the files and said something like "will try again". It is also embarrassing to admit that I was running the array without a parity drive because I had issues adding one a month or so ago. I forget the exact issues that prevented me from adding the parity.

... yesterday I was trying to move my most important photos/videos off disk3 and it appears that those files are now gone/missing.

Thanks! Here are the new diags. As you will see in the diags, - I have my external drive pools disconnected for now. - I ran an extended self test overnight on disk3 and it showed no errors. Should I try to add parity back in now to see what happens? mastertower-diagnostics-20220827-1451.zip

One pass of Memtest completed without any errors.

I recently moved my unraid server to a new location and was having I/O issues on some of my external drives that seemed to have been caused by a loose internal USB connector. I think I fixed the external drive issues [so I went to add a parity drive] and then all of the sudden two of my array drives (disk 3 first and then disk 2) started to have I/O errors [when I tried to start the array and build parity]. I checked the cables and even switched drives around in my hot swap cages to see if it was a cable problem. I then tried running a btrfs scrub on disk3 which aborted itself. I turned off the machine to switch drives/cables around again, restarted, and now disk3 is unmountable. The most recent diagnostics is with disk3 unmountable. The earlier diagnostics is when I was having I/O errors, but the disk was still mounted. It seems like a hardware problem somewhere, but it seems unlikely that I would have multiple drives fail like this. EDIT: I feel like I am chasing my tail here so I want to stop before I do any damage. mastertower-diagnostics-20220826-1636.zip mastertower-diagnostics-20220826-1526.zip

The drive errors when adding the parity to the array is another problem, for which I can create a less dramatic thead topic..

It is amazing how adrenaline can narrow one's focus. Thanks for bringing me back up to the surface. I forgot to adjust the User Share setting to include the new disk I added to the array. So when I reordered the drives, a drive with data on it was excluded from being included in the User Shares. That's embarrassing, yikes. It has been awhile since I have performed any real maintained on the server.... But yes, I know that USB drives are not optimal, unfortunately I have run out of room and SATA ports with my current enclosure and setup. Need to move to a rack mount system or add a new SAS JBOD card and some 3D printed drive mounts... but that takes more time than I have atm Thanks trurl!

I can't believe what I have done, at least what I think I have done. I was adding a new parity disk (that was not precleared) so I used the "New Config" tool to both add a parity drive and reorder the drives. When I started the array, two of my 10TB disks completely error-ed out (block level I/O). I repeatedly tried to cancel the Parity process which froze the machine. I did a hard shutdown, rebooted, checked the SATA cables, and tried again. Same thing happened, except the machine didn't fully freeze. I got the logs (attached) and then did another hard shutdown. I removed the parity drive, thinking it was the causes of these weird issues, used the new config tool, and restarted the array. After removing the parity drive and restarting, my 10TB do not have any block-level IO problems now. However, accessing my user shares, it seems that I have lost a lot of data (most of my photos, some video, etc). Not sure how extensive the loss it. The only thing I can think of is that when I started the array it tried to rebuild the array using the invalid parity drive!?!? I definitely did not think this was the default behavior and I did not select any such options. I'm hyperventilating. Any advice? mastertower-diagnostics-20220717-1227.zip

Hi everyone. I have finally accepted the fact that it is time for me to upgrade my original 2013 build to a solution that supports more disks (16+). I am also completely ignorant to the current state of hardware and what is hot. The good thing is that I really only use Unraid for network storage and downloading. Part of me wants to stay with a tower to keep it small and pleasant to look at, but I am probably leaning towards a rack mount chassis that supports 16+ 3.5" drives. I would like recommendations on what to do with the old hardware. Anyone have ideas on how to use it in a new build? Gear List: Asus F1A75-V PRO AMD A8-3870 3.3GHz APU 2x4GB DDR3 LSI SAS Card Flashed to IT Mode + 2 x (SAS -> 4 SATA breakout cables) 2x ICY DOCK 4 in 3 Hotswap Cage Rosewill 4 bay hot swap 2.5" Xigmatek Elysium Tower Chassis Rosewill 550W SMPS ZALMAN 120mm CPU Fan 14 x 3.5" Spinning disks 4 x 2.5" SSD I have an additional tower as well as an HP blade chassis that runs Proxmox with most of my VMs/containers. I use my Unraid machine for downloading, network storage, and backups (of course). I would like at least 16 bays (preferably hot swap). My budget is around $500-$600 for a chassis and components. I have a feeling that may put me in the used market?

I should have mentioned that I already tried another USB port (one integrated on the MB and one plugged in to the MB via an adapter) I also do not have any SATA ports free. I only have 14 slots and they are all filled. Really need to upgrade to a new case/SAS backplane. (That is also why I am running three other drives via USB ports)

I had a new 12TB disk (attached via USB) fail on preclear twice now. I am on Unraid 6.9.0-beta25 with Unassigned Devices 2020.07.26b (Plus 2020.05.22). I also tried on Unraid 6.8.3 before upgrading to the new beta. Here is the disk log which is showing errors that I do not understand. Furthermore the errors seems to happen earlier before the webui notified me that the preclear had failed. I have precleared other USB disk drives multiple times before (> 6 months). However recently (< 1-2 months) I am having problems with other disks attached via USB (causing docker/system hangs and other nasty things) Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] 1465081856 512-byte logical blocks: (750 GB/699 GiB) Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] Write Protect is off Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] Mode Sense: 47 00 10 08 Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] No Caching mode page found Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] Assuming drive cache: write through Jul 29 19:43:31 MasterTower kernel: sdb: sdb1 Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] Attached SCSI disk Jul 29 19:43:31 MasterTower kernel: BTRFS: device label cache1 devid 2 transid 9272 /dev/sdb1 scanned by udevd (1339) Jul 29 19:44:13 MasterTower emhttpd: WD_Elements_25A3_574D41553430303136323237-0:0 (sdb) 512 1465081856 Jul 29 19:48:38 MasterTower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Jul 29 19:48:38 MasterTower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 00 00 00 00 20 00 Jul 29 19:48:38 MasterTower kernel: blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 Jul 29 19:48:38 MasterTower kernel: blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Jul 29 19:48:38 MasterTower kernel: Buffer I/O error on dev sdb, logical block 0, async page read Jul 30 17:18:01 MasterTower kernel: sd 1:0:0:0: [sdb] Spinning up disk... Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] 23437705216 512-byte logical blocks: (12.0 TB/10.9 TiB) Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Write Protect is off Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Mode Sense: 47 00 10 08 Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] No Caching mode page found Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Assuming drive cache: write through Jul 30 17:18:18 MasterTower kernel: sdb: sdb1 Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Attached SCSI disk