They both got essentially the same contract, the dollar value represents what the companies bid for it, rather than establishing a first/second place.
Basically, the both won an equal contract. On the one hand, it sucks for SpaceX that they get less money to do the same thing, but on the other hand, it will put quite a feather in their cap to be able to demonstrate concretely that they can live up to their claims of doing it for less, which will give them a huge edge in the next round of contracts. Next time they can say "Look, we did everything just as well as Boeing, but we cost you a ton less. This time you should give us most of the flights."
I think that ship sailed when Microsoft started contributing code to the Linux kernel, although they had released lots of code under OSI-approved licenses way before that.
I once checked out the TV section of a Yodobashi Camera (and if you're ever in Japan, you really must visit a Yodobashi Camera, it's like every store of the floor is the size one or two BestBuy stores, except there's half a dozen floors or more). The brands of TVs on offer was very different from what you'd see outside of Japan. In most of the world, Korean brands like Samsung and LG are quite popular, but in that TV section (of what are probably the largest electronics stores in Japan), there was not a single non-Japanese television brand to be seen. Not a single Samsung or LG television was available.
- The difference is irrelevant, the apps are stored as platform-independent bytecode that (as of the next Android release) is then converted to machine code by ART or done on-the-fly by Dalvik itself. As a result, so long as Dalvik or ART supports the processor architecture, the application doesn't need to.
- As long as the ARM app doesn't use NEON (which I believe Intel's Houdini emulator doesn't support), it shouldn't have any problems running the ARM code on the x86 devices. In fact, you're likely to have better compatibility running emulated on x86 than you are natively on some older ARM devices.
You're accounting only for full-drive failures. IIRC BackBlaze indicates failure rates are higher than 5% per year, but that's not really relevant. The bigger problem is a read error during a resilver. That's something that the drive specs indicate should be expected at least once during any resilver, although in practice I find it less likely than that.
If you're using mirrored pairs, any resilver is (by spec) highly likely to result in corruption due to unrecoverable read errors due to lack of redundancy. Resilvering a single drive in a raidz2 array, however, still provides you with redundancy to recover from any read errors.
Yes, but write throughput is still increased, and not everybody needs more write IOPS. Furthermore, even with 8 disks you can build two raidz2 arrays and put them in a pool, at which point you've got the IOPS of two disks. And on top of that, you can use fast SSDs as ZIL cache devices.
- Most Android apps are Java bytecode, not native code, so the underlying processor architecture is irrelevant (for those apps) - x86 is a supported Android platform, so many apps that do require native code have x86 binaries available - Intel provides an ARM emulator for the x86 version of Android so that x86 Android devices can run ARM binaries - Some ChromeOS devices use ARM processors to begin with.
Only if ZFS is communicating with that higher level. A simpler solution is to just use ZFS's native RAID instead of treating a RAID array as a block device. I can't think of a single benefit to doing that, but I can think of lots of reasons why it's a bad idea.
You shouldn't have to reinstall ZFS after any updates (apart from maybe a distro release upgrade, which on a file server running Ubuntu are probably being done every two years, or six months if you live on the edge), as it uses DKMS and will recompile the modules when you update the kernel or zfs.
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:
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.
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.
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.
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...
Why does his company need a huge pile of tax breaks to succeed? If I open a company tomorrow, how can I get away with not paying taxes?
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.
Why are Tesla's debt bonds in Junk status but he continues to get freebies from states?
The junk bond status is because S&P doesn't think Tesla will succeed. It's an opinion.
Why are Tesla's cars so rudely expensive? Is there a plan for a 4 door sedan that a real family can afford in the 20K - 30K range like the Prius?
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).
Why is it that a guy with a big mouth and political friends on all sides gets so much tax subsidy, loans, breaks and deals?
Errm, isn't that the way US politics work in general?
Why are guys who run factories employing tons of US citizens in US based factories (like Toyota) who produce super reliable product with great mileage get slapped by the media when a bogus story about a gas pedal getting stuck?
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.
3.8 million priuses have been sold and cab drivers will tell you they easily go into the 300K range and even if the battery runs out the car is still useable.
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.
But instead we continue to give money to the cartoon guy.
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.
Schools are understandably reluctant to let [smartphones] be used in classrooms, where students may opt to tune out in class and instead text friends or play games.
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.
Slashdot Mirror
They both got essentially the same contract, the dollar value represents what the companies bid for it, rather than establishing a first/second place.
Basically, the both won an equal contract. On the one hand, it sucks for SpaceX that they get less money to do the same thing, but on the other hand, it will put quite a feather in their cap to be able to demonstrate concretely that they can live up to their claims of doing it for less, which will give them a huge edge in the next round of contracts. Next time they can say "Look, we did everything just as well as Boeing, but we cost you a ton less. This time you should give us most of the flights."
I think that ship sailed when Microsoft started contributing code to the Linux kernel, although they had released lots of code under OSI-approved licenses way before that.
I once checked out the TV section of a Yodobashi Camera (and if you're ever in Japan, you really must visit a Yodobashi Camera, it's like every store of the floor is the size one or two BestBuy stores, except there's half a dozen floors or more). The brands of TVs on offer was very different from what you'd see outside of Japan. In most of the world, Korean brands like Samsung and LG are quite popular, but in that TV section (of what are probably the largest electronics stores in Japan), there was not a single non-Japanese television brand to be seen. Not a single Samsung or LG television was available.
- The difference is irrelevant, the apps are stored as platform-independent bytecode that (as of the next Android release) is then converted to machine code by ART or done on-the-fly by Dalvik itself. As a result, so long as Dalvik or ART supports the processor architecture, the application doesn't need to.
- As long as the ARM app doesn't use NEON (which I believe Intel's Houdini emulator doesn't support), it shouldn't have any problems running the ARM code on the x86 devices. In fact, you're likely to have better compatibility running emulated on x86 than you are natively on some older ARM devices.
You're accounting only for full-drive failures. IIRC BackBlaze indicates failure rates are higher than 5% per year, but that's not really relevant. The bigger problem is a read error during a resilver. That's something that the drive specs indicate should be expected at least once during any resilver, although in practice I find it less likely than that.
If you're using mirrored pairs, any resilver is (by spec) highly likely to result in corruption due to unrecoverable read errors due to lack of redundancy. Resilvering a single drive in a raidz2 array, however, still provides you with redundancy to recover from any read errors.
Yes, but write throughput is still increased, and not everybody needs more write IOPS. Furthermore, even with 8 disks you can build two raidz2 arrays and put them in a pool, at which point you've got the IOPS of two disks. And on top of that, you can use fast SSDs as ZIL cache devices.
Some points here:
- Most Android apps are Java bytecode, not native code, so the underlying processor architecture is irrelevant (for those apps)
- x86 is a supported Android platform, so many apps that do require native code have x86 binaries available
- Intel provides an ARM emulator for the x86 version of Android so that x86 Android devices can run ARM binaries
- Some ChromeOS devices use ARM processors to begin with.
Only if ZFS is communicating with that higher level. A simpler solution is to just use ZFS's native RAID instead of treating a RAID array as a block device. I can't think of a single benefit to doing that, but I can think of lots of reasons why it's a bad idea.
Sorry, brain fart. I meant "DEDUPE consumes insane amounts of RAM", not "BSD".
You shouldn't have to reinstall ZFS after any updates (apart from maybe a distro release upgrade, which on a file server running Ubuntu are probably being done every two years, or six months if you live on the edge), as it uses DKMS and will recompile the modules when you update the kernel or zfs.
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.
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...
Why does his company need a huge pile of tax breaks to succeed? If I open a company tomorrow, how can I get away with not paying taxes?
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.
Why are Tesla's debt bonds in Junk status but he continues to get freebies from states?
The junk bond status is because S&P doesn't think Tesla will succeed. It's an opinion.
Why are Tesla's cars so rudely expensive? Is there a plan for a 4 door sedan that a real family can afford in the 20K - 30K range like the Prius?
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).
Why is it that a guy with a big mouth and political friends on all sides gets so much tax subsidy, loans, breaks and deals?
Errm, isn't that the way US politics work in general?
Why are guys who run factories employing tons of US citizens in US based factories (like Toyota) who produce super reliable product with great mileage get slapped by the media when a bogus story about a gas pedal getting stuck?
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.
3.8 million priuses have been sold and cab drivers will tell you they easily go into the 300K range and even if the battery runs out the car is still useable.
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.
But instead we continue to give money to the cartoon guy.
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.
Schools are understandably reluctant to let [smartphones] be used in classrooms, where students may opt to tune out in class and instead text friends or play games.
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.