Intel's best kept secret is that many of Intel's cheapest processors support ECC (including most of the i3 series), and as such enable you to build some surprisingly low-cost low-power file servers.

Here's the list of Intel desktop CPUs that support ECC:

http://ark.intel.com/search/ad...

Looks like the MSRP starts at $64 or so. The downside is that you need a chipset that supports ECC too, and those are only server chipsets. Luckily, a motherboard with one of those (like the Intel C222 chipset) start at ~$140 or so.

Slapping together a low-end server motherboard with an i3, some 8-drive HBAs, and a bunch of ECC RAM, it's a popular way to make a low-end file server.

It works if and only if the target system is also using LSI RAID controllers.

Meanwhile, I created my storage pool on Solaris UNIX, used it for years, then switched to Linux without having to do anything to the pool except "zpool export tank" on the old OS and "zpool import tank" on the new one.

Why would you run ZFS on top of two raid6 arrays instead of building a storage pool consisting of two 10-drive raidz2 vdevs? By doing what you're doing, you're effectively running with no redundancy despite being on top of raid6. If ZFS finds a checksum error, it thinks it's running on two big drives in a stripe with no redundancy, and it will be unable to recover the lost data.

What you're doing is highly inadvisable.

Since you shouldn't have more than 8 to 10 disks in any one raidz vdev, the suggestion that raidz is only for huge numbers of disks is absurd. If you're using more drives than that, you're going to be adding multiple vdevs to a pool anyhow, which is striping, so roughly equivalent to raid 5+0.

ZFS only supports on-the-fly dedupe. For batch dedupe, you're probably thinking of HAMMER in DragonFly BSD.

BSD consumes insane amounts of RAM and has a massive performance penalty. It's almost never worth it, because the cost of extra RAM will be more than if you had just bought more disks in the first place.

Compression, on the other hand, requires very little RAM or CPU resources, gives a tangible performance improvement, and saves space. Once ZFS implemented LZ4 (which is extremely fast) it begun making sense to simply always enable compression globally on every filesystem. They should probably make it enabled by default.

You're assuming that the single process isn't multithreaded. ZFS is multithreaded.

They're working on fixing that, but in the mean time you can pipe it through mbuffer or something similar to resolve the issue.

More than that, since you're effectively virtualizing your EXT4 filesystem, you can expand it pretty easily too. You're backed by a storage pool, which means you can expand that pool by adding or replacing drives, and then simply resize the EXT4 filesystem live. EXT4 need not know about the fact that you've added a new raid array to the storage pool.

The link in the article is cut off and gives a 404. Here is the correct link:

http://www.cbc.ca/news/world/a...

I like raidz2 over mirrors because it allows any two drives to fail without data loss. In a mirror configuration (even the one you specified above), the wrong two drives failing can cause data loss. More specifically, if any one drive fails in your listed setup, you've lost redundancy, and any read error on the other drive in the troubled pair would cause data loss.

Mirrors will be faster, while raidz2 will be safer and less wasteful of space. It's all about tradeoffs, and for home use, I prefer the extra reliability and the cost savings of needing less drives for equivalent capacity. The downside is upgrades are bigger and less frequent, but that's a tradeoff I'm willing to accept.

It should be pointed out that with the approach of replace-resilver-replace-resilver-etc, the entire process is done online. No downtime, and the resilver doesn't kill the performance too badly (you can configure how aggressively it goes if you care to do so). So even though I need to replace 8 drives for my next upgrade, and even though it will probably take me a week, my array will be up and available, and I need never reboot. Of course, one of my two HBAs only supports 2TB drives, so I'll need to shut down to replace the controller :P

Adding additional drives to a raidz vdev is not supported, no. Apparently it's a use case that is extremely rare in enterprise, which is where zfs was intended for. Adding additional capacity is easy if you have no redundancy (12x2TB drives in a pool? Just add 2x2TB more drives to the pool and boom, more space), but not as easy if you want redundancy.

So you can't expand an existing vdev, but you can add a new vdev to the zpool. For example, say your current configuration is 12x2TB in raidz2 (the zfs equivalent of raid6). That's giving you 20TB of capacity, after redundancy. You need to add 4TB of additional usable capacity...

There are a few options. ZFS doesn't enforce redundancy, so there's nothing stopping you from adding two bare 2TB drives to the zpool. You'd get your extra 4TB, but data on those drives would be unprotected. Instead, you'd probably have to take 4x2TB, put them in a new raidz2 vdev, and then add that to your zpool. Then you'd have 12x2TB & 4x2TB, giving you that 12TB of usable capacity, and every disk in the array has dual redundancy.

My home file server currently has 7x4TB & 8x2TB. They're both raidz2 arrays, in the same zpool, for 32TB of usable capacity on 44TB of raw storage. I started out with 5x2TB in raidz1 and migrated the data between various configurations. The iterations looked like this:

Configuration 1: 5x2TB (raidz1)

Configuration 2: 5x2TB (raidz1) + 5x2TB (raidz1)

Configuration 3: 7x4TB (raidz2) + 8x2TB (raidz2)

The migration process was:

1 to 2: Add the new 5x2TB (raidz1) vdev to the existing storage pool

2 to 3: Add the new 7x4TB (raidz2) vdev to a new storage pool, zfs send the file system from the old pool to the new pool, wipe the old 2TB drives, add back 8 of them in a new raidz2 vdev, add that new vdev to the existing new pool

The server only has 15 hotswap bays (the 2-to-3 migration required opening the case to get some of the drives hooked up directly), so my next migration will involve replacing the 2TB drives with something larger (probably 8TB by the time I need to expand). To do that, the process in zfs is that you replace a drive, re-silver the array, replace a drive, resilver the array, etc. When you have replaced the last drive, zfs automatically will expand the vdev to use the new capacity. Resilvering a completely empty drive is not fast, so I expect the process will probably take me about a week, since I'd probably start a new resilver each night before bed. But since I run raidz2, at no point would I be without redundancy, so it should be safe.

Did you fail comprehension? He clearly stated they sold the item at the advertised price. Loss leaders are perfectly legal (at least here in California), but you have to actually have to have a reasonable amount of the product on hand. So if a single person buys out all the stock, the business could get in trouble for not having the product on hand, which could be seen as bait-and-switch. When there is an extremely limited supply, it must be clearly stated in the advertisement. A loss leader is meant to attract customers in the hopes that they will buy additional items and make up for the loss and possibly gain a new regular customer. Also, it is perfectly legal to set a limit on sale items.

In many places in the USA, it works exactly like that, which is why the price of power is going negative overnight. In fact, the exact same thing is happening in Germany, why doesn't your magic spot market fix that?

Transport excess capacity to where? If there isn't a demand, there is nowhere you can send your supply. In the middle of the night, demand is low everywhere. If the coal and nuclear plants that run at a constant output plus the power supplied by the wind is greater than the demand then spot prices will drop to negative. Shipping your power to another locality with negative prices or even slightly positive prices doesn't help economically. If the European model obviates the need for storage, why does this list have so many European projects on it?

Sure, a city bus might get 5 miles per gallon. But it's also carrying up to 80 people. If each of those people were driving a car, it'd be the equivalent of each person getting 400 miles per gallon.

There are probably only a few thousand busses in any given city, and they're carrying a whole bunch of people. Replacing busses with cars isn't going to make any real impact on the environment. Replacing the hundreds of thousands of cars in that city, though...