jbuszkie

I'm copying big enough files that get past the cache pretty quick, I imagine.. one thing I noticed when I broke the unbalance into smaller chunks, was that the copy would be "finished" but the remove (rm) command took a while.... or like it was waiting for the disk to be ready again before it could start the next group..

Grasping at straws?? 😄 I think the shingled drive might be my answer...

I think my issue might be the fact that my destination drive is an archive (Shingled?) drive? That might be killing my writes? Jim

My md_write_method is set to reconstruct write.

No... These are DVD VOB's pretty decent size.. I just upgraded a disk. It finished before I started the move.. Everything is green.. But I wonder if it's still trying to emulate the disk I upgraded... Maybe I'll try a reboot. Also, I started a docker upgrade (just recently after I noticed the slow move) and it's taking forever! The dash board said I'm about 50-80% cpu usage... Extracting is taking forever... Once that's done I'll try a reboot, I guess... Jim

I even turned off my crash plan docker before I started it...

No this is a modern 4 core.. (8 thread) i7..

I just added a second parity disk. That went fine. Now I'm trying to empty a disk (using unbalance) so I can finally change the few riserfs's I have left. Before dual parity, the move was about 30-45MB/s... Now with dual parity I'm hovering 13-15MB/s Is this expected? Thanks, Jim

That will work!! I didn't see the advanced settings! Thanks!

*pout* Not what I wanted to hear.. But what I expected to hear... Thanks for confirming, Squid....

Bump...

If you don't have any parity then you don't have to run this script. With the array stopped just pick no device for that slot and go with the new config keep current assignments.... as I understand it. Now I've never tried this with no parity drive assigned.. So maybe there is a bug there... The whole Idea with the zeroing drive script is to keep parity valid while you remove a drive from the array. But you don't have parity so you should be able to just pull the drive. You could also try "new config" without the preserve and just re-assign. Just make sure you take a picture or write down the current assignments so you can duplicate them... What I did with the array stopped was to remove the drive from the list first, then I did the new config with preserve and it worked fine for me. Jim Edit: Now I see this was already replied to! Stupid browser not bringing me to the last message!

*Sigh* Everyone may know this but I didn't... When using user scripts if you click outside the script window in the main window that will also kill the script. So not just hitting the "X".. I was about a 1/4 into zeroing out a drive when I accidentally click outside the script window and killed it! *sigh*

Nice! I missed the 0000:04:00.0 being able to be mapped back to a PCI device! From the LSPCI I also could have seen that 04:00.0 mapped to the ASMedia device! Thanks, Jim

Ok.. I give up.. How were you able to tell that ata7 and ata8 where the Asmedia ports from the syslog? Because I know my motherboard.. I could figure it out.. But I can't find anywhere which ports are mapped to which controller in the syslog... There is no mention of asmedia in the syslog.

I keep forgetting how to piece everything together in the syslog! I haven't had to look at the syslog in a long time LOL. I have to re-learn each time 😄

Has anyone ever had issues with a slot going bad in the Norco drive cages? Two different slots in two different cages are, potentially, giving me issues. One is causing the drive to disappear and the other is give sporadic CRC errors. I'm going to look into if it's the cables or the slot. But I was curious to know if anyone ever had a slot go bad on them?

Hehe.. You have an extra 0 in the part number! No wonder the search came up with nothing! 🙂 BPN-DE350HD

Crap! Those are two different Norco drive cages. One with the dropped disk and one with the CRC errors. And it's not like I bumped the machine or anything.. I guess it's time to open her up and check for loose cables to the cages! So the drive might be good??? hmm.. Anyone seen years of vibrations knocking a sata cable loose on a drive cage? I *think* both of those slots in question are connected to the MB not the LSI card... Has anyone seen norco slots go bad? Thanks @johnnie.black

Look at the 800K one.. The errors start around 8:16ish

Yeah this after the reboots during the rebuild So the disabled disk info is not there... ... I actually found the syslogs.. syslog-20200311-074811.txt syslog-20200311-082322.txt

I'll give the diags.. But I'm not sure what help it will be. They don't contain any historical data about failed disks, right? You would be able to see the CRC errors in the SMART report.. What else is useful in there? tower-diagnostics-20200311-1114.zip

I'm seeing this too.. I remember something sent to me about them requiring more log in This what I found on in my e-mail

Yeah.. I know the CRC are connection issues.. usually.. But these cables haven't been touched in years... I'm worried about the drive red-balling in slot A... Is it the drive or the slot...

Some history... I had a 8T drive fail (red ball) recently in slot will call it A. I had a spare 8T unassigned device so I swapped it in and rebuilt fine. I ran pre-clear on the "failed" drive in slot A and it failed in the zeroing phase.. Ok maybe it was a bad drive. So I bought another 8T drive to keep as a spare. I shucked it and threw it into slot B. Slot B had an old 4T drive that I took out of service for some reason. I ran pre-clear on the new 8T drive in slot B and it ran fine. No issues other than a couple UDMA CRC errors. It was only like 4 or 5.. So I scratched my head and continued. I want to remove 3 2T disks so I put my "spare" in slot B in the array. I took all the stuff on one of the 2T disks and put it on the 8T drive in slot B. That ran fine an came up maybe with one or two more CRC errors. I zeroed out the 2T drive and emptied the 2nd 2T drive on the 8T in slot B. That went fine... but a couple more CRC errors. So I'm thinking maybe slot B has some issues with the cable? The first 2T was ready to be removed from the system So I removed it and created a new config and trusted parity. That went fine. I started a parity check and that was working fine so I stopped it. I shutdown the array and was going to try the new disk in a different slot. I moved the new 8T into slot A and removed the "failed" 8T I started the system and copied more files from the 2nd 2T disk that I wanted to empty. After that was done I noticed that the new disk in Slot A red balled!!! It had a bunch of errors (like 6k) Shoot! WTF! So now I put the new 8T back in Slot B. And it's currently being re-built! It's moving along at 7% with no disk errors. It's up to 14 CRC errors. but I think that's what it started with at the start of the re-build. So do I have a bad drive or bad slot(s). The slots are in 2 different 5 bay norco drive cages. Trying to figure out how to proceed.. Look to the experts here..