Maticks

looks to be fixed after a reboot and the plugin changed.

With the plugin disabled the drives spin down as per below, but without the cachedir plugin a Plex scan will spin up all the disks that are part of that share. The plugin did stop that from happening by holding the directories in memory during the scan. Though disks are spun down without the cachedir its not an ideal situation. In all fairness when i did my plugin upgrade i never rebooted, so i will go do that now. But my settings for cachedir are below as well, do they look right.

i upgraded the plugin and turned on user share, didn't make any difference for me still has activity. There is less activity when the plugin is off. The plugin use to work really well maybe something in 6.x.x has upset it.

i've added -u to set user shares. Nov 8 00:45:44 Vault cache_dirs: Starting cache_dirs: Nov 8 00:45:44 Vault cache_dirs: Arguments=-i Cloud -i Movies -i Music -i TV -i isos -i system -p 0 -U 0 -l on -u -d 20 Nov 8 00:45:44 Vault cache_dirs: Cache Pressure=0 Nov 8 00:45:44 Vault cache_dirs: Max Scan Secs=10, Min Scan Secs=1 (min scan seconds ignored, always sleep max) Nov 8 00:45:44 Vault cache_dirs: Scan Type=adaptive Nov 8 00:45:44 Vault cache_dirs: Max Scan Depth=none Nov 8 00:45:44 Vault cache_dirs: Use Command='find -noleaf' Nov 8 00:45:44 Vault cache_dirs: Version=2.2.0j Nov 8 00:45:44 Vault cache_dirs: ---------- Caching Directories --------------- Nov 8 00:45:44 Vault cache_dirs: Cloud Nov 8 00:45:44 Vault cache_dirs: Movies Nov 8 00:45:44 Vault cache_dirs: Music Nov 8 00:45:44 Vault cache_dirs: TV Nov 8 00:45:44 Vault cache_dirs: isos Nov 8 00:45:44 Vault cache_dirs: system Nov 8 00:45:44 Vault cache_dirs: ---------------------------------------------- Nov 8 00:45:45 Vault cache_dirs: cache_dirs process ID 19516 started

I am running cache_dirs version: 2.2.0j which is saying its the latest version.

Ran into this thread after noticing my disks not spinning down for quite some time. When i turned off Cache Dir it finally spun disks down for the first time in months. I have my depth set to 20 i only need 17 to catch all my files but i set this for headroom. Adaptive makes no difference however. 2018.11.07 12:32:40 Executed find in (1s) 01.70s, wavg=03.99s Idle____________ depth 20 slept 10s Disks idle before/after 1541554359s/1541554361s suc/fail cnt=8/9/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=13%, filecount[20]=73711 2018.11.07 12:32:51 Executed find in (1s) 01.75s, wavg=03.89s Idle____________ depth 20 slept 10s Disks idle before/after 1541554371s/1541554373s suc/fail cnt=9/10/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=15%, filecount[20]=73711 2018.11.07 12:33:03 Executed find in (5s) 05.43s, wavg=04.14s Idle____________ depth 20 slept 10s Disks idle before/after 1541554383s/1541554388s suc/fail cnt=10/11/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=17%, filecount[20]=73711 2018.11.07 12:33:19 Executed find in (1s) 01.09s, wavg=03.95s Idle____________ depth 20 slept 10s Disks idle before/after 1541554399s/1541554400s suc/fail cnt=11/12/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=14%, filecount[20]=73711 2018.11.07 12:33:30 Executed find in (0s) 00.09s, wavg=03.67s Idle____________ depth 20 slept 10s Disks idle before/after 1541554410s/1541554410s suc/fail cnt=12/13/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=15%, filecount[20]=73711 2018.11.07 12:33:40 Executed find in (1s) 01.41s, wavg=03.51s Idle____________ depth 20 slept 10s Disks idle before/after 1541554420s/1541554421s suc/fail cnt=13/14/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=15%, filecount[20]=73711 2018.11.07 12:33:51 Executed find in (0s) 00.71s, wavg=03.27s Idle____________ depth 20 slept 10s Disks idle before/after 1541554431s/1541554432s suc/fail cnt=14/15/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=15%, filecount[20]=73711 2018.11.07 12:34:02 Executed find in (6s) 06.39s, wavg=03.58s Idle____________ depth 20 slept 10s Disks idle before/after 1541554442s/1541554448s suc/fail cnt=15/16/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=21%, filecount[20]=73711 2018.11.07 12:34:19 Executed find in (0s) 00.09s, wavg=03.26s Idle____________ depth 20 slept 10s Disks idle before/after 1541554459s/1541554459s suc/fail cnt=16/17/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=17%, filecount[20]=73711 2018.11.07 12:34:29 Executed find in (0s) 00.09s, wavg=02.94s Idle____________ depth 20 slept 10s Disks idle before/after 1541554469s/1541554469s suc/fail cnt=17/18/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=14%, filecount[20]=73711 2018.11.07 12:34:39 Executed find in (0s) 00.09s, wavg=02.62s Idle____________ depth 20 slept 10s Disks idle before/after 1541554479s/1541554479s suc/fail cnt=18/19/0 mode=4 scan_tmo=150s maxCur=20 maxWeek=20 isMaxDepthComputed=1 CPU=15%, filecount[20]=73711 I've tried setting my cache pressure to 0 and memory limit to 0 but makes no difference for me. attached are my settings. As per my attachments, i basically see every scan in the cache_dir.log file increments the disks all spike with read accesses. Even though the content on all the drives is unchanged. Even went i shutdown VM and Docker completely and unplug it from the network i still see these disk reads that coincidence with cache_dir.log find. This seems to be preventing the disks spinning down, which seem to be the point of this plugin Maybe someone can point me in the right direction here. Not all my shares are across all my disks either, but my included folders in Cache Dir will include all the disks except my Disk 13.

I can't believe it's happening again, so my old motherboard which i had an SSD 256G about a year ago i added a second 256G and setup a cache pool. I ran into read errors a few hours after the system was running, i repaired them and it happened again randomly. When i pulled a disk out the problem went away, when i added a new replacement SSD the problem happened again it seemed like some kind of BTRFS bug. Fast foward a year, i've installed my old gaming system motherboard into unraid, i have two NVMe drive's on my board and i know they are both fine given they were raid0 for over a year. I have these two disks as the BTRFS Cache pool and it's happening again.. same problem, i am moving everything off the cache drives will format it and go back to one BTRFS disk. But my question is will this be ever fixed? any reason why we can't have something other than BUGFS ?

@johnnie.black so an update for everyone. I turned out to be the BIOS on the HBA causing some kind of weird conflict, i erased it from the HBA and the problem went away. You only need the BIOS on the HBA if you're using this as a boot drive which since unraid uses a USB that is never going to happen. Running 6.6.3 without any issues. I ended up doing my upgrades anyway.

Yeah Corsair are sending a replacement and then i post back the RM850 when i get it, but i didnt want to leave it that long. So i went and got a HX750i, didn't want to leave the RM850 on my desktop too long otherwise who knows if it will fry that motherboard as well.

So even with the PSU changed it still had issues. i had to run it a few days on my desktop system because i didn't have a spare. I noticed that even at 500Watts from my desktop system which has no 5V devices plugged in. something a bit odd. The Fan on the PSU doesn't spin at all, and it was so hot you couldn't touch the PSU case. Likely part of the problem. The new HX750i is now in place. PCI-X slot 1 is also not happy i see errors if i have the HBA in that slot. So i've put the HBA in the second slot. Likely the power supply has damaged other parts on the system, likely the motherboard. When the new processors come out 9700k's, ill get a new motherboard/cpu/memory for my desktop. Move my current desktop Z170A Xpower MSI Board, 6700k and DDR4 memory over to the Unraid Server and sell off the old parts online. Someone who has a spare motherboard can work out if its memory, cpu or motherboard thats faulty here. 6.5.3 is stable, the system really hates 6.6.X if i do an upgrade it comes apart. I am assuming it has something to do with the overall hardware issue i can't fix without changing things out. Unfortunately for now an old hardware means i'd have to buy more stuff to test it and that just doesn't seem practical since it will be second hand likely given the age of the platform. I am happy with the peak load when i run a parity check on the 5V rail i was expecting a bit higher than what i got. Well under the 25A's, but at least i can monitor this on a VM from now on. rule out that whole drama as well.

upgraded to a HX750i and pushed the USB header into a VM on Unraid to get corsair link working. This is my peak usage when i run a disk check it spikes to this load on the 5V, well under the 25A.

I thought i was on P20.00.00 but i am actually on P20.00.07. Does it need to be a version before P20?

Looks like when 6.6.X is upgraded to if your LSI Card is running firmware P20.00.00 it needs to be upgraded to P20.00.07. If not it will be incompatible with 6.6.X and start throwing read errors randomly on drives. As per the thread attached below, i am waiting till my system is idle then i can try this method i can confirm i am running P20.00.00.

interesting... i think i am running P20.00.00 as well. certainly ran into the same issue. so 00.07 is a lot better ?

mine is also running IT firmware, and it runs stable on 6.5.3 and when i upgrade to 6.6.1 it starts throwing errors only with that upgrade.

Thats what started it off. Sep 29 01:50:39 Vault kernel: mpt2sas_cm0: SAS host is non-operational !!!! ### [PREVIOUS LINE REPEATED 5 TIMES] ### Sep 29 01:50:44 Vault kernel: mpt2sas_cm0: _base_fault_reset_work: Running mpt3sas_dead_ioc thread success !!!! Sep 29 01:50:44 Vault kernel: sd 7:0:0:0: [sdb] Synchronizing SCSI cache Sep 29 01:50:44 Vault kernel: sd 7:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:0:0: [sdb] tag#0 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 0 Sep 29 01:50:44 Vault kernel: sd 7:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:0:0: [sdb] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 5e 99 fe d0 00 00 00 08 00 00 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1587150544 Sep 29 01:50:44 Vault kernel: sd 7:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1588554072 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1588554384 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1588554504 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1588554560 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1588554624 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1588554640 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1588554744 Sep 29 01:50:44 Vault kernel: print_req_error: I/O error, dev sdb, sector 1588554808 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 5e 99 fe d0 00 00 00 08 00 00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 5e b0 18 a0 00 00 00 10 00 00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 5e b0 19 10 00 00 00 08 00 00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 5e b0 19 40 00 00 00 08 00 00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 5e b0 19 78 00 00 00 08 00 00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 5e b0 1b 70 00 00 00 08 00 00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 Sep 29 01:50:44 Vault kernel: sd 7:0:4:0: [sdf] tag#0 CDB: opcode=0x88 88 00 00 00 00 00 5e b0 1b 88 00 00 00 08 00 00 Sep 29 01:50:44 Vault kernel: mpt2sas_cm0: removing handle(0x000c), sas_addr(0x4433221103000000) Sep 29 01:50:44 Vault kernel: mpt2sas_cm0: enclosure logical id(0x500605b003cc0de0), slot(0) Sep 29 01:50:44 Vault kernel: sd 7:0:1:0: [sdc] Synchronizing SCSI cache

I upgraded to 6.6.1 and the read errors came back but it was a bit different this time. It never broke the parity disks and it only happened for a little while and it was only 4 disks not like last time. Truly weird, i've rolled back to 6.5.3 and attached the diag file maybe something in my system is too old for 6.6.1. vault-diagnostics-20180929-0959.zip

I've already disabled all my disks spinning down about 3 months ago. I was suspect that the power spikes of disks spinning up might cause some issues with how many drives i have. So that made no difference. The memory switching didn't make any difference nor did picking different memory slots. What did make a difference when i switched over my PSU and the power cables all the problems have gone away. @johnnie.blackhas been saying i think for the last 3 times this has happened its my power supply but is simply didn't believe him it was that. But after changing it out, it's just gone away. i've pointed a 120mm fan at the HBA heatsink there is low too no airflow there. I'll be keeping that change. My desktop power supply is in my Server an RM850i and the RM850 from the server is in my Desktop for now. I've rebuilt both parity drives, rebooted the system about 6 times without any issues. I am now going through running File Integrity on the drives Disk 1 and Disk 10 in particular since they were hit the worst. So far 6 files corrupted so i will manually restore those. But looking good so far. I've ordered a new Corsair HX750i rather spend a bit more and get that 10 Year warranty. I have contacted Corsair support about my RM850 from 2014 and too my surprise they've shipped me a replacement and charged me for it. But when they get my RM850 back they will refund the cost of the RM850 replacement. Once the HX750i arrives tomorrow i'll put that in my server. Move the RM850i back into my desktop machine. I can push through the USB Header the power supply is plugged into on the corsair link cable to a windows VM. Then i can read the power supply data directly off the VM check how things look going forward. My RM850 will go to a mate of mine building a new system, that will save him $200 and it has a new 5 year warranty. I am somewhat hopeful it is over, but still have a little thing in the back of my head say you never saw something break and it be fixed. I honestly think it was my spin down of 13 disks, when plex would do its nightly scan they'd all turn on at once every night for 2 years. It would have been several times a day the same surge of disks starting, it could have overwealmed the 5V rail or something odd. The RM850 is working fine in my desktop but i have no SATA perf's plugged in the SSD's are M.2's and a graphics card on PCIE cables. I won't risk running something dying though in a good machine it will blow up at some point i am sure. Also i might add that putting a fan at the HBA has also seem my disk speeds shoot up a good 60MB/sec more. Maybe here was some thermal throttling there also.

So i pointed a Fan at the HBA headsink and it still crashed 30 minutes later. I removed the PSU from my desktop system which is an RM850i and replaced my server RM850 power supply with it. So far completely stable.. but it does do this. I am doing a parity rebuild and will see if it breaks down or finishes in 11 hours. If it finishes ill give it a reboot in the morning leave it for an hour or two and give it a few more reboots see if i get the read errors again. It’s looking like a power supply replacement is in order $200 i can deal with. Im considering the HX750i given i was planning to add on 4 more drives in the future. I use around 250Watts at peak load. Any suggestions for a brand of power supply or model that gives me more drive support or more power support on the 5V rail i think is whats needed here more. Corsair i’ve always had a good experience with so i’ve always picked them. Hard Drives and CPU is all i use this system for no graphics cards.

I've tried switching out all my memory and now changing from slots 1 and 3 too 2 and 4. @jonathanm there isn't a lot of airflow in that section of the case, but it hasn't presented an issue before. I just installed a 120mm fan and pushing cold air all over the HBA lets see if that helps thanks for pointing that out. I have touched the HBA heatsink it doesn't feel that hot but who knows maybe it hits a high temp at some point and throws errors. Next fail attempt ill be changing over the power supply and see if that helps.

RM has 14 + 10 24pin layout while the RMi has for some reason 18 + 10 layout. That would end with a very bad day and i am sure then the motherboard will be needing replacing. Best i switch those 24 pin cables with the right power supply, what i stupid thing to do. People made custom RM cables for their RMi power supplies and discovered it did more than just look pretty. What has me stumped is when this happened 3 months ago i did my disk rebuilds and rebooted it a few times no issues also slammed it with read and writes. Even build File Integrity which slammed the whole array making hashes, not a problem. If it was the PSU i'd expect it to be flaky here and there not go 70 days with no issues. It so odd, but clearly something hardware is not happy.

im trying switching around memory at the moment. i've removed two sticks so i have only two in their now. Will switch out one stick at a time till have tried two different sticks. If that happens ill switch out the power supply i have an RM850i in my desktop and an RM850 in my server so i can switch them around and see if that fixes it. Cabling is exactly the same from what i can see. Apart from that my motherboard is a Z87 EVGA about 5 years or 6 years old. So maybe its on the way out. It's hard to tell nothing is standing out as being faulty, i hate these types of issues. i like easy ones, smoke, clicking or just dead. Gremlins in my server. Also HBA is running P20 which is the latest patch so thats ok as well.

@Benson i spoke too soon. This time the two parity drives and one disk on the LSI card as well. still cant work out whats causing it. Just took out another stick of memory so i have 2 in their now. If it happens again ill change out one stick give it another go and then change it around after that. It should at least rule that out. This feels like memory to me given its pretty random. Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: removing handle(0x000a), sas_addr(0x4433221102000000) Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: removing : enclosure logical id(0x500605b003cc0de0), slot(1) Sep 24 20:40:12 Vault kernel: sd 1:0:4:0: [sdf] Synchronizing SCSI cache Sep 24 20:40:12 Vault kernel: sd 1:0:4:0: [sdf] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: removing handle(0x000c), sas_addr(0x4433221104000000) Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: removing : enclosure logical id(0x500605b003cc0de0), slot(7) Sep 24 20:40:12 Vault kernel: sd 1:0:5:0: [sdg] Synchronizing SCSI cache Sep 24 20:40:12 Vault kernel: sd 1:0:5:0: [sdg] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: removing handle(0x000e), sas_addr(0x4433221105000000) Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: removing : enclosure logical id(0x500605b003cc0de0), slot(6) Sep 24 20:40:12 Vault kernel: md: disk0 write error, sector=1586782472 Sep 24 20:40:12 Vault kernel: md: disk29 write error, sector=1586782472 Sep 24 20:40:12 Vault kernel: sd 1:0:6:0: [sdh] Synchronizing SCSI cache Sep 24 20:40:12 Vault kernel: sd 1:0:6:0: [sdh] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP received, forcing refresh of disks info. Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: removing handle(0x000f), sas_addr(0x4433221106000000) Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: removing : enclosure logical id(0x500605b003cc0de0), slot(5) Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: sending diag reset !! Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP received, forcing refresh of disks info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault rc.diskinfo[10970]: SIGHUP ignored - already refreshing disk info. Sep 24 20:40:12 Vault kernel: mpt2sas_cm0: diag reset: FAILED Sep 24 20:40:13 Vault kernel: iommu: Removing device 0000:02:00.0 from group 1 Sep 24 20:40:35 Vault kernel: md: disk1 read error, sector=2930292224 Sep 24 20:40:35 Vault kernel: md: disk1 read error, sector=2930292232 Sep 24 20:40:35 Vault kernel: XFS (md1): metadata I/O error: block 0xaea8b607 ("xlog_iodone") error 5 numblks 64 Sep 24 20:40:35 Vault kernel: XFS (md1): xfs_do_force_shutdown(0x2) called from line 1232 of file fs/xfs/xfs_log.c. Return address = 0xffffffffa02cd5de Sep 24 20:40:35 Vault kernel: XFS (md1): Log I/O Error Detected. Shutting down filesystem Sep 24 20:40:35 Vault kernel: XFS (md1): Please umount the filesystem and rectify the problem(s)

Just crossed the two hour mark, though its hard to tell if changing the settings helped make it stable or it just was ok this reboot. Will see how it goes, but if anyone else on this forum knows what is causing this let me know.