Here's a paradigm for you: "frog in a well". The frog looks up all its life and thinks that the entire world outside the well looks just like that patch of sky it sees. C programmers often view objects this way. (I am a C programmer, but I do not view objects that way.)
On a more concrete note, you better review your "all exceptions implementations cause a performance hit" claim. Modern exception handers are not the same as your grandaddy's exception handler. Apparently unlike you, I have verified that there is no discernable performance hit for exceptions with the compiler I use.
But the protection is not perfect. Throw random data into a few adjacent blocks the way a head crash does, and if those blocks happen to be structural metadata, think about how extensive the data loss could be. In most cases, e2fsck and repair damage like that. ZFS can't.
If you need help imagining this, think about the effect of sticking a pin into your aortic valve.
The "self-healing filesystem" (as I understand in the case of ZFS) is that it makes sure that the filesystem itself is not corrupted, i.e. the *whole* system is automatically healed.
False. ZFS "self-healing" has no concept of filesystem structure at all, it only knows about raid parity sets so it can fix a single block dropout or corruption of that sort. But blow big holes in the filesystem the way a head crash or failing flash does and ZFS "self-healing" gets useless fast. And yes, I have seen exactly that kind of corruption with Ext3/4 on multiple occasions and e2fsck has been able to get nearly all the data back. Obviously, if you blow a hole right in the middle of nonredundant data, it's not coming back, but at least e2fsck gives you the best shot at it of any filesystem.
It's actually unconsciounable that the false impression of "self-healing" promulgated by ZFS fans and repeated by you has been allowed to propagate without responsible correction by ZFS designers, who certainly understand the nature of the hyperbole. Smells like intellectual fraud. I'm not saying it is intellectuatl fraud per se, just that it smells like it.
Re "don't be an ass"... overeaction indeed. But perhaps understandable given the persistent false claims we hear about ZFS. Come on, ZFS is a decent filesystem without ascribing mythical powers to it that it does not possess. But nonsensical hype and shameless exaggeration do not serve that community well. Eventually somebody who bothered to examine the code and know the facts is going to come along and make some wide eyed claims look a little dumb.
The stupidest part of this whole issue: nothing stops ZFS from having a proper repairing fsck except hubris and misplaced faith in the capabilities of raid-only corruption repair.
The people who pay the bills don't care about wizzy directx features, they want the computer to be better at what they use it for, and they're getting repeated burned on that front.
ZFS has got "self-healing" and does not need fsck.
Every time I hear this absurb blather repeated I hear "up the creek without a paddle" but hey, it's ok because ZFS is "self-healing". Hah what rubbish. Do you even know what the so-called self-healing is? Recovering data from parity. Now... Suppose you lose a whole stripe, what now? Hmm?
The truth about why ZFS has no repairing fsck is, nobody in that camp is smart enough to write it, especially considering the baroque mess that is ZFS metadata.
Righto. ZFS performs amazingly when not compared to anything. Look, even fanbois admit that ZFS is slow on "simple configurations", like for example... one disk. And it is a memory hog, do we agree? Here are some benchmarks. ZFS last by a mile. Look, we know the drill. ZFS fans talk a great filesystem. It only looks good when you don't compare it to anything. BTW, ZFS is a disgusting mess inside that nobody has the courage to touch in any substantive way now that Sun has paid the death penalty for being stupid. No wonder it has proved impossible to implement a repairing fsck.
Here you go. Please tell me how the poor sod has any hope of getting anything back without a proper repair tool. Oh yeah, I forgot, when your blood runs thick with ZFS koolaid, all those unrecoverable pool errors out there never happened.
NTFS is metadata only journaling, no data protection. Kinda stone age. But good enough for Windows I guess, meets or exceeds the braindamage quotient for the system as a whole.
The only thing people hated about Windows 8 on a PC was the interface. If this gets rid of that it will not be as bad as Windows 8 which means they did something right...
I humbly predict that Microsoft has way too much ego invested to do the right thing and put it back the way it was. IOW the fiasco isn't over, it's just moving into new hitherto unexplored territory.
Do they really? Which new features are those? I thought, these days new versions of Windows are mainly about frog marching the customer base to some wacky new user interface model that is somehow supposed to result in more and bigger transfers of hard earned cash into offshore bank accounts somewhere in Redmond, Nigeria.
so if they had instead asked, 'Will Microsoft get it wrong this time?' the answer would still be no?
They wouldn't ask that, they would ask "will Microsoft get it wrong again?" But they did't ask that either, because, by Betteridge's law, they obviously expect Microsoft to get it wrong again.
ZFS lacks fsck, it's slow unless you through massive hardware at it, and "send" as a replication API is a drug addled piece of crap. Can't resume interrupted replication without starting from the beginning, what kind of amateur effort is that?
There are reasons to use ZFS, and other reasons to use UFS.
Like, for example, UFS actually has a repairing FSCK. ZFS fanatics will argue to the ends of the earth that ZFS doesn't need fsck repair because it has built-in raid. Riiiggght.
Bottom line is, ZFS is groovy and all (though no speed daemon) until it breaks. Chances are excellent that you are well and truly screwed.
I prefer NTFS as a journaling file system. It provides all the functionality and none of the incompatibility that you get with these niche OS's.
Isn't NTFS kind of frozen in time as of 10 years ago at least? As I understand it, devs are mortally afraid to touch it out of fear of breaking it. No new features of any note for how long, a dozen years? And no new optimizations. Kind of zombified really. But don't believe me, see Microsoft's ADHD ReFS effort, they obviously have ZFS envy but don't quite know what to do about it. Supposedly started with gutting the NTFS code base. Great way to start with a clean sheet guys, or not.
Bottom line, nobody looks to Microsoft for industry beating storage software. Never have, never will.
You would want redundancy (send two or more packets)
No way! You want as much bandwidth as you possibly can... the more bandwidth, the less latency to update your Google search index for example, or upload the latest Hollywood sellout. You send along significant error correction, not just error detection. Somewhere in there is an optimum that can only be found by sophisticated mathematics - tempered with actual experience, and sensitive to changing conditions like distance and solar activity. Probably, the optimum would end up being somewhere with 1-2% of bandwidth devoted to error correction. Maybe a trifle more. Certainly not 100-200% redundancy, that just screams amateur. The big deal is, you want to avoid errors in the first place by not crowding the channel(s) so much that the error rate goes vertical. And you want to protect against big burst errors, something like LDPC would be a lot better for than ecc on small packets.
Wasting bandwidth by abusing replication for redundancy is something you would only do if you have more bandwidth than you know what to do with, or are rich and stupid like Google (I'm not making this up).
Instead of jetpacks, everybody ended up with personal RPGs. Instead of underwater cities we have underwater suburbs..
Anyway, getting groceries on Mars would arguably be easier that at the top of Everest or the bottom of the Marianas trench. There is something to be said for having a large, non-moving flat spot to live on, even if it means never going outside. Sure, there remains lots of uninhabited space on earth, but start by writing off pretty much all the oceans... a little matter of the occasional 10 meter wave. It's only a matter of time until Mars starts looking pretty good.
Slashdot Mirror
Civilization is amazing, even for shooter addicts.
It does seem more than a little idiotic to omit Android considering which way the market share wind is blowing.
No, it means the GP doesn't know what he's talking about.
Here's a paradigm for you: "frog in a well". The frog looks up all its life and thinks that the entire world outside the well looks just like that patch of sky it sees. C programmers often view objects this way. (I am a C programmer, but I do not view objects that way.)
On a more concrete note, you better review your "all exceptions implementations cause a performance hit" claim. Modern exception handers are not the same as your grandaddy's exception handler. Apparently unlike you, I have verified that there is no discernable performance hit for exceptions with the compiler I use.
It is not the task of a filesystem to recover data, but to keep the data as consistent as possible.
You are right, it is the task of the recovery tools to recover data*, which for ZFS are deficient or completely missing.
* Short of online repair, which today only exists in the limited form of raid recovery, and BTW, ZFS is far from the only fs that has that.
But the protection is not perfect. Throw random data into a few adjacent blocks the way a head crash does, and if those blocks happen to be structural metadata, think about how extensive the data loss could be. In most cases, e2fsck and repair damage like that. ZFS can't.
If you need help imagining this, think about the effect of sticking a pin into your aortic valve.
The "self-healing filesystem" (as I understand in the case of ZFS) is that it makes sure that the filesystem itself is not corrupted, i.e. the *whole* system is automatically healed.
False. ZFS "self-healing" has no concept of filesystem structure at all, it only knows about raid parity sets so it can fix a single block dropout or corruption of that sort. But blow big holes in the filesystem the way a head crash or failing flash does and ZFS "self-healing" gets useless fast. And yes, I have seen exactly that kind of corruption with Ext3/4 on multiple occasions and e2fsck has been able to get nearly all the data back. Obviously, if you blow a hole right in the middle of nonredundant data, it's not coming back, but at least e2fsck gives you the best shot at it of any filesystem.
It's actually unconsciounable that the false impression of "self-healing" promulgated by ZFS fans and repeated by you has been allowed to propagate without responsible correction by ZFS designers, who certainly understand the nature of the hyperbole. Smells like intellectual fraud. I'm not saying it is intellectuatl fraud per se, just that it smells like it.
Re "don't be an ass"... overeaction indeed. But perhaps understandable given the persistent false claims we hear about ZFS. Come on, ZFS is a decent filesystem without ascribing mythical powers to it that it does not possess. But nonsensical hype and shameless exaggeration do not serve that community well. Eventually somebody who bothered to examine the code and know the facts is going to come along and make some wide eyed claims look a little dumb.
The stupidest part of this whole issue: nothing stops ZFS from having a proper repairing fsck except hubris and misplaced faith in the capabilities of raid-only corruption repair.
The people who pay the bills don't care about wizzy directx features, they want the computer to be better at what they use it for, and they're getting repeated burned on that front.
ZFS has got "self-healing" and does not need fsck.
Every time I hear this absurb blather repeated I hear "up the creek without a paddle" but hey, it's ok because ZFS is "self-healing". Hah what rubbish. Do you even know what the so-called self-healing is? Recovering data from parity. Now... Suppose you lose a whole stripe, what now? Hmm?
The truth about why ZFS has no repairing fsck is, nobody in that camp is smart enough to write it, especially considering the baroque mess that is ZFS metadata.
Don't be an ass. Anybody can search "ZFS unrecoverable" or the like. Up the creek without a fsck.
Righto. ZFS performs amazingly when not compared to anything. Look, even fanbois admit that ZFS is slow on "simple configurations", like for example... one disk. And it is a memory hog, do we agree? Here are some benchmarks. ZFS last by a mile. Look, we know the drill. ZFS fans talk a great filesystem. It only looks good when you don't compare it to anything. BTW, ZFS is a disgusting mess inside that nobody has the courage to touch in any substantive way now that Sun has paid the death penalty for being stupid. No wonder it has proved impossible to implement a repairing fsck.
Here you go. Please tell me how the poor sod has any hope of getting anything back without a proper repair tool. Oh yeah, I forgot, when your blood runs thick with ZFS koolaid, all those unrecoverable pool errors out there never happened.
NTFS is metadata only journaling, no data protection. Kinda stone age. But good enough for Windows I guess, meets or exceeds the braindamage quotient for the system as a whole.
The only thing people hated about Windows 8 on a PC was the interface. If this gets rid of that it will not be as bad as Windows 8 which means they did something right...
I humbly predict that Microsoft has way too much ego invested to do the right thing and put it back the way it was. IOW the fiasco isn't over, it's just moving into new hitherto unexplored territory.
Do they really? Which new features are those? I thought, these days new versions of Windows are mainly about frog marching the customer base to some wacky new user interface model that is somehow supposed to result in more and bigger transfers of hard earned cash into offshore bank accounts somewhere in Redmond, Nigeria.
Why should I waste my time with Windows 10?
Why? Well, if you want to run Windows Applications :-)
Well, or as an alternative to gouging my eyes out with a rusty spoon. Though I have to admit, that one is a close call.
so if they had instead asked, 'Will Microsoft get it wrong this time?' the answer would still be no?
They wouldn't ask that, they would ask "will Microsoft get it wrong again?" But they did't ask that either, because, by Betteridge's law, they obviously expect Microsoft to get it wrong again.
Seem to be a distinct lack of them, a bit surprising.
ZFS lacks fsck, it's slow unless you through massive hardware at it, and "send" as a replication API is a drug addled piece of crap. Can't resume interrupted replication without starting from the beginning, what kind of amateur effort is that?
There are reasons to use ZFS, and other reasons to use UFS.
Like, for example, UFS actually has a repairing FSCK. ZFS fanatics will argue to the ends of the earth that ZFS doesn't need fsck repair because it has built-in raid. Riiiggght.
Bottom line is, ZFS is groovy and all (though no speed daemon) until it breaks. Chances are excellent that you are well and truly screwed.
I prefer NTFS as a journaling file system. It provides all the functionality and none of the incompatibility that you get with these niche OS's.
Isn't NTFS kind of frozen in time as of 10 years ago at least? As I understand it, devs are mortally afraid to touch it out of fear of breaking it. No new features of any note for how long, a dozen years? And no new optimizations. Kind of zombified really. But don't believe me, see Microsoft's ADHD ReFS effort, they obviously have ZFS envy but don't quite know what to do about it. Supposedly started with gutting the NTFS code base. Great way to start with a clean sheet guys, or not.
Bottom line, nobody looks to Microsoft for industry beating storage software. Never have, never will.
You would want redundancy (send two or more packets)
No way! You want as much bandwidth as you possibly can... the more bandwidth, the less latency to update your Google search index for example, or upload the latest Hollywood sellout. You send along significant error correction, not just error detection. Somewhere in there is an optimum that can only be found by sophisticated mathematics - tempered with actual experience, and sensitive to changing conditions like distance and solar activity. Probably, the optimum would end up being somewhere with 1-2% of bandwidth devoted to error correction. Maybe a trifle more. Certainly not 100-200% redundancy, that just screams amateur. The big deal is, you want to avoid errors in the first place by not crowding the channel(s) so much that the error rate goes vertical. And you want to protect against big burst errors, something like LDPC would be a lot better for than ecc on small packets.
Wasting bandwidth by abusing replication for redundancy is something you would only do if you have more bandwidth than you know what to do with, or are rich and stupid like Google (I'm not making this up).
Instead of jetpacks, everybody ended up with personal RPGs. Instead of underwater cities we have underwater suburbs..
Anyway, getting groceries on Mars would arguably be easier that at the top of Everest or the bottom of the Marianas trench. There is something to be said for having a large, non-moving flat spot to live on, even if it means never going outside. Sure, there remains lots of uninhabited space on earth, but start by writing off pretty much all the oceans... a little matter of the occasional 10 meter wave. It's only a matter of time until Mars starts looking pretty good.
Anybody who can live in Manhattan or Beijing could be perfectly happy living on Mars. Probably, half the population of Lahore would be much happier.
Eh, obviously rcp, not scp....