Native S3 Sleep Support

[reggierat]

this is a big one for me and would like to see this as a standard feature for Unraid.  I love that my server puts itself to sleep after a period of no activity and all my devices around the house can wake it up when required

[josywong]

+1

[SlrG]

+1

[aspik]

+1! 

 

For me it is also very important, I know for many of you it is any unnecessary feature, because your running the server 24x7, but if unRAID will compete with the commerce NAS Vendors like qnap or synology it should also natively support S3 (in my opinion).

I've already asked, why it is not officially supported and been told that's the reason for that are various hardware dependencies, but I think with a modern hardware it isn't a problem anymore, or knows some of you a motherboard, which doesn't support S3?

[garycase]

The issue with s3 support isn't generally the motherboard -- it's the add-in cards, many of which still have issues with not "waking up" properly.    In addition, as many systems are now used to run multiple machines via a hypervisor, you need communications between all of the running systems to ensure a system isn't put to sleep while one of the VM's is actively executing a task.

 

But I agree that native support would be good -- and for those systems that are used as a pure NAS with all drives connected to motherboard ports there shouldn't be any issues in doing so.

 

[bonzi]

One of the biggest problem cards is the supermicro saslp-mv8 which does not support suspend. I have often seen people cite this as their main problem with suspend. I don't know if this solution will work under unraid but in ubuntu I can unmount the disks and unload the modules before suspend, then reload them and remount on resume. Like this:

 

/etc/pm/sleep.d/00disks

 

#!/bin/sh

case $1 in
    hibernate|suspend)
        if mount | grep /media/storage > /dev/null; then 
            umount /media/storage
            sleep 5
        fi
        if mount | grep /mnt/disk1 > /dev/null; then
        umount /mnt/disk1
        fi
        if mount | grep /mnt/disk2 > /dev/null; then
        umount /mnt/disk2
        fi
        if mount | grep /mnt/disk3 > /dev/null; then
        umount /mnt/disk3
        fi
        if mount | grep /mnt/disk4 > /dev/null; then
        umount /mnt/disk4
        fi
        if mount | grep /mnt/disk5 > /dev/null; then
        umount /mnt/disk5
        fi
        if mount | grep /media/Audio > /dev/null; then
        umount /media/Audio
        fi
        if mount | grep /media/Backup > /dev/null; then
        umount /media/Backup
        fi
        if mount | grep /media/cache > /dev/null; then
        umount /media/cache
        fi
        if mount | grep /media/Documents > /dev/null; then
        umount /media/Documents
        fi
        if mount | grep /media/flash > /dev/null; then
        umount /media/flash
        fi
        if mount | grep /media/Pictures > /dev/null; then
        umount /media/Pictures
        fi
        if mount | grep /media/Video > /dev/null; then
        umount /media/Video
        fi
        if mount | grep /media/ubuntu > /dev/null; then
        umount /media/ubuntu
        fi
    ;;
    thaw|resume)
        mount -a
        sleep 5
        mount -t aufs -o br:/mnt/disk3=rw:/mnt/disk4=rw:/mnt/disk5=rw,sum,create=mfs none /media/storage
    ;;
    *) exit $NA
    ;;
esac

 

/etc/pm/config.d/modules

 

SUSPEND_MODULES="mv_sas libsas scsi_transport_sas"

 

This works 100% of the time in ubuntu, would be interested if someone could try in unraid. I suspect it would be necessary to install pm-utils...

[Julian0o]

+1

[TSM]

I've got one of those supermicro cards.  Every since upgrading to the 6 betas I've had weird problems with the server not waking back up after the drives have spun down.  And then have to hard boot it for it to be functional again.  For the past 8 days I have had the drives set to never spin down, and I've had no problems.  Is the supermicro card the the reason why maybe?

[hellboy]

+10 

[NAS]

The only way this can be native and supported (as in it just works) is for their to be an whitelist of hardware that is supported. Personally I think this is a bad precedent to have. Given this IMHO it should not be natively officially supported but rather continue to be community driven but with more Limetech support.

 

Otherwise all we are going to see is a bunch of unhappy people for which it breaks leading to the inevitable bad PR that goes with it.