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.

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...

They don't need tax breaks to succeed, but since the states were competing to get the gigafactory, the state that offers the highest tax breaks wins. If no state offered tax breaks on the factory, they'd have built it anyhow.

The junk bond status is because S&P doesn't think Tesla will succeed. It's an opinion.

Tesla has always been very open about their strategy. Electric cars are very expensive to make. Their plan was to introduce a high-cost sports car (the roadster) to build experience/resources/etc, and use the revenue from that to design a luxury sedan (the model S), and use that to start to get some economies of scale and use the revenue from that to build a mass-market vehicle (the model 3).

Their next stage of vehicle will not be 20-30K, but it will be a 40K vehicle competing with sedans like the Camry. As soon as it is possible to build a car for 20-30K that will compete with ICE cars, you can be sure that they'll do it.

In other words, they're currently limited by technology (or rather the cost of the technology).

Errm, isn't that the way US politics work in general?

How is this Tesla's fault? In fact, the media has been rather harsh on Tesla for minor problems like the occasional fire in a crash, despite the fact that they're still less likely to have that happen than regular cars.

The Prius has been on the market a lot longer than Tesla's cars. There's a guy putting 40K miles on his Roadster per year without issues, and they've got various warranties for batteries over the long haul.

Nevada's government is claiming that they'll get an 80:1 return on investments for the tax breaks. If true, it seems like a good investment to me. I'm a bit skeptical that they'll get that high of a return, but it seems certain they'll get back more than their investment.

If you live in Nevada, then they're indirectly getting your tax dollars (in that they are getting cheaper rates and tax breaks, rather than actual money handed over). However, the economic impact of the gigafactory is apparently expected to outstrip the tax breaks by a ratio of 80:1, so it sounds like a good deal... if the economic benefits the governor of Nevada is claiming are realized.

Umm, what do you think kids are doing with their calculators? I seem to recall multi-player bomberman and tetris matches happening in the back of math class thanks to the TI-83+ link cable.

What would you do?

Point out a ridiculously inaccurate analogy?

$230 is... OK. Performance is roughly comparable to Intel chips at the same pricepoint, but with significantly higher power draw. There may be potential for cost savings in platform costs, I've not looked into it.

Indeed. And I want a box that will simulate the experience of a CRT on a high-res LCD, not make it pixel-perfect. I want subtle screen curvature, I want scanlines that actually look like they're on a CRT (simulating how bright and dim scanlines are different sizes) and not just sticking black horizontal lines on the image, I want NTSC composite artifacting, I want to simulate a CRT's subpixel pattern...

Ironically, I can do all that with filters for emulators, but not with a real SNES. It's surprising to me that nobody has stuck an FPGA between a composite input and an HDMI output and stuck a CRT simulating pixel shader in the middle.