ISSUE : Dynamix S3 Sleep (2016.06.19) not Sleeping when invoked from Array Operation tab.

UNRAID : 6.1.9 Plus

 

I checked my plugins for updates today and saw that the WebGUI, S3 Sleep and System Temperature were all wanting to be updated. After an update, I left the server running and we watched a movie. After we were done, I came back to the WebGUI - Main - Array Operation tab and clicked the Sleep button. The label for the button changed to "Sleeping..." but the server did not enter the sleep state. Fans were still running and the WebGUi still responded

 

The previous version of the plugin certainly worked as I have got used to the fans stopping and hearing the click of the PSU turning off.

 

I stopped, rebooted and restarted the server but there was no change in the behaviour of the sleep button.

 

My system spec in my forum sig is correct.

The S3-Sleep Button is broken in the new version - saw this yesterday too 

I fixed a regression error when s3-sleep plugin is used on a system running unRAID v6.1.9.

 

New version 2016.06.20 is available.

 

Perfect - I confirm that 2016.06.20 works as expected.

 

Cheers!

Yep! Working! Thanks for the fix 

I just installed the S3 Sleep plugin and enabled the Execute function to "Sleep" on the plugin settings page, but I still don't see the Sleep button on the Main/Array Operations tab.  What am I missing?

first off, a great thank you to bonienl for these wonderful suite of plug-ins. 

 

a few days ago i installed the SSD TRIM plug-in (i somehow managed to ignore it for quite a while, beside running other Dynamix plug-ins  ) and set it to fire at 8am every day. the very next day i checked the logs of unRAID to look for (maybe) any entries belonging to the plug-in. low and behold i found this one (removed private informations):

 

Jun 23 08:00:02 unRAID sSMTP[20482]: Creating SSL connection to host
Jun 23 08:00:02 unRAID sSMTP[20482]: SSL connection using XXXX
Jun 23 08:00:02 unRAID sSMTP[20482]: Authorization failed (535 5.7.8  https://support.google.com/mail/answer/14257 u64sm2150802wmd.8 - gsmtp)

 

ok, a bit confused (for a moment) – what has caused this? out of nowhere (and never before) something tried to send an email via google. the next second i remembered, ey i got the new plug-in installed – maybe it has any defaults to send reports automatically. checked the "Notification Settings" in unRAID, but they where like i had them set up: no eMail-Notifications, only in browser; no email-account informations in the "SMTP Settings" area.

 

so i went ahead and configured the "SMTP Settings" with my account informations (with different sending/receiving addresses). i verified the setup by using the "Test"-button and immediately received the test-email – all well i thought. and the very next day log-check showed this:

 

08:00:01 unRAID sSMTP[x]: RCPT TO:<[email protected]> (553 5.7.1 <[email protected]>: Sender address rejected: not owned by user email-account)

 

this error says that something (most probably the plug-in, because didn't happen before) tried to use the sender email-address "[email protected]" to send an email to the (correctly) specified "[email protected]"-address. but now, it correctly did try to use the google email-servers, instead it used the specified one. after re-checking all settings and test-sending emails from the "SMTP Settings" tab i came to the conclusion, that (maybe) the plug-in (or any used parts of unRAID for sending emails) has a hard coded sending email-address (root@) and ignores the specified one.

 

now, you could ask, why then not use the [email protected]. because of security concerns. this email-server checks the sending email-address against the provided email-account; and if it can't verify that it is allowed, it denies it, hence the error in the log.

 

 

wrap up: had no log entries up to now which are email related (and nothing configured for it) and just exactly one second after the (since then) newly installed SSD_TRIM plug-in fired, i'm pretty much confident, that it is caused by it. maybe some things play together here (functions of unRAID which are used for sending the actual email, or combinations of Dynamix plug-ins) but i think it can be fixed to work as expected.

 

sorry for the long post, but it (hopefully) helps much better to track down this bug.

 

greets,

oliver

@s.Oliver

 

Can you run the following from CLI:

 

/sbin/fstrim -v /mnt/cache

 

And see if this gives an error message?

@s.Oliver

 

Can you run the following from CLI:

 

/sbin/fstrim -v /mnt/cache

 

And see if this gives an error message?

 

yes, gives this error:

 

root@unRAID:~# /sbin/fstrim -v /mnt/cache
fstrim: /mnt/cache: FITRIM ioctl failed: Operation not supported

yes, gives this error:

 

root@unRAID:~# /sbin/fstrim -v /mnt/cache
fstrim: /mnt/cache: FITRIM ioctl failed: Operation not supported

 

First thing to check is if your SSD supports trim

 

# hdparm -I /dev/sdX | grep TRIM

      (X = reference to your cache disk)

 

Second question: is your disk directly connected to your motherboard or do you use an adapter?

 

 

 

yes, gives this error:

 

root@unRAID:~# /sbin/fstrim -v /mnt/cache
fstrim: /mnt/cache: FITRIM ioctl failed: Operation not supported

 

First thing to check is if your SSD supports trim

 

# hdparm -I /dev/sdX | grep TRIM

      (X = reference to your cache disk)

 

root@unRAID:~# hdparm -I /dev/sdb | grep TRIM
   *	Data Set Management TRIM supported (limit 8 blocks)

 

Second question: is your disk directly connected to your motherboard or do you use an adapter?

 

it is directly connected and does support trim (Samsung Evo 850).

 

thx. for looking into it. 

It is unclear to me why fstrim fails, but it is the cause of the email (when a cron job fails it results in an email sent).

 

Are you running version 6.2?

 

It is unclear to me why fstrim fails, but it is the cause of the email (when a cron job fails it results in an email sent).

 

Are you running version 6.2?

 

no, 6.1.9 as per signature.

but why is the cron job then ignoring the settings for smtp? it is using root@ instead of the setup email-address.

 

It is unclear to me why fstrim fails, but it is the cause of the email (when a cron job fails it results in an email sent).

 

Are you running version 6.2?

 

no, 6.1.9 as per signature.

but why is the cron job then ignoring the settings for smtp? it is using root@ instead of the setup email-address.

 

It's normal that email of cron job is sent by root. It is not attached to any user.

 

It's normal that email of cron job is sent by root. It is not attached to any user.

 

well, i know usually it is sent by sendmail. i thought, that unRAID uses it's own script or small proggy, which is sending out the email with regard to the settings in the "SMTP Settings". but, it seems we have two different use cases here: 1st for sending out only the specified in "Notification Settings" and 2nd for all system generated output.

 

strange in use case two is, that unRAID is already using all defined parameters of "SMTP Settings", but only replaces the sender address with the "root@"-part. in my opinion it seems to be a small step from here to using the specified "from" sending address.

>> bonienl

 

is it maybe because the cache device is using (the defaulted) BTRFS?

 

reading up a bit reveals, that BTRFS should support TRIM, but (might) dependent on used mount options.

maybe the only quick solution is to format the SSD with EXT4?

 

this page might shed some light on my issue:

https://kb.plesk.com/en/122080

 

using the command on the mountpoint of the cache drive "/mnt/cache" shows the exact same output (also for the discard_max_bytes).

 

 

 

>> bonienl

 

is it maybe because the cache device is using (the defaulted) BTRFS?

 

No, default BTRFS supports TRIM, you usually get that error when the controller doesn't support it, looks like you're virtualizing unRAID, so maybe that's the cause (if you're using the mb controller).

 

 

 

 

>> bonienl

 

is it maybe because the cache device is using (the defaulted) BTRFS?

 

No, default BTRFS supports TRIM, you usually get that error when the controller doesn't support it, looks like you're virtualizing unRAID, so maybe that's the cause (if you're using the mb controller).

 

you're right, i do virtualize unRAID, in that hardware controllers are passthrough completely to unRAID. all (to me) known/used hardware features (esp. such as sleep function of hdd) do work properly. even all operations, which do change the boot usb-stick – so no tricks used/necessary here. the SSD is on the same controller (SAS3 from MB) as other HDDs.

 

not an TRIM expert here, but my reading showed, that they use the fstrim command on mountpoints of filesystems and not on devices directly. well, i tried that too, but same result.

 

 

>> bonienl

 

is it maybe because the cache device is using (the defaulted) BTRFS?

 

No, default BTRFS supports TRIM, you usually get that error when the controller doesn't support it, looks like you're virtualizing unRAID, so maybe that's the cause (if you're using the mb controller).

 

you're right, i do virtualize unRAID, in that hardware controllers are passthrough completely to unRAID. all (to me) known/used hardware features (esp. such as sleep function of hdd) do work properly. even all operations, which do change the boot usb-stick – so no tricks used/necessary here. the SSD is on the same controller (SAS3 from MB) as other HDDs.

 

not an TRIM expert here, but my reading showed, that they use the fstrim command on mountpoints of filesystems and not on devices directly. well, i tried that too, but same result.

Is the  SAS3 controller from intel PCH or other, like LSI, some LSI controllers don't support trim, e.g., 9211.

 

 

 

the SSD is on the same controller (SAS3 from MB) as other HDDs.

 

Looking at your mb manual this is the problem, SAS3 is onboard LSI, when we say onboard controller we mean the PCH ports, connect the SSD to one of those and trim should work.

 

 

 

 

the SSD is on the same controller (SAS3 from MB) as other HDDs.

 

Looking at your mb manual this is the problem, SAS3 is onboard LSI, when we say onboard controller we mean the PCH ports, connect the SSD to one of those and trim should work.

 

just wanted to post back, that the SSD is connected to the LSI Logic SAS3008 chip – but you beat me

well, i've choosen the faster SAS3 ports and usually passthrough of 3rd party controllers is easier than the MB-ports. well, i'll probably need to reconsider how to utilize all ports of the board. i've passthrough'ed another LSI Logic SAS2008 pci card to unRAID as well. but it seems then same game for these LSI controllers.

I don't believe the normal EVO 850 supports the required TRIM commands, you need a PRO drive... The 840 PRO is commonly used.

I don't believe the normal EVO 850 supports the required TRIM commands, you need a PRO drive... The 840 PRO is commonly used.

 

The 850 EVO supports TRIM.

It does indeed support TRIM, however, I don't believe it's supported by LSI, as it doesn't support the correct command. At least I had to replace mine with a PRO (which works fine).

 

I believe it doesn't support deterministic read after trim / read zero after trim.

 

http://www.win-raid.com/t1366f25-Nightmare-to-find-a-SSD-with-functional-TRIM-on-LSI-SAS.html

well, well, i'll most probably rearrange my drives, so in the end the samsung will end up on a sata port of the MB.

so it's then not connected any longer to the LSI and probably TRIM will then work.