SavellM

No splitters, and all powered by a backplane, and directly attached to molex. But maybe I'll shut it down and give them all a wiggle and make sure its cleanly in still. We did have some poweroutages a week or two ago, but server is on UPS and was shut down cleanly.

Hi all, I'm seeing a ton of random kernel: blk_update_request: I/O error in my logs. I just added a new drive that is Pre-Clearing disk: sdy to replace the missing Disk 12. Anyone know why it could be getting these alerts? May 22 10:47:42 Odin kernel: blk_update_request: I/O error, dev sdf, sector 1525788360 op 0x0:(READ) flags 0x80700 phys_seg 32 prio class 0 May 22 10:47:42 Odin kernel: sd 1:0:4:0: [sdf] tag#3879 CDB: opcode=0x28 28 00 1f 1a 7c 18 00 01 00 00 May 22 10:47:42 Odin kernel: sd 1:0:4:0: [sdf] tag#3913 UNKNOWN(0x2003) Result: hostbyte=0x0b driver

@JorgeB and anyone else, I think I may have figured it out. So SMB seems to be the issue. As I have like 500 plots, when the Chia miner is reading the plots its opening around 500 streams. I think this is what was causing the server and everything to fall over. I change the mount of the miner to a NFS share and so far so good, no drops.

Ye that wont really work. Not sure what else I can do/test

@JorgeB Do you know if I can take these drives out of the array, and put them in their own pool like Cache pool without losing data? Just try to isolate them a bit more?

Its happening again while trying to copy... This is killing me!

Yeah its super weird. Copy or Mover and just no dice... kinda sucks.

Is anyone able to help me diagnose further?

Hey guys, So I've been having an issue where if I copy files over to the array via network for instance it causes outages and lockups. Outages are other PC's that are reading files from a network share are no long able to access the share. Or lockups are when I connect to the server SSH and I do something easy like HTOP or LS a file, it just hangs for a good 5mins+. It does come back to life eventually on its own as/when the copy finishes. This also affects files on the Cache and then mover runs it causes the same issues as above. I have tak

I did test with a spare pool, but not properly. Give it a go, no harm no foul.

1) I use my array as if I lose my plots I'd cry its taken so long to make them. But you can use anything really... I had spare drives in my array, so I just set them to spin forever. 2) I dont do this, I got 2 spare Intel SSD's that I use for plotting via unassigned devices I did do 1 or 2 plots via my Cache pool as a test. Just make sure you link it via the container otherwise you'll plot to your docker.img file and it'll blow. 3) I use both unRAID and my gaming PC and just have my gaming PC transfer the plots to my array via a share. Hope t

I plot on unRAID and my windows gaming pc and then copy's the plots to unRAID where it gets farmed.

Ok even tho I have it to set to TRIM daily, over the last few months. Its still expected to TRIM so much?

There is? Can you link it to me, I cant see it.

I downloaded and installed the TRIM plugin. I set it to run daily. I have a few SSD's, 2 in Cache, 2 in Media_db and then some in unassigned devices. Today I decided to run /sbin/fstrim -v /mnt/cache /mnt/cache: 1.6 TiB (1795191562240 bytes) trimmed All my SSD's trimmed a fair amount. Is the plugin not working? Or am I missing something?