Yes, I did. It quotes an explanation that you can only fix errors in redundant configuration. Considering that the whole basis for this discussion is RAID-5, I think that's a feasible thing. However, metadata is written in multiple places, so if you want a ZFS fsck to correct a corrupted superblock, it's kinda silly since that superblock is written in multiple places anyway. Also, you can tell ZFS to do a manual scrub (as I shown) which has the advantage of running while the array is running so you can cron script it and still keep the array available.
I'm not going to argue license points. The fact is that ZFS is under an open source license and so is Linux. Sun had every right to use their own license.
Wow. I love your FUD. If you're going to lie, at least make it seem truthful.
Lacking in file system utilities (yes, fsck IS necessary even on healthy filesystems, especially on desktops and portables)
Why no fsck? And if you really feel the need to do something:
zpool scrub <pool_name>
License-incompatible with anything worth running it on, other than Solaris itself... which is NOT worth running (see #1 above)
What you mean to say is "Some Operating Systems whose merits can be debated are license incompatible with the license of ZFS." FreeBSD can implement ZFS. Why can't Linux? Because of its license, not that of ZFS.
The only things I have learned for sure is that I'll only use RAID-1, true hardware RAID-5 or 6 (no Intel ICHx "RAID-5"), and Linux software RAID-5 or 6...anything else is too dangerous for recovery.
I think hardware RAID is more dangerous than software RAID for recovery. You can always install the identical Linux kernel and mdtools you had running to recover a Linux software raid array. Or you can always install the same version of Solaris to recover a zfs array. What you can't always do is purchase the same exact card needed to recover an array if it's the card that fails.
Unless you have a managed storage solution (e.g. from EMC) where you can guarantee you can get replacement parts, I would have no warm and fuzzy feelings from hardware based RAID. ZFS all the way.
AES has some advantages (eg. speed) but 3DES is as secure as it gets.
Are you nuts? 3DES is by no means "as secure as it gets." It's a hack. Its strength maxes out at 112 bits due to the true DES key length combined with a meet in the middle attack. The Triple DES Wikipedia Entry states, "NIST considers 3-key TDES to be appropriate through 2030." Honestly, 2030 is not that far away.
Exactly. But that's still not "valueless". Even if you sell a CDO for 22 cents on the dollar (which is the lowest I've seen quoted), it's still not valueless.
Agreed, but the CDO might be worth 22 cents whereas the actual homes might be worth 75 cents. You just might have the sucky tranche.
I've seen wall st data centers... and it's essentially a floor packed with racks of computers and cooling equipment---most of which are 5 years out of date.
Because I'm sure you've been in every Wall St. data center. Trust me, they're not all filled with old servers.
Um no. Though houses, businesses and commercial real estate are worth less due to market conditions, they are certainly not valueless.
Part of the problem is that the assets that have dropped to nothing are not the homes themselves. They are securitizations of the loans issued to buy these homes. If you own such a securitized loan, you can't go to the 1000 homeowners that back it and say "hey, let's work something out." You can either sell it for pennies on the dollar or hold on.
And fortunately your opinion matters not. Speeding up the markets means more efficient markets which in turn means that financial instruments are priced closer to reality.
There is not anything important that can change in a company in less than 1 quarter anyway.
Really? I mean, really? Your view of "important" is rather small.
that's GAMBLING, not investing.
Again, really? That's funny, because I won't step foot in a casino, yet I work on Wall St. My paychecks sure don't feel like I'm gambling.
It was an ugly day of finger-pointing and near-fixes, but in the end, it just left all the financial firms standing there staring at the Exchange. Definitely was a big deal--and it seemed like a lot of volume spilled over to US markets, creating volume related issues here.
So if I buy a product that sucks, I'm supposed to say, "Well gee, this could have happened to any company. I will give them a second chance."
"Sucks" is a very subjective term. There's a difference between you making a subjective decision that "this product isn't for me" and saying under the guise of objectivity that "this product failed so it must suck."
I was a big Abit fan until I had to return a faulty motherboard to NewEgg. Purchasing items online leaves no tolerance for that sort of thing.
Uhh, components fail. Having one failure is hardly a statistically significant sample. It could have been Asus, it could have been Intel, it could have been anyone.
Yeah! And while we're at it, why should I have to pay taxes that go to old, sick and young people I don't even know! It's unjust!
Even though you're being sarcastic, I agree with you. Why should I have to involuntarily pay for things other people take advantage of and I don't? E.g. welfare, medicare, social security, and the list goes on and on. I pay way more into the system than I get back.
I work on Wall St. About 1/4 of the firm is IT workers. That's thousands. And it doesn't account for people who code in other capacities, though that number is smaller.
ZFS RAID-Z won't protect you from a complete double failure. What ZFS will protect you from is silent corruption that would result in an effective double failure. If you have one bad disk in a RAID 5 array and then you try to rebuild the array, but one of the remaining drives has already corrupted blocks, you're out of luck. In ZFS, it's much less likely that you'd ever have corruption as there are end to end checksums.
Seriously, who in their right mind would submit themselves to this type of thing. I can no longer see any merit to traveling out of the country (or by air at all).
Wow. You must be a very boring person. It's nice to see the world--it gives you a different perspective.
If you've got a small, agile car that can be agile in a controlled manner on ice, I think you'd have quite the market in regions that experience actual weather.
Is your claim that an SUV or some sort of truck can do better on ice than a car?
Is there any practical reason why the hardware is limited to 4 x 1 TB?
This used to be true. The new code version (free upgrade) supports volumes up to 64 TB. See here. From that page,
With RAIDiator 3, you were limited to a data volume of 2 terabytes. With four 750 GB drives, accounting for RAID and other overhead, you're roughly at 2 TB. However, with the latest 1 TB drives, usable space with 4 drives are around 2.8 TB, so you'll need RAIDiator 4 to take advantage of that extra space. RAIDiator 4 supports up to 64 TB, so you will be happy to know that your investment will be good for quite a number of years, especially with the way the ReadyNAS capacity is able to grow with X-RAID.
I disagree with this and a number of other comments that say you can't do ingress qos.
I'll respond to this as I did to a similar post. You can't control the other end. You can't control how much data they send and what backoff algorithm they use for TCP. If you could, no one would ever have to worry about a DoS attack with too much TCP data. End to end QoS is the only true solution to the problem.
With exponential back-off. You should look up 'slow start' as well.
You can't control the other end. It might back off considerably and go into slow start, or it might marginally shrink the window and still send a considerable amount of data. I also don't need to lookup "slow start," but I appreciate the snide comment. I'm a network engineer so I know the only way you control these things with any sort of true success is to have end to end QoS.
Slashdot Mirror
Isn't ZFS a filesystem? Why would I care about what filesystem I am using when I am trying to protect my data from disk failures?
Because it's a file system, volume management, and redundancy all rolled into one combined with native NFS and SMB sharing, iSCSI support, etc. etc.
You DID see my previous reply, right?
Yes, I did. It quotes an explanation that you can only fix errors in redundant configuration. Considering that the whole basis for this discussion is RAID-5, I think that's a feasible thing. However, metadata is written in multiple places, so if you want a ZFS fsck to correct a corrupted superblock, it's kinda silly since that superblock is written in multiple places anyway. Also, you can tell ZFS to do a manual scrub (as I shown) which has the advantage of running while the array is running so you can cron script it and still keep the array available.
I'm not going to argue license points. The fact is that ZFS is under an open source license and so is Linux. Sun had every right to use their own license.
Wow. I love your FUD. If you're going to lie, at least make it seem truthful.
Lacking in file system utilities (yes, fsck IS necessary even on healthy filesystems, especially on desktops and portables)
Why no fsck? And if you really feel the need to do something:
License-incompatible with anything worth running it on, other than Solaris itself... which is NOT worth running (see #1 above)
What you mean to say is "Some Operating Systems whose merits can be debated are license incompatible with the license of ZFS." FreeBSD can implement ZFS. Why can't Linux? Because of its license, not that of ZFS.
The only things I have learned for sure is that I'll only use RAID-1, true hardware RAID-5 or 6 (no Intel ICHx "RAID-5"), and Linux software RAID-5 or 6...anything else is too dangerous for recovery.
I think hardware RAID is more dangerous than software RAID for recovery. You can always install the identical Linux kernel and mdtools you had running to recover a Linux software raid array. Or you can always install the same version of Solaris to recover a zfs array. What you can't always do is purchase the same exact card needed to recover an array if it's the card that fails.
Unless you have a managed storage solution (e.g. from EMC) where you can guarantee you can get replacement parts, I would have no warm and fuzzy feelings from hardware based RAID. ZFS all the way.
AES has some advantages (eg. speed) but 3DES is as secure as it gets.
Are you nuts? 3DES is by no means "as secure as it gets." It's a hack. Its strength maxes out at 112 bits due to the true DES key length combined with a meet in the middle attack. The Triple DES Wikipedia Entry states, "NIST considers 3-key TDES to be appropriate through 2030." Honestly, 2030 is not that far away.
Nice, except that Goldman Sachs was never leveraged anywhere near 60:1. Get your facts straight and take your FUD elsewhere.
Exactly. But that's still not "valueless". Even if you sell a CDO for 22 cents on the dollar (which is the lowest I've seen quoted), it's still not valueless.
Agreed, but the CDO might be worth 22 cents whereas the actual homes might be worth 75 cents. You just might have the sucky tranche.
I've seen wall st data centers... and it's essentially a floor packed with racks of computers and cooling equipment---most of which are 5 years out of date.
Because I'm sure you've been in every Wall St. data center. Trust me, they're not all filled with old servers.
Um no. Though houses, businesses and commercial real estate are worth less due to market conditions, they are certainly not valueless.
Part of the problem is that the assets that have dropped to nothing are not the homes themselves. They are securitizations of the loans issued to buy these homes. If you own such a securitized loan, you can't go to the 1000 homeowners that back it and say "hey, let's work something out." You can either sell it for pennies on the dollar or hold on.
I think slowing down the markets is good anyway.
And fortunately your opinion matters not. Speeding up the markets means more efficient markets which in turn means that financial instruments are priced closer to reality.
There is not anything important that can change in a company in less than 1 quarter anyway.
Really? I mean, really? Your view of "important" is rather small.
that's GAMBLING, not investing.
Again, really? That's funny, because I won't step foot in a casino, yet I work on Wall St. My paychecks sure don't feel like I'm gambling.
Since when is 7 hours even close to "a whole day"? Maybe you meant "almost a whole business day"?
It's a whole trading day--and that's all that really matters when it comes to a major market.
It was an ugly day of finger-pointing and near-fixes, but in the end, it just left all the financial firms standing there staring at the Exchange. Definitely was a big deal--and it seemed like a lot of volume spilled over to US markets, creating volume related issues here.
So if I buy a product that sucks, I'm supposed to say, "Well gee, this could have happened to any company. I will give them a second chance."
"Sucks" is a very subjective term. There's a difference between you making a subjective decision that "this product isn't for me" and saying under the guise of objectivity that "this product failed so it must suck."
I have a zero tolerance policy.
And that makes no sense as it does not take into account how hardware fails and plain old statistics.
I was a big Abit fan until I had to return a faulty motherboard to NewEgg. Purchasing items online leaves no tolerance for that sort of thing.
Uhh, components fail. Having one failure is hardly a statistically significant sample. It could have been Asus, it could have been Intel, it could have been anyone.
n's number of digits is always prime, when represented in base-n (hint: one digit)
And by definition, 1 is not prime, so no, this doesn't work.
Yeah! And while we're at it, why should I have to pay taxes that go to old, sick and young people I don't even know! It's unjust!
Even though you're being sarcastic, I agree with you. Why should I have to involuntarily pay for things other people take advantage of and I don't? E.g. welfare, medicare, social security, and the list goes on and on. I pay way more into the system than I get back.
I work on Wall St. About 1/4 of the firm is IT workers. That's thousands. And it doesn't account for people who code in other capacities, though that number is smaller.
ZFS won't protect you either.
ZFS RAID-Z won't protect you from a complete double failure. What ZFS will protect you from is silent corruption that would result in an effective double failure. If you have one bad disk in a RAID 5 array and then you try to rebuild the array, but one of the remaining drives has already corrupted blocks, you're out of luck. In ZFS, it's much less likely that you'd ever have corruption as there are end to end checksums.
Seriously, who in their right mind would submit themselves to this type of thing. I can no longer see any merit to traveling out of the country (or by air at all).
Wow. You must be a very boring person. It's nice to see the world--it gives you a different perspective.
If you've got a small, agile car that can be agile in a controlled manner on ice, I think you'd have quite the market in regions that experience actual weather.
Is your claim that an SUV or some sort of truck can do better on ice than a car?
Not all viruses die in a dry environment.
And neither VRE or MRSA are viruses. They're bacteria, so the point really doesn't apply as they act completely differently.
Is there any practical reason why the hardware is limited to 4 x 1 TB?
This used to be true. The new code version (free upgrade) supports volumes up to 64 TB. See here. From that page,
With RAIDiator 3, you were limited to a data volume of 2 terabytes. With four 750 GB drives, accounting for RAID and other overhead, you're roughly at 2 TB. However, with the latest 1 TB drives, usable space with 4 drives are around 2.8 TB, so you'll need RAIDiator 4 to take advantage of that extra space. RAIDiator 4 supports up to 64 TB, so you will be happy to know that your investment will be good for quite a number of years, especially with the way the ReadyNAS capacity is able to grow with X-RAID.
I disagree with this and a number of other comments that say you can't do ingress qos.
I'll respond to this as I did to a similar post. You can't control the other end. You can't control how much data they send and what backoff algorithm they use for TCP. If you could, no one would ever have to worry about a DoS attack with too much TCP data. End to end QoS is the only true solution to the problem.
With exponential back-off. You should look up 'slow start' as well.
You can't control the other end. It might back off considerably and go into slow start, or it might marginally shrink the window and still send a considerable amount of data. I also don't need to lookup "slow start," but I appreciate the snide comment. I'm a network engineer so I know the only way you control these things with any sort of true success is to have end to end QoS.