September 22, 201411 yr 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
September 22, 201411 yr +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?
September 22, 201411 yr 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.
September 23, 201411 yr 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...
October 12, 201411 yr 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?
November 10, 201411 yr 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.
Archived
This topic is now archived and is closed to further replies.