smart scheduled tests problem

  • @tkaiser thanks for giving me direction, I found your btrfs tutorial. btrfs is a new subject to me and sounds like exactly what I need.

    JMicron provided yesterday a new firmware upgrade for JMS578 (see link to ODROID forum) which should solve both serial number and SAT issues. Please test and report back!

  • @tkaiser thanks for firmware update information. That completely solved 4TB drives issue. All four 4TB hdds now have unique ID_SERIAL_SHORT and OMV S.M.A.R.T. test scheduler identifies these drives correctly as individual hdds.


    There is still a problem with 1TB drives which use different Orico USB-to-SATA bridges. I was unable to update firmware on them. To avoid confusion 4TB and 1TB drives use Orico 27UTS and 2599US3 converters. 27UTS is upgradabe by JMS578 new firmware while 2599US3 is not. I'm not too concerned about that because 2599US3 will never be connected permanently to the Odroid. Both 2599US3 converters show the same ID_SERIAL_SHORT=0123456789ABCDE. Is there any way to find out what hardware does 2599US3 use? I will not be surprised if it is JMicron based too.

  • Is there any way to find out what hardware does 2599US3 use?

    Sure, connect them and do an 'lsusb' to get device and product ID. I wouldn't be surprised if they're based on Norelsys NS106x (crappy chipsets -- claims to be UAS compatible but aren't. Therefore UAS blacklisted on the Armbian based OMV images).


    I bought two ORICO USB-to-SATA adapters this summer that were advertised as JMS578 based while in reality using Norelsys NS1068. :(

  • It is Norelsys ID 2537:1066. I'll have to buy a replacement.

    For spinning rust it's ok as long as UAS is blacklisted (check with 'lsusb -t'). As already mentioned Armbian (and all the Armbian based OMV images therefore too) in the meantime contains an UAS blacklisting mechanism trying to take care of those two Norelsys chipsets and any external Seagate and WD disk enclosures since almost all of them are somewhat broken wrt UAS.


    The performance drop when blacklisting UAS with HDDs is more or less negligible (just a few percent difference with both sequential and random IO numbers -- with SSDs it's a totally different story though) so all you have to take care of with these enclosures is to ensure UAS is disabled for them (I donated one of my two 1068 SATA bridges to current UAS kernel maintainer back in August but so far nothing happened and they did not appear in drivers/usb/storage/unusual_uas.h so far)


    Only good news: automatically UAS blacklisting all Seagate disk enclosures might not be necessary any more with future kernel versions.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!