On Mon, 2006 Jul 31 13:47:21 -0300, Henrique de Moraes Holschuh wrote: > > > > Define "(un)suitable for UPS management." Does this definition include > > most people's desktop systems? > > Suitable for UPS management: > Load: > Powers up when AC returns > Can be informed that it must shutdown by the UPS > (through NUT).
Okay, so pretty much anything that can run NUT. Nice. > UPS: > Does delayed load shutdown upon shutdown command > Does not power up the load before it has enough charge > to do a delayed shutdown, plus safety margin. Pretty basic stuff, yes. > Always power-cycles the load after a shutdown command is > ACK'ed to the controlling host. Even if AC > returns, and it doesn't need to shutdown anymore. Many low-end UPSes fail here. Power races would be an academic issue if not for this. > Communicates the host when battery charge is below a > certain threshold, so that it can shutdown safely. > Powers up the load if the batteries have enough charge, > and an AC cycle happens while the load is offline. > Powers up the load after a timer expires, if no AC cycles > happen AND the load was broght offline by an explicit > delayed shutdown command. > > Anything else is unsuitable. Hi, I'm Bob, and I have an unsuitable UPS. Can I use it with Debian? > Any PC97 desktop should be suitable for proper UPS management. And just > FYI, PC97 requires WoL on all ethernet devices, not that you need WoL for > a proper UPS setup, but you somehow got the idea that WoL was a > server-grade feature... Fair enough, but a UPS with an Ethernet port (and a means of configuring WoL) certainly is. If not in purpose, then in price. > > No, but any decent power supply will present a load pretty close to it, > > Only ones with PFC. Decent power supplies have PFC. > > number of machines connected, but large numbers of machines connected are > > not exactly a typical scenario. > > No, but your hard-drive doing emergency unloads is a typical scenario, and > desktop HDs don't like those unloads *at* *all*. Do not do it (and as I > already said, the only proper way to know the HD heads are unloaded requires > kernel cooperation, and it is NOT done by userspace currently). > > I know you were under the mistaken impression that we could guarantee all > HD heads were unloaded in userspace, and before halt runs. We not only > cannot do it, we also do not *attempt* to do it. The only thing in Debian > initscripts that really tries to take care of HD head unloads is the halt > command. > > You can, of course, try to make sure hdparm was run and actually uloaded all > heads for your particular configuration, but it is not an acceptable > default, because we cannot get it right every time. So implement it as an > admin-enabled, admin-configured option by all means. But *not* as a > default. Perhaps the sleep-then-reboot loop belongs inside the halt command, then. At some point, there's going to be little difference between cutting power to the PSU, and having the PSU do a soft poweroff. > > need to. What more shutdown magic do you need on a hard disk that is not > > spinning? > > None. If the disk spun down, but hdparm doesn't work for all disks. And we > cannot reliably spin down all disks and uload heads from userspace, for all > possible configurations. Thus, anything that relies on this cannot be made > a default. > > > If you're talking about a flaky hardware RAID array where you can't stop > > SCSI plus all software RAID arrays. I mean _after_ mdadm is stopped. Not that any distinction is currently made between RAID setups, flaky or otherwise. > The bad thing in your patch is that the maintainer made it non-optional, and > the default. I understand it will not be a default anymore, which is enough > for me. I agree that having it non-optional is undesirable. > > You: Do a normal system shutdown. Rely on server-grade features (e.g. WOL > > No. Me: make the whole behaviour you want *optional*, and not the default, > because it is dangerous and we don't have a lick of a chance of making it > safe for all setups. > > packet from a networked UPS) to resume operation, or an "On/Off state: ON" > > No. Rely on standard PC97 ACPI desktop BIOS option "always power on on AC > return", which is the correct way to deal with machines that need to restart > when an UPS powers it up again. Correct? The PC will then always turn on when the AC returns, e.g. when being plugged in, or after a power outage when it was off to begin with. The PSU's hard power switch isn't a solution, either, as it is often inconvenient/inaccessible and many newer consumer PSUs don't even have one. The real solution is to have an on/off state bit that can be frobbed by the OS, but I'm not holding my breath on that one. > > BIOS setting (despite the problems associated with that). Have this be the > > default, as the risk of data loss from fragile storage media trumps that of > > system unavailability after an extended outage. > > No. This is a local decision done by a local admin. It cannot be a default > setting for Debian. The Debian default must be the *safest* choice we have. It's the fsck-versus-fsck-y-on-boot debate all over again.... > > Mr. Quette will have to decide this, but I don't think you've made a strong > > case for a power-cut being significantly detrimental to data or hardware. > > I have not seen you make a case at all for a *default* behaviour. You don't > need it to be default, you just need it to exist. My case for the default is based on the notion that most people will be running standard systems without all the weirdness you're worried about, *and* that the danger you're positing is no worse than any other misconfiguration of NUT that causes a shutdown not to occur. If someone with a large, fragile RAID installs NUT, doesn't review the configuration, and expects his data to survive... well, then, what can you expect? We're talking about cutting power here, not twiddling partition tables. Anyway, I care more about having the option, than having it be the default. > It has been at least five years since I've last seen a desktop PC that is > incapable of "always power on", with the exception of some laptops. I am > not buying your assertion that most desktop PCs cannot do it properly, but > even if this were true, it would still be a dangerous, unacceptable default > behaviour for NUT to do what you proposed. PCs can do "always power on" just fine; the problem is that "always" really does mean "always." The behavior is not reasonable. --Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
