On 04/11/12 17:13, Michael Davies wrote:
...
> I attach at the bottom of this e-mail my dmesg output for my relatively
> simple platform for the NAS (I knowwwwww, it's a waste of an excellent
> OS! But I am after the security):
not at all. Its a fine general purpose OS, too. :)
...
> However, I have been trying to find out how OpenBSD handles ACPI/APM
> Power Management and disk hibernation.
>
> I have read quite a bit:
> 1) Michael Lucas' Absolute OpenBSD (2004)
> 2) Secure Architectures with OpenBSD (2004)
> 3) Michael Lucas' Absolute BSD (for FreeBSD) (2002)
> 4) Calomel - you know the one
> 5) I've tried to search the archived dialogues on Old Nabble (Difficult)
> 6) I've searched Daemon Forums
> 7) I've read the FAQ - Always the last place I look ;-)
I could take exception to that. :)
> This is what I feel I have learned:
>
> 1) Advanced Power Management on OpenBSD is handled by apmd. I know that
> because enabling it through /etc/rc.conf, rebooting and then issuing zzz
> puts the PC to sleep. When I tap a key - it wakes up again (exactly
> where I left it). GREAT!
Nifty, eh? :)
> 2) apmd does not automatically hibernate my disk (unless I am missing
> something) - but it is possible that there are ports (I've read about
> these for FreeBSD) which might handle disk hibernation: spindown and
> diskidle
Haven't seen a whole lot of interest in disk hibernation on OpenBSD.
> 3) I read somewhere that there is a danger in suspending/hibernating the
> disk security wise - but haven't found a full explanation (Is RAM dumped
> to disk unencrypted, perhaps?). That would explain why a program to
> hibernate the disk isn't included in the default install of OpenBSD.
I can't think of any security issue on putting a system to SLEEP, but a
full suspend-to-disk could kinda leave your secrets out in the open for
off-line examination if done unencrypted. If done encrypted...where do
you put the key? If on the disk, no gain. If you have to type it in on
power-up, other problems.
Some DISKS supposedly don't like too many power-up/power-down cycles.
...
> 1) Beyond apmd, is there a default handler of disk hibernation
> install-ed/able via default OpenBSD?
disk hibernation... I'm assuming you mean, "disk stops spinning until
the OS (which is running normally) calls for it". if this is REALLY
what you want (keep reading), I don't think OpenBSD can help you.
> 2) To use apmd, do I need to maintain a swap partition? Indeed, should I
> ALWAYS maintain a swap partition on this simple setup (which is running
> fine)? I was hoping to get away without one (currently b: is undefined).
Swap partition is optional, as long as you have enough RAM to do what
you want. If you are short one byte, you are in trouble, but with 4G
RAM, you got a lot.
> 3) If spindown or diskidle exist in the packages/ports - would
> installing these provide me with a disk hibernation facility for OpenBSD?
You MAY be able to do something along these lines with a CF or USB flash
disk as your OS drive, then using "atactl(8)" to power up and down the
disk after unmounting/mounting the file system. How you decide "My
windows machine has just made a request via SMB for a file, I had best
power up the disk and get it", I have no idea. HOWEVER, might be useful
for off-line backups, where you can say, "I am starting a backup process
now (spin up, mount). ... I'm done now (dismount, spin down)."
> 4) Is there another way to manage the PC('NAS') using OpenBSD to
> minimize power while the 'NAS' is available 24/7?
I'm not sure how much I'd like "sleeping" a NAS. Ok, disk goes to
sleep, then something requests a file. *PAUSE* Not so bad when it is
your local computer where the OS can realize, "I'm waking the disk, be
patient"...over the wire, you just get dead air. Sleeping the whole
machine? yikes. how would it wake up?
> All you savvy peeps who know where I am going on this - what's my best
> case scenario?
>
> An OpenBSD NAS which doesn't hibernate (Thinks... "Where can I get a
> 100W PSU?") or can I possibly achieve a NAS that hibernates the drive
> and "Wake(s) on LAN"?
"Wake on LAN" is a special signal to power-up a device. It isn't a "oh,
I got a request...lemme fire up now" thing. Devices being served by a
NAS don't normally send Wake On LAN signals.
>
> I'd settle for simply hibernating the disk (That's about 22W there -
> half the power draw) - but if the full monty is possible - I'll keep on
> digging.
um. no.
that particular disk is rated at 2.2W on seek, 2.0W on read/write, and
0.25w on standby. The only way to get 22W is the power-on max draw
spin-up, which will last probably two seconds, at most (probably more
like a fraction of a second at that kind of draw). Think about it for a
moment..go find 25W electric lightbulb. Leave it on for five minutes.
Touch it. Go put some ice on your burned fingers. Watts are Watts.
that's how hot your drive would get if it were drawing 22w non-stop.
The MOST you will save by powering down your little laptop disk is about
2W. Realistically, it will be less than that, as your power supply
probably won't pass all the power savings on to your wall.
(again for reference, I have here on my desk an old SCSI server disk,
very fast (for its day), and its maximum steady-state power draw is 17W.
A more modern 1TB 3.5" SATA disk is rated at 10W.)
For reference, I have a little PIII system here I'm making into a
firewall for a friend who is tired of her cheap router, and it just
happens to be attached to a Wattmeter. After OpenBSD is booted, it
idles at 34W power draw. It has a traditional 3.5" 80G HD in it, a
second NIC on a "switch-card" (nic+four external switch ports).
If while the system is running (idle), I unplug the hard disk, the 34W
power consumption goes all the way down to... 29W. Now, my wattmeter
was designed for things like refrigerators and big appliances, it has a
1W resolution, so assume the 34W is "almost 35" and the 29W is "almost
28"...so we are saving at the most 7W of power on full-size stuff.
(note: repeating this experiment on critical systems is not
recommended...OpenBSD really is not at all fond of its only disk being
powered down like that...and the system promptly crashes, even if the
disk is plugged back in).
> dmesg details follow this EXTREMELY LONG FIRST POST. Thanks for YOUR
> patience, y'all ;-)
>
> Mike
>
> P.S. Anybody know why there is an RTC BIOS error 80 for the clock
> battery (See below)? Brand New board, this one.
yeah, a lot of machines are doing that now. Don't sweat it.
> P.P.S. The i386 32-bit version 5.0 works on this MB too - but I haven't
> attached the DMESG for that...
>
> **************************************************************************************************************************************
> MY DMESG
> **************************************************************************************************************************************
snipped for message size, but thanks. :)
Nick.
