Am 22.02.2012 um 22:48 schrieb Joe Greco:

You also don't have to buy a MMS; the lower end Mac mini's are also plenty powerful, can be upgraded similarly, but lack OS X Server and the quad core CPU.

With 10.7, Server is now a $50 add-on download from the Mac App Store, no special hardware required. Stefan -- Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811

On 22 Feb 2012, at 22:04, "Stefan Bethke" <stb@lassitu.de> wrote:

Am 22.02.2012 um 22:48 schrieb Joe Greco:

...

You also don't have to buy a MMS; the lower end Mac mini's are also plenty powerful, can be upgraded similarly, but lack OS X Server and the quad core CPU.

With 10.7, Server is now a $50 add-on download from the Mac App Store, no special hardware required.

You dudes need to get with the times and put all this stuff in the cloud. Ok so I joke a little.. But I did move a load of stuff from a couple of home servers to some VMs and it works fine. Less to mess around with and prob cheaper too. The only thing I keep at home now is storage. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

On 22 Feb 2012, at 22:40, "Jeroen van Aart" <jeroen@mompl.net> wrote:

Leigh Porter wrote:

...

You dudes need to get with the times and put all this stuff in the cloud. Ok so I joke a little..

The "cloud" seems to be a more modern implementation of the mainframe "paradigm" (and now I feel soiled having used 2 such words in one sentence). It has its uses, though it's interesting to see how things go full circle. I predict a move away from "the cloud" in about a decade, give or take.

Or sooner when people realise that anything not locked away on an box at home is being routinely nosed at for thought crime and illegal quotations or something or other..

I do have a few virtual private servers (and use them) and have set up a few VPS serving servers myself. However it's fun to tinker with hardware and if I'd migrate as much as possible to VPS systems it'd take a big chunk of the fun out of it.

Yeah it does, I wish I had time for the fun of it! -- Leigh ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________

Joe Greco wrote:

Quite frankly, it's a little horrifying how quickly people have embraced not owning their own resources. On one hand, sure, it's great not to have to worry about some aspects of it all, but on the other hand...

The web sites that we entrust our data to can, and do, vanish:

You know where I never have to worry about any of that? On gear we own and control.

"Cloud" is a crock of hooey buzzword. There's no "cloud." For the average end user, it is the realization that we've farmed out tasks to

Sun had it right all those years ago: "The network is the computer." But it doesn't have to be Amazon's network, or Google's network. We *are* the North American Network Operators' Group. The people here are more than just a little clued about this stuff.

I wholeheartedly agree. I couldn't have said it better :-) -- Earthquake Magnitude: 3.2 Date: Wednesday, February 22, 2012 22:00:06 UTC Location: Central Alaska Latitude: 62.0453; Longitude: -152.4945 Depth: 10.90 km

On 02/22/12 21:13, Jeroen van Aart wrote:

I felt inclined to ask who has attempted to make a really energy efficient setup?

My current always-on home server is: - 3U rackmount box, Supermicro H8SGL, 450 watt '80-plus platinum' PSU - 8-core Opteron 6128 _underclocked_ to 800Mhz - 16 GB of ECC DDR2 - 8x 2TB SATA 'green' drives from assorted manufacturers - all fans replaced with near-silent Noctua models - 2 additional gigE ports (4 total) I run a few VMs on it to compartmentalize things a bit; the host and most VMs run gentoo-amd64-hardened, virtualized with Qemu-KVM. Host OS routes/firewalls. One VM is boot and NFS-root server for a couple diskless workstations around the house. Another VM runs ntpd, local DNS, HTTP forward proxy, shell, dev tools, etc. Another boots FreeBSD and runs only Postrgres. The box is also my home music & movie system, runs motion-detection software to record video from a security camera, and logs weather and other sensor data. The server burns 170 to 190 watts in normal use, up to about 280 peak (movie or music playing + diskless workstations running + compiling stuff + video recording + backing up laptop). This is certainly not low absolute energy consumption compared to some of the other things mentioned in this thread, but it also does a lot more, so it might be more efficient, depending on situation. Consider also that the diskless workstations only use around 35 W each (including monitor), and these are the primary personal computers in my home. In 2011 measured annual energy consumption for the server was 1635 kW*hour, 186 W average. I estimate the diskless workstations use another 270 kW*hour or so annually. -gh/nynex

On Wed, Feb 22, 2012 at 3:48 PM, Joe Greco <jgreco@ns.sol.net> wrote:

...

The current Mac mini "Server" model sports an i7 2.0GHz quad-core CPU and up to 16GB RAM (see OWC for that, IIRC). =A0Two drives, up to 750GB each, or SSD's if you prefer.

The Mac mini server is quite intringuing with that low power requirement . Unfortunately... 16 GB _Non-ECC_ memory. I sure would not want to run a NAS VM on a server with non-ECC memory that cannot correct single-bit errors, at least with any data I cared much about..

When you have such a large quantity of RAM, single-bit/fade errors caused by background irradiation happen often, although at a fairly low rate. Usually on a workstation it's not an issue, because there is not a massive quantity of idle memory.

If you're running this 24x7 with VMs and Non-ECC memory, it's only a question of time, before silent memory corruption results in one of the VMs.

And silent memory corruption can make its way to the filesystem, or applications' internal saved data structures (such as the contents of a VM's registry database).

True can be partially mitigated with backups; but the idea of VMs blue-screening or ESXi crashing with purple screen every 3 or 4 months sounds annoying.

While I don't disagree with the general thought, one could also say it's just a matter of time before your server's power supply fails, or a fan fails, or a hard drive fails. Since we don't hear about Mac mini server users screaming about how their servers are constantly crashing, the severity and frequency of memory corruption events may not be anywhere near what you suggest. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

...

And silent memory corruption can make its way to the filesystem, or applications' internal saved data structures (such as the contents of a VM's registry database).

Since we don't hear about Mac mini server users screaming about how their servers are constantly crashing, the severity and frequency of memory corruption events may not be anywhere near what you suggest.

ECC is an absolute MUST. Case closed- unless you like corrupt encryption keys that blow away an entire volume.

On Sun, Apr 15, 2012 at 1:46 AM, Joe Greco <jgreco@ns.sol.net> wrote:

Since we don't hear about Mac mini server users screaming about how Do you hear of lots of Mac mini server users loading up 16GB of RAM?

it's just a matter of time before your server's power supply fails, or

The difference is power supplies don't fail nearly as often as 1-bit DRAM errors, except when subject to harsh conditions. HDD errors are comparably rare also; and yet, the drive surface of any HDD has error correction codes, because disk surfaces are subject to similar problems. Consumer desktop hard drives use non-ECC memory inside the drive for the cache/buffer memory, to save $$$: but it's typically only 12MB or so of memory, so it's approximately 300 days before you have a 50% chance of a single bit error caused by background radiation, and those are good odds, but nevertheless, people get corrupted files, so maybe they aren't that good. Consider that the probability 16GB of SDRAM experiences at least one single bit error at sea level, in a given 6 hour period exceeds 66% = 1 - (1 - 1.3e-12 * 6)^(16 * 2^30 * 8). In any given 24 hour period, the probability of at least one single bit error exceeds 98%. Assuming the memory is good and functioning correctly; It's expected to see on average approximately 3 to 4 1-bit errors per day. More are frequently seen. Now if most of this 16GB of memory is unused, you will never notice that over 30 days, 120 or so bits have been flipped from their proper value.. On the other hand, if you have some filesystem read cache for a NAS VM or database application in the effected space, and moderately important data is being damaged well, that's just plain uncool

... JG

-- -JH

Laurent GUERBY wrote:

Do you have reference to recent papers with experimental data about non ECC memory errors? It should be fairly easy to do

Maybe this provides some information: http://en.wikipedia.org/wiki/ECC_memory#Problem_background "Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10−10−17 error/bit·h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per century, per gigabyte of memory.[2][4][5] A very large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance’09 conference.[4] The actual error rate found was several orders of magnitude higher than previous small-scale or laboratory studies, with 25,000 to 70,000 errors per billion device hours per megabit (about 3–10×10−9 error/bit·h), and more than 8% of DIMM memory modules affected by errors per year." -- Earthquake Magnitude: 4.9 Date: Wednesday, April 18, 2012 16:21:41 UTC Location: Solomon Islands Latitude: -7.4630; Longitude: 156.7916 Depth: 414.30 km

On Apr 18, 2012, at 5:55 32PM, Douglas Otis wrote:

On 4/18/12 12:35 PM, Jeroen van Aart wrote:

...

Laurent GUERBY wrote:

...

Do you have reference to recent papers with experimental data about non ECC memory errors? It should be fairly easy to do Maybe this provides some information:

http://en.wikipedia.org/wiki/ECC_memory#Problem_background

"Work published between 2007 and 2009 showed widely varying error rates with over 7 orders of magnitude difference, ranging from 10−10−10−17 error/bit·h, roughly one bit error, per hour, per gigabyte of memory to one bit error, per century, per gigabyte of memory.[2][4][5] A very large-scale study based on Google's very large number of servers was presented at the SIGMETRICS/Performance’09 conference.[4] The actual error rate found was several orders of magnitude higher than previous small-scale or laboratory studies, with 25,000 to 70,000 errors per billion device hours per megabit (about 3–10×10−9 error/bit·h), and more than 8% of DIMM memory modules affected by errors per year." Dear Jeroen,

In the work that led up to RFC3309, many of the errors found on the Internet pertained to single interface bits, and not single data bits. Working at a large chip manufacturer that removed internal memory error detection to foolishly save space, cost them dearly in then needing to do far more exhaustive four corner testing. Checksums used by TCP and UDP are able to detect single bit data errors, but may miss as much as 2% of single interface bit errors. It would be surprising to find memory designs lacking internal error detection logic.

mallet:~ smb$ head -14 doc/ietf/rfc/rfc3309.txt | sed 1,7d | sed 2,5d; date Request for Comments: 3309 Stanford September 2002 Wed Apr 18 23:07:53 EDT 2012 We are not in a static field... (3309 is one of my favorite RFCs -- but the specific findings (errors happen more often than you think), as opposed the general lesson (understand your threat model) may be OBE. --Steve Bellovin, https://www.cs.columbia.edu/~smb

On Apr 19, 2012, at 6:31 43PM, Douglas Otis wrote:

On 4/18/12 8:09 PM, Steven Bellovin wrote:

...

On Apr 18, 2012, at 5:55 32PM, Douglas Otis wrote:

...

Dear Jeroen,

In the work that led up to RFC3309, many of the errors found on the Internet pertained to single interface bits, and not single data bits. Working at a large chip manufacturer that removed internal memory error detection to foolishly save space, cost them dearly in then needing to do far more exhaustive four corner testing. Checksums used by TCP and UDP are able to detect single bit data errors, but may miss as much as 2% of single interface bit errors. It would be surprising to find memory designs lacking internal error detection logic.

mallet:~ smb$ head -14 doc/ietf/rfc/rfc3309.txt | sed 1,7d | sed 2,5d; date Request for Comments: 3309 Stanford September 2002

Wed Apr 18 23:07:53 EDT 2012

We are not in a static field... (3309 is one of my favorite RFCs -- but the specific findings (errors happen more often than you think), as opposed the general lesson (understand your threat model) may be OBE.

Dear Steve,

You may be right. However back then most were also only considering random single bit errors as well. Although there was plentiful evidence for where errors might be occurring, it seems many worked hard to ignore the clues.

Reminiscent of a drunk searching for keys dropped in the dark under a light post, mathematics for random single bit errors offer easier calculations and simpler solutions. While there are indeed fewer parallel buses today, these structures still exist in memory modules and other networking components. Manufactures confront increasingly temperamental bit storage elements, where most include internal error correction to minimize manufacturing and testing costs. Error sources are not easily ascertained with simple checksums when errors are not random.

Yes -- that's precisely why I like that RFC so much. --Steve Bellovin, https://www.cs.columbia.edu/~smb

In a past role, I did spend the time grepping through such a properly configured cluster, with tens of thousands of nodes, looking for failing hardware. I should have done a proper paper with statistics, but I did not. The vast majority of servers had zero correctable ecc errors, while a few had a lot, which is consistent with the theory that ECC errors are more often caused by bad ram.

I'd have to say that that's been the experience here as well, ECC is great, yes, but it just doesn't seem to be something that is "absolutely vital" on an ongoing basis, as some of the other posters here have implied, to correct the constant bit errors that are(n't) showing up. Maybe I'll get bored one of these days and find some devtools to stick on one of the Macs. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

In a message written on Sun, Apr 15, 2012 at 09:54:14PM -0400, Luke S. Crawford wrote:

On my current fleet (well under 100 servers) single bit errors are so rare that if I get one, I schedule that machine for removal from production.

In a previous life, in a previous time, I worked at a place that had a bunch of Cisco's with parity RAM. For the time, these boxes had a lot of RAM, as they had distributed line cards each with their own processor memory. Cisco was rather famous for these parity errors, mostly because of their stock answer: sunspots. The answer was in fact largely correct, but it's just not a great response from a vendor. They had a bunch of statistics though, collected from many of these deployed boxes. We ran the statistics, and given hundreds of routers, each with many line cards the math told us we should have approximately 1 router every 9-10 months get one parity error from sunspots and other random activity (e.g. not a failing RAM module with hundreds of repeatable errors). This was, in fact, close to what we observed. This experience gave me two takeaways. First, single bit flips are rare, but when you have enough boxes rare shows up often. It's very similar to anyone with petabytes of storage, disks fail every couple of days because you have so many of them. At the same time a home user might not see a failure in their lifetime (of disk or memory). Second though, if you're running a business, ECC is a must because the message is so bad. "This was caused by sunspots" is not a customer inspiring response, no matter how correct. "We could have prevented this by spending an extra $50 on proper RAM for your $1M box" is even worse. Some quick looking at Newegg, 4GB DDR3 1333 ECC DIMM, $33.99. 4GB DDR3 1333 Non-ECC DIMM, $21.99. Savings, $12. (Yes, I realize the Motherboard also needs some extra circuitry, I expect it's less than $1 in quantity though). Pretty much everyone I know values their data at more than $12 if it is lost. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

Jimmy Hess wrote:

Consider that the probability 16GB of SDRAM experiences at least one single bit error at sea level, in a given 6 hour period exceeds 66% = 1 - (1 - 1.3e-12 * 6)^(16 * 2^30 * 8). In any given 24 hour period, the probability of at least one single bit error exceeds 98%. Assuming the memory is good and functioning correctly;

application in the effected space, and moderately important data is being damaged well, that's just plain uncool

Having limited knowledge of which consumer devices support ECC memory and which don't I was pleasantly surprised to find out the always on IBM thinkpad I ran for years refused to work with non-ECC memory. Greetings, Jeroen -- Earthquake Magnitude: 6.2 Date: Tuesday, April 17, 2012 19:03:55 UTC Location: east of the South Sandwich Islands Latitude: -59.0988; Longitude: -16.6928 Depth: 1.00 km

Marcel Plug wrote:

I've run a SheevaPlug at home for a few years now. I don't do anything fancy with it, but it does what I need it to do. Mostly that

I wonder how reliable the storage is in these things. Is it comparable to modern SSDs?

Oh and I also have native IPv6 on my DSL. I like to brag about that whenever I can.

So your ISP delivers IPv6 to your home? I wish mine did... -- Earthquake Magnitude: 3.2 Date: Wednesday, February 22, 2012 22:00:06 UTC Location: Central Alaska Latitude: 62.0453; Longitude: -152.4945 Depth: 10.90 km

Marcel Plug wrote:

No issues so far. As I said though, I don't push it too hard. I don't have any specs or stats off hand, so I can't get any more detailed.

What's the speed like?

I'm pretty happy with them, I just wish my DLink would stop requiring reboots...

I assume you connected it to a (battery backed) UPS? If not doing so may help with that. Small fluctuations in power may cause just enough bitrot (http://www.catb.org/jargon/html/B/bit-rot.html) for it to behave funky but not all out fail. Greetings, Jeroen -- Earthquake Magnitude: 3.2 Date: Wednesday, February 22, 2012 22:00:06 UTC Location: Central Alaska Latitude: 62.0453; Longitude: -152.4945 Depth: 10.90 km

I've spent a fair amount of time working on energy effiency at home. While I've had a rack at my house in the distant past, the cooling and power bill have always made me work at down sizing. Also, as time went by I became more obsessed with quite fans, or in particular fanless designs. I hate working in a room with fan noise.

So, good group to ask, probably... anyone have suggestions for a low- noise, low-power GigE switch in the 24-port range ... managed, with SFP? That doesn't require constant rebooting? I'm sure I'll get laughed at for saying we like the Dell 5324. It's a competent switch that we've had good luck with for half a decade. The RPS is noisy as heck, though, and overall consumption is something like maybe 80 watts per switch (incl RPS).

The area where I think work needs to be done is home file servers. Most of the low power computer options assume you also want a super-small case and a disk or two. Many Atom motherboards only have a pair of SATA ports, a rare couple have four ports. There seems to be this crazy assumption that if you need 5 disks you need mondo processor, and it's just not true. I need 5 disks for space, but if the box can pump it out at 100Mbps I'm more than happy for home use. It idles 99.99% of the time.

I'd love a low powered motherboard with 6-8 SATA, and a case with perhaps 6 hot swap bays but designed for a low powered, fanless motherboard. IX Systems's FreeNAS Mini is the closest I've seen, but it tops out at 4 drives.

But what's really missing is storage management. RAID5 (and similar) require all drives to be online all the time. I'd love an intelligent file system that could spin down drives when not in use, and even for many workloads spin up only a portion of the drives. It's easy to imagine a system with a small SSD and a pair of disks. Reads spin one disk. Writes go to that disk and the SSD until there are enough, which spins up the second drive and writes them out as a proper mirror. In a home file server drive motors, time you have 4-6 drives, eat most of the power. CPU's speed step down nicely, drives don't.

FreeNAS can cope with ATA idle spindowns. You don't need to have all the drives spun up all the time. But it's a lot more dumb than it maybe could be. What do you consider a reasonable power budget to be?

The cloud is great for many things, but only if you have a local copy. I don't mind serving a web site I push from home out of the cloud, if my cloud provider dies I get another and push the same data. It seems like keeping that local copy safe, secure, and fed with electricty and cooling takes way more energy (people and electricty) than it should.

Quite frankly, and I'm going to get some flak for saying this I bet, I am very disappointed at how poorly the Internet community and related vendors have been at making useful software, hardware, and services that mere mortals can use that do not also marry them to some significant gotchas (or their own proprietary platforms and/or services). Part of the reason that people wish to outsource their problems is because it hasn't been made easy to handle them yourself. Look at e-mail service as just one example. What the average user wants is to be able to get and send e-mail. Think of how much effort it is to set up an e-mail system, with spam filtering, a web frontend, and all the other little things. I've been building e-mail services on the Internet for more than a quarter of a century, and as far as I can tell, it has not gotten easier - it's gotten worse. Most people just concede defeat without even trying at this point, point their domains at Gmail, and let someone else handle it. What about services like Flickr? We've completely failed at providing strategies for users to retain their pictures locally without putting them at risk. By that, I mean that Microsoft (for example) has made it nice and easy for users to pull their digital photos off their cameras, but has failed to impress upon users that their computers are not redundant or reliable, and then when a hard drive fails, years worth of pictures vanish in a moment. So that frustrates users, who then go to services like Flickr, upload their content there, and their data lies on a server somewhere, awaiting the day the business implodes, or gets T-Mo Sidekick'ed, or whatever. This frustrates me, seeing as how we've had so much time in which this stuff could have been made significantly more usable and useful... ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

I like the Juniper EX2200C switches. They are only 12-port, but have 2 SFPs. They are very low power, and have no fans. However, I am still waiting (it has been several months) for them to send me the correct rack mount brackets (which are a separate purchase). -Randy -- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ---- ----- Original Message -----

On Thursday, February 23, 2012 04:53:06 PM Joe Greco wrote:

...

So, good group to ask, probably... anyone have suggestions for a low- noise, low-power GigE switch in the 24-port range ... managed, with SFP? That doesn't require constant rebooting?

I can't comment to the rebooting, but a couple of years ago I looked at the Allied-Telesis AT-9000-28SP, which is a smack steeply priced (~$1,500) but has flexible optics and is managed. And at ~35 watts is the lowest powered managed gigabit switch I was able to find for our solar powered telescopes. The grant that was going to fund that fell through, so I'm still running the 90W+ Catalyst 2900XL with two 1000Base-X modules and 24 10/100 ports instead, but the AT unit looked pretty good as a pretty much direct replacement with extra bandwidth.

It exists. Google for "unRAID" It uses something like Raid4 for Parity data, but stores entire files on single spindles. It's designed for home media server type environments. This way, when you watch a video, only the drive you are using needs to power up. It also lets you add/remove mismatched disks with no rebuild needed. http://lime-technology.com/technology * Better power management: not all hard drives are required to be spinning in order to access data normally; hard drives not in use may be spun down. However modern "green" drives don't take that much power. On Fri, Apr 13, 2012 at 1:06 PM, Jeroen van Aart <jeroen@mompl.net> wrote:

Leo Bicknell wrote:

...

But what's really missing is storage management. RAID5 (and similar) require all drives to be online all the time. I'd love an intelligent file system that could spin down drives when not in use, and even for many workloads spin up only a portion of the drives. It's easy to imagine a system with a small SSD and a pair of disks. Reads spin one disk. Writes go to that disk and the SSD until there are enough, which spins up the second drive and writes them out as a proper mirror. In a home file server drive motors, time you have 4-6 drives, eat most of the power. CPU's speed step down nicely, drives don't.

Late reply by me, but excellent points.

A combination of mdadm and hdparm on linux should suffice to have a raid that will spin down the disks when not in use. I have used for years a G4 system with a mdadm raid1 (and a separate boot disk) and hdparm configured to spin the raid disks down after 10 minutes and it worked great.

I think in a raid10 this would only spin up the disk pair that has the data you need, but leave the rest asleep. But I didn't try that yet.

What I'd like is to have small disk enclosuer that includes a whole (low power) computer capable of having linux installed on some flash memory. Say you have an enclosure with space for 4 2.5 inch disks, install linux, set it up as a raid10, connect through USB to your computer for back up purposes.

Greetings, Jeroen

-- Earthquake Magnitude: 3.0 Date: Friday, April 13, 2012 17:45:06 UTC Location: Central Alaska Latitude: 64.0464; Longitude: -148.9850 Depth: 1.80 km

Once upon a time, Jeroen van Aart <jeroen@mompl.net> said:

There may be a performance penalty using raid4, because it uses one parity disk. Although that system looks like it can be useful for some purposes it looks less ideal for home use. Also I don't see how it would allow you to install your own OS.

For read-mostly storage, there's no penalty as long as there's no disk failure. The parity drive wouldn't even spin up for reads. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

Have you looked at the HP ProLiant MicroServer? Cheers, Henk On 13-04-12 12:06, Jeroen van Aart wrote:

Leo Bicknell wrote:

...

But what's really missing is storage management. RAID5 (and similar) require all drives to be online all the time. I'd love an intelligent file system that could spin down drives when not in use, and even for many workloads spin up only a portion of the drives. It's easy to imagine a system with a small SSD and a pair of disks. Reads spin one disk. Writes go to that disk and the SSD until there are enough, which spins up the second drive and writes them out as a proper mirror. In a home file server drive motors, time you have 4-6 drives, eat most of the power. CPU's speed step down nicely, drives don't.

Late reply by me, but excellent points.

A combination of mdadm and hdparm on linux should suffice to have a raid that will spin down the disks when not in use. I have used for years a G4 system with a mdadm raid1 (and a separate boot disk) and hdparm configured to spin the raid disks down after 10 minutes and it worked great.

I think in a raid10 this would only spin up the disk pair that has the data you need, but leave the rest asleep. But I didn't try that yet.

What I'd like is to have small disk enclosuer that includes a whole (low power) computer capable of having linux installed on some flash memory. Say you have an enclosure with space for 4 2.5 inch disks, install linux, set it up as a raid10, connect through USB to your computer for back up purposes.

Greetings, Jeroen

On Mon, Apr 16, 2012 at 11:22:20AM -0700, Henk Hesselink wrote:

...

Have you looked at the HP ProLiant MicroServer?

Notice it takes up to 8 GByte ECC memory and supports zfs via napp-it/Illumos. A hacked BIOS was required to use the 5th internal SATA port in AHCI mode, maybe that's no longer necessary with N40L.

The MicroServer is actually a nice little platform, one little bright spot in the small-home-server market. It does have some other issues though: 1) It's not particularly low-power, as in, I managed to build some Xeon based systems that run rings around it for only maybe a dozen watts more, and some of the NAShead guys over at one of the Linux based projects have a similar but lower-power platform for a lower price, 2) While it has a remote management card available, it's known to not work with certain things, including FreeBSD, 3) Various problems noted with the eSATA port, such as the inability to use an external port multiplier. On the flip side, some people have tossed one of those 4-2.5"-in-a-5.25" bay racks into the optical bay, along with a PCI controller, to allow the addition of SSD's or whatever for NAS use. Pretty cool and the thing *is* pretty compact. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.