On 5/3/2012 6:54 PM, Bill Cole wrote: ... > For many of these systems, > the OS resides on a mirrored pair of local disks which see very > infrequent writes because every filesystem with significant flux is > physically resident across the SAN. Spinning disks draw power. Anything > drawing power generates heat. Heat requires cooling. Cooling typically > requires more power than the devices it is compensating for. Cooling > also requires careful attention to the details of physical server > density and rack design and so on...
This could be completely resolved by PXE/bootp and NFS mounted root filesystems, and save you $200-500/node in disk drive costs after spending $1000-2000 for the NFS server hardware, or nothing using a VM server. It would also save you substantial admin time by using templates for new node deployments. This diskless node methodology has been around for ~30 years. > A local mail submission and trivial outbound transport subsystem is a > normal feature of any Unix-like machine. To operate robustly, it needs a > queueing and retry mechanism. It is helpful for environments with power > and cooling concerns if a mechanical disk (or worse: a mirrored pair of > disks) isn't forced to spin up every time that mechanism activates. > Every little wattage savings is useful, and avoiding truly pointless > disk writes is never a bad thing. SSD is a perfect solution here, in cases of non netboot machines. And right now small SSDs are less expensive than their rusty disk counterparts. If one is truly concerned about spurious spin ups eating power and generating heat, I would think one would not go after the software stack in a piecemeal fashion to solve the problem. The MTA isn't the only software waking the disk. The kernel will write logs far more often in many/most situations. > Well, beyond the data center environment there is also a very widespread > deployment of Postfix as the legacy mail subsystem on MacOS personal > machines, where the mail flow is typically extremely low. ... > Ultimately the result is having to choose > between power management and timely delivery. If the periodic wakeups > didn't force a disk write, it would be less onerous to let master run in > its normal persistent mode for a lot of Postfix users (many of whom may > not even be aware that they are Postfix users.) This is only true if two things persist into the future: 1. Postfix isn't modified in order to perform a power management role 2. Laptops will forever have spinning rust storage Addressing the first point, should it be the responsibility of application software to directly address power management concerns? Or should this be left to the OS and hardware platform/BIOS? Addressing the 2nd, within a few years all new laptops will ship with SSD instead of SRD specifically to address battery run time issues. Many are shipping now with SSDs. All netbooks already do, smart phones use other flash types. > Whether it is actually worthwhile to make a change that is only > significant for people who are barely using Postfix isn't a judgment I > can make. It's obvious that Dr. Venema takes significantly more care > with his code than I can really relate to, so I don't really know what > effort a conceptually small change in Postfix really entails. Wietse will make his own decisions as he always has. I'm simply making the point that issues such as power/cooling, wake/sleep, etc should be addressed at the hardware platform/OS level, or system or network architecture level, at the application level, especially if the effort to implement it is more than trivial. This is especially true when any such coding effort may only produce very short term gains, as these issues are already being addressed and will be completely resolved by other means (SSD) in the near future, or have already been resolved by 30 year old technology/architecture methods (netboot/NFS), depending on the platform scenario. -- Stan
