Just to be clear, when that airbag fills explosively, nobody's arms are going to do squat to stop it from filling, not even Sylvester Stallone's. But you're right, if they are anywhere near the bag they are going to flail like hell and almost certainly hit stuff with devastating impact. From ten-and-two you have a pretty decent chance of smashing your eyeglasses into your eyes with your flying hands/arms.
It's 9 and 3 if you have an airbag, according to the NHTSA.
Well, they're close, anyway. In the real world, around 8 and 4, or even 7:30 and 4:30 is a better choice when you're using two hands. It's been a LONG time since power steering obviated the need to ever use both hands to apply torque. Any but the most violent left turn can be easily accomplished solely with the right hand starting at 4 or 4:30, and any but the most violent right turn can easily be accomplished solely with the left hand starting at 7:30 or 8. With the hands starting low, there is much more available motion before you have to do hand-over-hand, and additionally it is safer in case the airbag goes off and tries to do you violent injury.
The unused hand only comes into play for extremely violent maneuvering; huge hand-over-hand steering inputs.
Most of the time on the highway, one hand at 12 or 1 is perfectly capable of making any required maneuvers. You can't apply huge inputs at highway speed without spinning out anyway.
For anybody who uses the seatbelt, the airbag is his worst enemy anyway. You don't want your arms anywhere near that damn thing when it goes off. Most definitely not above the center of the wheel, but better nowhere near it. Drivers who crash cars for a living always cross their arms over their chest just before impact so flailing arms won't shatter bones and gouge wounds if when they hit objects.
An airbag is not some kind of balloon that blows up fast, like in the cartoons. It has a goddam pyrotechnic inflator. That means explosive. Quicker than the blink of an eye. An airbag is a devastating weapon. If it saves the life of an imbecile who can't trouble to buckle up it MAY be worthwhile, but for anyone of normal intelligence it is a liability.
So, I guess the melt downs in 1959, 1960, 1966, and 1979 were on purpose?
You're getting really closed to being ignored by me because you are not paying attention; not reading for comprehension. I specifically said zero UNCONTAINED meltdowns for nuclear electric power generation. Two of those incidents were test or research reactors, so they have nothing to do with the point. The others released no significant uncontained radiation.
Repeating falsehoods does not make them true. ZFS does not mysteriously "require" ECC RAM, end of goddam story. Plenty of people are using ZFS without ECC RAM.
Well, it sure as hell is crazy unsafe when they *are* lazy bastards, and it sure is a hell of a lot safer when they are painstaking. Look at the US Navy nuclear submarines and aircraft carriers. Perfect nuclear safety record with respect to the nuclear power plants. Hell, look at the US Nuclear electricity industry, even though I wouldn't put it close to being good enough. Zero uncontained meltdowns. Zero hydrogen explosions.
Sounds (revising this) like there's a bit more to it than that, but not much. I believe either of those two methods will work. I suspect the original export/import method may still work too.
Yes, on linux you can specify drives to ZFS using any of the mechanisms in/dev/disk: by-id , by-label, by-path and by-uuid. As well as/dev/sd* of course. This is one aspect where linux is way ahead of FreeBSD.
Sounds like a fairy tale to me. Yes, one can conceive of scenarios where this MIGHT happen, but in general no. There are other scenarios where a RAM error leads to writing wrong data which will in fact be FIXED by ZFS checksums. And still other scenarios where a RAM error has absolutely no effect on ZFS checksumming. Probably the third group of scenarios is most common, followed by the second group.
Generally, with non-ECC RAM, either you can't find a single bit error in years of runtime, or else the first onset of errors will be severe enough to crash the system and the user will run memtest and fix it before any significant damage is done.
Your reference is a lot of utter bullcrap mixed in with a few posters who have a clue. The consequence of RAM errors is EXACTLY the same using ZFS as it is with any other filesystem. You can corrupt your data, or even metadata, either coming from or going to storage. So what. Unreliable SATA cables or bad drive electronics can do EXACTLY the same thing. Even ECC RAM has a finite undetected bit error rate.
Obviously ECC RAM is a Good Idea when you have Important Data, no matter what the file system is, but there is absolutely nothing magic about ZFS that makes magically higher demands on RAM.
No problem, if youi're talking about a reasonabe size ZFS store. Not 64 SAS drives, but say 4-12 SATA. Forget dedupe, which is useless in normal settings anyway, and 16 GB would do it. At or below the lower end of 4-12 drives, you could probably get away half decently with 8 GB depending on how many GB you gobble up in user processes (damn that Firefox!).
I'm running 12 SATA 3 TB in a 16 GB server, where there is nada RAM usage since there is no local user, and even no GUI running at all. It works just dandy for my usage pattern - the great preponderance of the files are 2-30 GB in size, not a whole lot of tiny files - and there is only one user, me.
If you have less than 8 GB, you have to be kidding me.
Yes you can, if the vdev is a concatenation of drives or other vdevs. And yes you can (in the form of additional copies) if it is a mirror.
And, for example, if you have a 6 drive raidz2, you can change each component - on the fly - from a single drive to a logical concatenation of 2-3 drives. Yes, the data safety will be reduced because you only have to simultaneously lose 3 drives out of 12 or 18 instead of 3 out of 6, to get catastrophic data loss, but you've still got double parity.
You can look at this as nitpicking and ZFS ass-covering if you want, but it's meant to be constructive.
Twelve good-size drives is too many for a single-level raidz2 (or RAID6 for that matter). Any guru will tell you that. The design on zfs would be far better with a zpool built on two raidz2 vdevs, 6 drives each. Six drives is the sweet spot for double parity. OK, that's now 16 TB instead of 20. A tradeoff I would make (and did in fact make, with twelve 3 TB drives) in a heartbeat.
Now when you want to grow your pool you can logically concatenate another vdev of 6 more drives. That won't involve any data rebuilding at all, like a RAID setup does. With ZFS the operation is essentially instantaneous. OK, thats an 8 TB increment instead of 4, but a 50% increment makes a whole lot more sense than a lousy 20% anyway.
Does btrfs' idea of RAID include the enormously improved features of raidz[23], or is it clearly on the roadmap? Does btfs support nested filesets, or is it clearly on the roadmap?
You're exactly right as far as I know. You would have to build a new raidz with larger drives or more drives, and with both old and new pools online, zfs send -> zfs receive all the data from old to new; then you could remove the old raidz and throw away the ridiculous tiny obsolete drives.
BTW, a bit of terminology. Zpool is the top level (root) ZFS structure for *any* use of ZFS, even one which only uses a single drive (degenerate case - which actually "works" just fine and dandy, and is a great improvement over ext4fs because of numerous ZFS features such as snapshots and block checksumming). You can have any number of independent zpools. Within a zpool you have vdev components.
From the bottom up, a vdev can be a single drive or partition, or multiple sub vdevs in the form of either (1) a logical concatenation of vdevs (like RAID0), a mirror (sort of like RAID1 but better), a raidz (single parity; sort of like RAID5 but considerably better), a raidz2 (double parity; sort of like RAID6 but considerably better), or a raidz3 (triple parity, beyond RAID6).
A zpool is then either a single vdev (possibly nothing but a single drive or partition), or multiple vdevs combined in exactly the same way.
Thus you can have a tree of arbitrary complexity, for example a mirror of mirrors of mirrors of mirrors of... Or a raidz of raidzs. Or a mirror of raidz2s. Or a raidz3 of mirrors. Or, you name it.
Finally, within a zpool you can create, in a completely ad hoc manner, any combination of zfs filesets (recursively if you wish). This is orthogonal to structure of vdevs and sub vdevs. Each such fileset can independently grow to any size, limited only by the size of the zpool it lies within.
And the stark reality. Once you create a raidz[23], the number of components and the utilized size of the components are forever set in stone for that particular raidz[23]. Mirrors, on the other hand, can have extra elements added (from 2-way to 3-way to arbitrarily many copies). And, if you know how, even the sizes of the individual elements can be grown.
I ran zfs on freebsd for a few years but gave up on it. at one time, I did a cvsup (like an apt-get update, sort of, on bsd) and it updated zfs code, updated a disk format encoding but you could not revert it!
That must have been a while ago, because cvsup has been obsolete for years. Furthermore, cvsup never touched system code; only userland ports. The way you update system code is freebsd-update. I believe there was a lot more to your disaster than you are saying. And I bet ZFS on Linux either didn't exist, or was very primitive and immature, at that time. Sort of like btrfs is now (btrfs is the only native linux filesystem that is even remotely comparable to ZFS in some, but far from all, ways).
That said, it's true that updating FreeBSD should never be a heedless operation. You need a lot more insight and attention to detail to work with FreeBSD than linux. That's the tradeoff for getting a true Unix system.
BTW, most claims that ZFS is extremely RAM hungry stem from users that don't know what they are doing. For example, deduplication virtually never should be enabled for most use. Dedupe can eat RAM like a blue whale. But wthout dedup, any realistic system with 16 GB+ is fine. Skimping on RAM is just silly, anyway.
Yeah, come back to me in several billion years and we can commiserate over it. An utterly pointless concern over relevant time periods. Because after several billion years, there either won't be any human race, or it's capabilities will be beyond our comprehension. Those people will just mentally command a matter synthesizer to make helium, or they will grab it from interstellar space. There is essentially an infinite quantity of helium in space, and it isn't going anywhere until the universe ends.
p.s. Multiple-of-3 / half-generation HDDs have terrible service records
That generalization is highly questionable. I have had a population of over twenty Toshiba 3 TB, including 12 spinning 24x7 that have from 6-14 months of power-on-time. Zero in-service failures.
Yes, sealing of the valve is a non-trivial issue, but it clearly can't possibly be an insuperable problem. Every K tank of compressed helium gas produced since the 1920s has such a valve, and those tanks are pressurized to well over 100 atmospheres. I have had such a tank sitting for over 10 years with negligible leakage as measured by gauge pressure. I did learn to my dismay that if you leave the main valve open and rely on the regulator and balloon-blowing attachment to hold, you will wonder where the gas went within weeks to months.
It would be interesting to know the pressure these drives operate at. If it is just room pressure, then I don't see how you could refill it unless you had an outgress valve as well as an ingress valve, in order to flush it.
"One of the ultralight gases" - well, that narrows it down to H2 and He and nothing else, now, doesn't it? You left out that the candidate gas has to be very high in thermal conductivity as well, but both of those are so.
BTW, hydrogen is not higher density than helium. It is considerably lower. It would be more ideal than helium for this use if it weren't for its highly undesirable propensity to react with other substances.
We're not "running short" of helium. The ready supply of helium-rich natural gas is going to run out some time in the future, but so is the ready supply of just about everything else.
All the helium you could ever possibly want is in the atmosphere. 0.0005% by volume, or 0.00007% by mass, of the atmosphere is helium. The total mass of the atmosphere is 5x10^18 kg, so the total mass of the helium in the atmosphere is 3.5x10^12 kg. At STP (standard temperature and pressure), that represents 2x10^13 cubic meters.
That would fill 100 million Hindenburgs, or many trillion party balloons.
So no, even if/when the current sources of helium run out entirely, "all research into superconductivity" will NOT have to stop. It will "just" cost more. The helium in the atmosphere is constantly escaping into space, and constantly being refreshed by escaping from the earth into the atmosphere. Inside the earth it is constantly being produced by nuclear processes.
Yes, it would be far more expensive to extract helium from the atmosphere at 0.0005% concentration than it is from natural gas sources at concentrations of from 0.1% to several %. But it is glaringly obvious that it is not impossible. The concentration of neon in the atmosphere is less than four times that of helium, and ALL the neon produced is produced by extracting it from the atmosphere.
Slashdot Mirror
Just to be clear, when that airbag fills explosively, nobody's arms are going to do squat to stop it from filling, not even Sylvester Stallone's. But you're right, if they are anywhere near the bag they are going to flail like hell and almost certainly hit stuff with devastating impact. From ten-and-two you have a pretty decent chance of smashing your eyeglasses into your eyes with your flying hands/arms.
Well, they're close, anyway. In the real world, around 8 and 4, or even 7:30 and 4:30 is a better choice when you're using two hands. It's been a LONG time since power steering obviated the need to ever use both hands to apply torque. Any but the most violent left turn can be easily accomplished solely with the right hand starting at 4 or 4:30, and any but the most violent right turn can easily be accomplished solely with the left hand starting at 7:30 or 8. With the hands starting low, there is much more available motion before you have to do hand-over-hand, and additionally it is safer in case the airbag goes off and tries to do you violent injury.
The unused hand only comes into play for extremely violent maneuvering; huge hand-over-hand steering inputs.
Most of the time on the highway, one hand at 12 or 1 is perfectly capable of making any required maneuvers. You can't apply huge inputs at highway speed without spinning out anyway.
For anybody who uses the seatbelt, the airbag is his worst enemy anyway. You don't want your arms anywhere near that damn thing when it goes off. Most definitely not above the center of the wheel, but better nowhere near it. Drivers who crash cars for a living always cross their arms over their chest just before impact so flailing arms won't shatter bones and gouge wounds if when they hit objects.
An airbag is not some kind of balloon that blows up fast, like in the cartoons. It has a goddam pyrotechnic inflator. That means explosive. Quicker than the blink of an eye. An airbag is a devastating weapon. If it saves the life of an imbecile who can't trouble to buckle up it MAY be worthwhile, but for anyone of normal intelligence it is a liability.
You're getting really closed to being ignored by me because you are not paying attention; not reading for comprehension. I specifically said zero UNCONTAINED meltdowns for nuclear electric power generation. Two of those incidents were test or research reactors, so they have nothing to do with the point. The others released no significant uncontained radiation.
Repeating falsehoods does not make them true. ZFS does not mysteriously "require" ECC RAM, end of goddam story. Plenty of people are using ZFS without ECC RAM.
Well, it sure as hell is crazy unsafe when they *are* lazy bastards, and it sure is a hell of a lot safer when they are painstaking. Look at the US Navy nuclear submarines and aircraft carriers. Perfect nuclear safety record with respect to the nuclear power plants. Hell, look at the US Nuclear electricity industry, even though I wouldn't put it close to being good enough. Zero uncontained meltdowns. Zero hydrogen explosions.
You keep using that term, kWh. As well as mis-capitalizing it, I do not think it measures what you seem to think it measures.
Hint: solar panels are measured in kW.
Lackadaisical safety management is dangerous.
Sounds (revising this) like there's a bit more to it than that, but not much. I believe either of those two methods will work. I suspect the original export/import method may still work too.
Yes, on linux you can specify drives to ZFS using any of the mechanisms in /dev/disk: by-id , by-label, by-path and by-uuid. As well as /dev/sd* of course. This is one aspect where linux is way ahead of FreeBSD.
But at least they are plainly *compatible*, aren't they? I mean, since FreeBSD has ZFS in the base system.
And CDDL is *incompatible* with GPL, Isn't it? I mean, since no distro includes it and you have to graft the two together from separate sources.
P.S. - I actually USE ZFS on Linux (as well as on FreeBSD), and I love it.
Sounds like a fairy tale to me. Yes, one can conceive of scenarios where this MIGHT happen, but in general no. There are other scenarios where a RAM error leads to writing wrong data which will in fact be FIXED by ZFS checksums. And still other scenarios where a RAM error has absolutely no effect on ZFS checksumming. Probably the third group of scenarios is most common, followed by the second group.
Generally, with non-ECC RAM, either you can't find a single bit error in years of runtime, or else the first onset of errors will be severe enough to crash the system and the user will run memtest and fix it before any significant damage is done.
Bad advice.
Your reference is a lot of utter bullcrap mixed in with a few posters who have a clue. The consequence of RAM errors is EXACTLY the same using ZFS as it is with any other filesystem. You can corrupt your data, or even metadata, either coming from or going to storage. So what. Unreliable SATA cables or bad drive electronics can do EXACTLY the same thing. Even ECC RAM has a finite undetected bit error rate.
Obviously ECC RAM is a Good Idea when you have Important Data, no matter what the file system is, but there is absolutely nothing magic about ZFS that makes magically higher demands on RAM.
No problem, if youi're talking about a reasonabe size ZFS store. Not 64 SAS drives, but say 4-12 SATA. Forget dedupe, which is useless in normal settings anyway, and 16 GB would do it. At or below the lower end of 4-12 drives, you could probably get away half decently with 8 GB depending on how many GB you gobble up in user processes (damn that Firefox!).
I'm running 12 SATA 3 TB in a 16 GB server, where there is nada RAM usage since there is no local user, and even no GUI running at all. It works just dandy for my usage pattern - the great preponderance of the files are 2-30 GB in size, not a whole lot of tiny files - and there is only one user, me.
If you have less than 8 GB, you have to be kidding me.
Yes you can, if the vdev is a concatenation of drives or other vdevs. And yes you can (in the form of additional copies) if it is a mirror.
And, for example, if you have a 6 drive raidz2, you can change each component - on the fly - from a single drive to a logical concatenation of 2-3 drives. Yes, the data safety will be reduced because you only have to simultaneously lose 3 drives out of 12 or 18 instead of 3 out of 6, to get catastrophic data loss, but you've still got double parity.
You can look at this as nitpicking and ZFS ass-covering if you want, but it's meant to be constructive.
Twelve good-size drives is too many for a single-level raidz2 (or RAID6 for that matter). Any guru will tell you that. The design on zfs would be far better with a zpool built on two raidz2 vdevs, 6 drives each. Six drives is the sweet spot for double parity. OK, that's now 16 TB instead of 20. A tradeoff I would make (and did in fact make, with twelve 3 TB drives) in a heartbeat.
Now when you want to grow your pool you can logically concatenate another vdev of 6 more drives. That won't involve any data rebuilding at all, like a RAID setup does. With ZFS the operation is essentially instantaneous. OK, thats an 8 TB increment instead of 4, but a 50% increment makes a whole lot more sense than a lousy 20% anyway.
Does btrfs' idea of RAID include the enormously improved features of raidz[23], or is it clearly on the roadmap?
Does btfs support nested filesets, or is it clearly on the roadmap?
They're questions, not a challenge.
You're exactly right as far as I know. You would have to build a new raidz with larger drives or more drives, and with both old and new pools online, zfs send -> zfs receive all the data from old to new; then you could remove the old raidz and throw away the ridiculous tiny obsolete drives.
BTW, a bit of terminology. Zpool is the top level (root) ZFS structure for *any* use of ZFS, even one which only uses a single drive (degenerate case - which actually "works" just fine and dandy, and is a great improvement over ext4fs because of numerous ZFS features such as snapshots and block checksumming). You can have any number of independent zpools. Within a zpool you have vdev components.
From the bottom up, a vdev can be a single drive or partition, or multiple sub vdevs in the form of either (1) a logical concatenation of vdevs (like RAID0), a mirror (sort of like RAID1 but better), a raidz (single parity; sort of like RAID5 but considerably better), a raidz2 (double parity; sort of like RAID6 but considerably better), or a raidz3 (triple parity, beyond RAID6).
A zpool is then either a single vdev (possibly nothing but a single drive or partition), or multiple vdevs combined in exactly the same way.
Thus you can have a tree of arbitrary complexity, for example a mirror of mirrors of mirrors of mirrors of ...
Or a raidz of raidzs. Or a mirror of raidz2s. Or a raidz3 of mirrors. Or, you name it.
Finally, within a zpool you can create, in a completely ad hoc manner, any combination of zfs filesets (recursively if you wish). This is orthogonal to structure of vdevs and sub vdevs. Each such fileset can independently grow to any size, limited only by the size of the zpool it lies within.
And the stark reality. Once you create a raidz[23], the number of components and the utilized size of the components are forever set in stone for that particular raidz[23]. Mirrors, on the other hand, can have extra elements added (from 2-way to 3-way to arbitrarily many copies). And, if you know how, even the sizes of the individual elements can be grown.
That must have been a while ago, because cvsup has been obsolete for years. Furthermore, cvsup never touched system code; only userland ports. The way you update system code is freebsd-update. I believe there was a lot more to your disaster than you are saying. And I bet ZFS on Linux either didn't exist, or was very primitive and immature, at that time. Sort of like btrfs is now (btrfs is the only native linux filesystem that is even remotely comparable to ZFS in some, but far from all, ways).
That said, it's true that updating FreeBSD should never be a heedless operation. You need a lot more insight and attention to detail to work with FreeBSD than linux. That's the tradeoff for getting a true Unix system.
BTW, most claims that ZFS is extremely RAM hungry stem from users that don't know what they are doing. For example, deduplication virtually never should be enabled for most use. Dedupe can eat RAM like a blue whale. But wthout dedup, any realistic system with 16 GB+ is fine. Skimping on RAM is just silly, anyway.
Hydrogen thermal conductivity = 0.1805 Wm1K1
Helium thermal conductivity = 0.1513 Wm1K1
Now, which one is higher again?
Yeah, come back to me in several billion years and we can commiserate over it. An utterly pointless concern over relevant time periods. Because after several billion years, there either won't be any human race, or it's capabilities will be beyond our comprehension. Those people will just mentally command a matter synthesizer to make helium, or they will grab it from interstellar space. There is essentially an infinite quantity of helium in space, and it isn't going anywhere until the universe ends.
That generalization is highly questionable. I have had a population of over twenty Toshiba 3 TB, including 12 spinning 24x7 that have from 6-14 months of power-on-time. Zero in-service failures.
Yes, sealing of the valve is a non-trivial issue, but it clearly can't possibly be an insuperable problem. Every K tank of compressed helium gas produced since the 1920s has such a valve, and those tanks are pressurized to well over 100 atmospheres. I have had such a tank sitting for over 10 years with negligible leakage as measured by gauge pressure. I did learn to my dismay that if you leave the main valve open and rely on the regulator and balloon-blowing attachment to hold, you will wonder where the gas went within weeks to months.
It would be interesting to know the pressure these drives operate at. If it is just room pressure, then I don't see how you could refill it unless you had an outgress valve as well as an ingress valve, in order to flush it.
"One of the ultralight gases" - well, that narrows it down to H2 and He and nothing else, now, doesn't it? You left out that the candidate gas has to be very high in thermal conductivity as well, but both of those are so.
BTW, hydrogen is not higher density than helium. It is considerably lower. It would be more ideal than helium for this use if it weren't for its highly undesirable propensity to react with other substances.
We're not "running short" of helium. The ready supply of helium-rich natural gas is going to run out some time in the future, but so is the ready supply of just about everything else.
All the helium you could ever possibly want is in the atmosphere. 0.0005% by volume, or 0.00007% by mass, of the atmosphere is helium. The total mass of the atmosphere is 5x10^18 kg, so the total mass of the helium in the atmosphere is 3.5x10^12 kg. At STP (standard temperature and pressure), that represents 2x10^13 cubic meters.
That would fill 100 million Hindenburgs, or many trillion party balloons.
So no, even if/when the current sources of helium run out entirely, "all research into superconductivity" will NOT have to stop. It will "just" cost more.
The helium in the atmosphere is constantly escaping into space, and constantly being refreshed by escaping from the earth into the atmosphere. Inside the earth it is constantly being produced by nuclear processes.
Yes, it would be far more expensive to extract helium from the atmosphere at 0.0005% concentration than it is from natural gas sources at concentrations of from 0.1% to several %. But it is glaringly obvious that it is not impossible. The concentration of neon in the atmosphere is less than four times that of helium, and ALL the neon produced is produced by extracting it from the atmosphere.
Like maybe all the alpha emitters ever created might produce enough helium in a billion years to fill a few party balloons?
How the hell does this address GP's point that all the helium produced comes from subterranean gas? Way to miss the point.