10 hours ago, TDD said:

Seagate Ironwolf parity drive under RC2.

There have been multiple users with issues with the 8TB Ironwof + LSI, for now best to stick with v6.8.3 or connect those disks to a non LSI controller.

Any issues with the Ironwolf/LSI combo are software *only* since it does work fine under the old kernel/driver.  I'm hopeful that from my reading and testing, disabling some of the aggressive power saving modes of the Ironwolf may cover up any faults currently in the driver that will need to be addressed. 

 

No matter what, kudos to Seagate (I have all WD drives BTW!) for having tools and documentation to tweak the settings.  WD could learn a lot here - but admittedly my WD drives always 'just worked' without any tweaks...

19 minutes ago, JorgeB said:

8TB Ironwof + LSI,

Hi JorgeB, 

 

I found this article which points to firmware on the 10Tb Ironwolfs. Post also says people having issues with 8s also but not sure if there is new firmware for 8s. May not be related but maybe worth a look?

 

Finally a solution?:
Now the point of this topic, digging deeper it turns out Seagate released a firmware update for the ST10000VN0004 and ST10000NE0004 last month. They bumped from firmware SC60 to SC61 and in that topic it's stated that this is because of "flush cache timing out bug that was discovered during routine testing" in regards to Synology systems.

As it turns out, write cache (and I believe internally NCQ) had been turned off for these specific drives in Synology systems for a while now because of "stability" issues. Since this firmware update it gets turned on again and all is well.

That got me thinking, if a Synology is having this issue, maybe this was more disk firmware related then anything else. So, since I still have all my data on other drivers anyway I went ahead and flashed all my 8x ST10000VN0004 from SC60 to SC61. This worked without a problem and even a ZFS Scrub found no issues with the data still on there.

But... I was able to finish a scrub twice of 20TB on the pool now without a single read, write or CRC error. I've been hitting the drive with TBs of DD and Bonnie++ and not a single error anymore. So this might actually be a fix for topics like this one I found and this one.

 

https://www.truenas.com/community/threads/seagate-ironwolf-10tb-st10000vn0004-vs-lsi-it-firmware-controllers.78772/

Edited March 7, 20215 yr by SimonF

I did check for revised firmware past my SC60. Nothing available.

 

This particular issue seems to be limited to the older 10TB drives.  If it is a bug in the 8TBs, they are certainly dragging their feet on a fix.

15 minutes ago, TDD said:

I did check for revised firmware past my SC60. Nothing available.

 

This particular issue seems to be limited to the older 10TB drives.  If it is a bug in the 8TBs, they are certainly dragging their feet on a fix.

Found this post from Jun 2020, so maybe worth checking again? 

 

Just to put a full stop to this for my issues. I engaged with Seagate tech support and they supplied me with another firmware for my ST8000VN004 8TB drives. Good news - I could enable NCQ again and not have any issues with SMART Command_Timeout accumulation, and I could do a full Nakivo backups verification, plus ZFS scrub and not have any issues. So I consider this issue resolved.

I used the Seagate utility to boot from a USB stick to update the drives. Thankfully it worked with the LSI RAID card, so that I didn't have to tediously transpose the drives into another caddy to put into a Windows server to run. The weird thing is that the "new" firmware still says SC60 and not SC61. You'd think they'd at least give it an engineering code like SC60e or something or even SE60. Anyways - there's other IT challenges to tackle. Finally I can put this hard drive madness to rest! (touch wood).

@limetech Could this be parameterized in disk settings, as non rotational devices do have power saving options. I know most people may not need that feature as running for VMs etc, but I think it should be an option for people that may use it. i.e not running docker/VMs 

Anybody know when multiple Array Pools will be available ?

 

Thanks 

26 minutes ago, Gdtech said:

Anybody know when multiple Array Pools will be available ?

Not super clear.

 

Multiple Pools are available as per the release notes.

Multiple Arrays is not available.

 

You can use several Pools in conjunction with the Array to act as Cache. You can choose which pool to use for each Share.

On 3/2/2021 at 12:11 AM, takkkkkkk said:

Does this resolve the issue with BTRFS's performance issue?

 

Also interested in this, I did not see this addressed in searching this thread?

9 minutes ago, TexasUnraid said:

Also interested in this, I did not see this addressed in searching this thread?

 

According to phoronix it was fixed in kernel 5.10.8.

6 minutes ago, John_M said:

 

According to phoronix it was fixed in kernel 5.10.8.

Great, thanks, just what I was waiting for to upgrade. Guess I will add upgrading to me todo list.

Update to 6.9 was successful, but automatic spindown is not working anymore

Thanks for 6.9. Excited about what to come in 7.0.

 

6.9 working fine, except cache performance. Current performance:

 

Raid 1:

500-600 MB/s in user path, about 2000 MB/s outside user path. No difference Raid 1 to Raid 10. 

 

The performance outside user path is fine enough, strange with no performance gain with Raid 10. 

 

Should the "user path" reduce performance by 3/4?

 

After upgraded to 6.9 yje cache has be formatted/rebuild/permissions/restarted.

 

10 hours ago, SimonF said:

Found this post from Jun 2020, so maybe worth checking again? 

 

Just to put a full stop to this for my issues. I engaged with Seagate tech support and they supplied me with another firmware for my ST8000VN004 8TB drives. Good news - I could enable NCQ again and not have any issues with SMART Command_Timeout accumulation, and I could do a full Nakivo backups verification, plus ZFS scrub and not have any issues. So I consider this issue resolved.

I used the Seagate utility to boot from a USB stick to update the drives. Thankfully it worked with the LSI RAID card, so that I didn't have to tediously transpose the drives into another caddy to put into a Windows server to run. The weird thing is that the "new" firmware still says SC60 and not SC61. You'd think they'd at least give it an engineering code like SC60e or something or even SE60. Anyways - there's other IT challenges to tackle. Finally I can put this hard drive madness to rest! (touch wood).

I upgraded from 6.8.3 to 6.9.0 without issue.

 

I have 10TB segate ironwolf pros (firmware EN01) and 8TB ironwolf's (SC61) - all on a LSI controller with NCQ on.

 

The 8TB's had about 2 years on a ZFS system as a mirror also without issues before I moved them to the unraid system. 

 

Edited March 7, 20215 yr by rilles

My 8TB is a very recent manufacture (a VN004) and has the SC60 firmware.  Is yours the slightly older VN0022?  That would explain the SC61.

 

I haven't seen any update for the VN004 as of yet.

17 minutes ago, TDD said:

My 8TB is a very recent manufacture (a VN004) and has the SC60 firmware.  Is yours the slightly older VN0022?  That would explain the SC61.

 

I haven't seen any update for the VN004 as of yet.

ST8000VN0022

 

not sure why a newer drive would have an older version of firmware.

 

Upgraded from 6.8.3 to 6.9 with no issues - thank you very much! The upgrade resolved an issue where disk temperature settings made under 'Settings/Disk settings' did not get applied to some disks when viewing them under 'Main'.

Upgrade to 6.9.0 did not go well for me. no drives visible.

 

Based on other people with the same issue the drivers in 6.9.0 do not work with Netapp SAS 4-Port 3/6 GB QSFP PCIE 111-00341+B0 Controller (PMC Sierra PM8003).

 

Peter.

 

@limetech Just an update to the issue with disk usage thresholds - my media unRAID system has been 'corrected'. As mentioned previously, it was showing all disks as 'returned to normal utilization' and showing as 'green' after the upgrade to 6.9.0. As per the release notes, I tried numerous times to reset my thresholds in Disk Settings, along with a few reboots. Nothing had corrected it.

 

After I was sure other aspects were working OK, I proceeded to add the 2 x 16TB new disks to the array. After the array started and the disks were formatted, disk utilization has now returned to using the proper colors. The 2 new disks are both green as they're empty, and the rest are accurately showing as red as I let them fill as completely as possible.

 

Note that the preclear signature was valid even though the disks may not have fully completed the post-read process due to my previously reported USB disconnection error with the unRAID flash drive. I know they passed the pre-read and zero 100% successfully, so I just took the chance on adding them to the array, expecting that unRAID might need to run its own clear process but that wasn't the case.

 

Note that my backup unRAID which was upgraded from 6.8.3 to 6.9.0 still shows the incorrect colors for disk utilization thresholds. I'll be adding/replacing some disks on it next month, so I'll watch to see if it also corrects this utilization threshold issue.

 

Alas I've now got another potential issue.... sigh.

 

Before adding the new drives I shut down all active VMs and Docker containers and then attempted to stop the array. This hung up the system reporting  'retry unmounting user shares' at the bottom left corner of the unRAID webgui. I then grabbed diagnostics and attempted a reboot, which it did. But upon restart, the system has again reported an unclean shutdown even though the reboot itself showed no errors on the monitor directly attached to the unRAID system.

 

This is the 3rd time since the upgrade to 6.9.0 that the system has reported an unclean shutdown. On all 3 occasions I've been able to watch the console output on the monitor directly attached to the unRAID system, with no noticeable errors during the reboot. On the 1st occasion (immediately after the upgrade from 6.9.0 RC2), I did an immediate reboot and that cleared the need for a parity check.

 

The 2nd unclean shutdown was reported after another apparently clean reboot on Mar 2nd. On this 2nd occasion I let unRAID proceed with the parity check and it completed with 0 errors found. I'm letting it proceed again with this most recent 'unclean shutdown' error, but I suspect it's a false warning and no errors will be found.

 

I've got the diagnostics created just before adding the 2 new drives, and also a diagnostic grab just a few moments ago. I can provide them if you wish, but prefer directly through PM. Let me know if you have any questions or want the diagnostics, but hopefully these 'unclean shutdowns' are just a small quirk with the stable 6.9.0 release.

 

Edited March 8, 20215 yr by AgentXXL
Clarify + re-wording; add statement about backup unRAID

Have you made sure that you do not have a console (or screen) session open with the current directory being one on the array as this will stop the array completing the unmounting correctly and thus can lead to a subsequent unclean shutdown.

 

 

5 hours ago, AgentXXL said:

The 2nd unclean shutdown was reported after another apparently clean reboot

There have been a couple of reports where it looks like the shutdown time-out is not being honored, i.e., Unraid considers an unclean shutdown after a couple of seconds even if the set time is much longer, changing the setting (Settings -> Disk Settings) to re-apply it fixed it.

15 hours ago, rilles said:

ST8000VN0022

Only model affected appears to be the ST8000VN004.

On 3/7/2021 at 8:56 AM, h0schi said:

Update to 6.9 was successful, but automatic spindown is not working anymore

 

I'm not an expert, but people have said the Dynamix Autofan plugin or Telegraf docker are culprits. For me, disabling [inputs.smart] in Telegraf fixed it as was suggested earlier in this thread.

 

Edit: Here's the relevant bug report:

 

Edited March 8, 20215 yr by mudsloth

16 minutes ago, mudsloth said:

 

I'm not an expert, but people have said the Dynamix Autofan plugin or Telegraf docker are culprits. For me, disabling [inputs.smart] in Telegraf fixed it as was suggested earlier in this thread.

 

Edit: Here's the relevant bug report:

 

Thx @mudsloth.

I do not use AutoFan or Telegraf.

I solved it yesterday with increasing the increasing the "Tunable (poll_attributes)" under Settings -> Disk Settings.

 

I set the spindown to 1 hour and increase the Tunable (poll_attributes) to 3700 seconds

7 hours ago, itimpi said:

Have you made sure that you do not have a console (or screen) session open with the current directory being one on the array as this will stop the array completing the unmounting correctly and thus can lead to a subsequent unclean shutdown.

 

I assume that reply was meant for me, but yes, I had closed all open console sessions, and even took the pro-active step of shutting down Docker containers manually before attempting the reboots. As I've got the pre and post diagnostics for this latest occurrance, I'll start doing some comparison today.

 

I just find it odd that I've experienced 3 supposed unclean shutdowns since the upgrade to 6.9.0 stable. I had rebooted numerous times while using 6.9.0 RC2 but don't recall a single unclean shutdown occurring. And as reported, I believe they're completely false errors as all of my parity checks in the last year have passed with no errors found. When I 1st started with unRAID in 2019 using my original storage chassis (an old Norco RPC-4020) I had numerous actual errors, but not a single one since I've moved to the Supermicro CSE-847.