SKEIN 256/512 was a SHA3 finalist and is only 1/2 the speed of SSE4 CRC32C, and that is on a CORE2 DUO with out modern SIMD. For half the speed on any 64bit machine you gain many more bits and cryptographic strength.
Native flash support isn't a huge selling point. A simple IO layer like FreeBSD's GEOM can handle that. They're two distinctly separate issues with virtually no benefit of integration. Similar thing with encryption and ZFS. OpenZFS has decided to forgo encryption because layers like GEOM can handle the encryption just fine and has the benefit of being useful for other file systems as well and reduces the work, complexity, and chance of bugs for OpenZFS. There are some benefits to ZFS directly supporting encryption, but they're corner cases and more useful as a check-box for policy requiring such features than needing such features.
The problem with ZFS is the only way to rebalance vDevs or removing them is to do pointer re-writing, and pointer re-writing by definition leaves the FS in an inconsistent state during the transition, and they refuse to do anything that leaves the FS in an inconsistent state. What they need is a way to atomically update all references that point to a a data block. There are some ways to do this, but the cure is worse than the disease. It's simpler to just make a duplicate system with your corrected vDevs and replicate the data over to them.
They actually did find a work-around to removing a vDev. Make a virtual vDev that is backed by the remaining vDevs, replicate that to-be-removed vDev to that virtual vDev, then remove the one vDev. I don't know when/if this will be implemented, but one of the original engineers who designed and programmed ZFS back with Sun who is still a contributing member to OpenZFS, said this is doable.
With my limited understanding, you may be able to change a vDev's raid type with this new feature. If you can clone a vDev without cloning the entire pool, you could in theory write the data to a vDev with a different raid level. You just can't do in-place raid level changes.
You can configure ZFS to only cache metadata in memory. Out of the box, ZFS comes configured for servers with at least 8GiB of memory. You can tweak it to be decent on low end hardware, but it really isn't meant for embedded systems.
A well designed FS should not allow for committed data to be lost. A correct design results in a very binary state, either things work or they don't. If they work, you don't lose data, if they don't work, it immediate errors out instead of chugging along and corrupting data.
Of course this is ideal and not 100% attainable, but you can get really damned close. Fail early and fail with a clear error message with the exact reason. All reasons should be accounted for.
Not the driver, that's a divide-by-zero in a bash-script that only happened when there were 0 reads from the L2arc, which can only happen during a brief window after the system starts up.
A generic algorithm that takes 10 years between each iteration. btrfs has some cool things, but has some horrible things that seem cool to a dev because of all the complex setups you can do, but sounds like a nightmare to a sysadmin because of all the complex setups it can do. It also forgoes some very important features to gain these "nifty" features.
ZFS is really great, but not perfect. How about someone takes the idea of ZFS, but with no legacy dependencies to hold them down, and implement it in a way that makes up for its shortcomings, like no pointer re-write? One idea that I like about btrfs is configurable raid levels per volume.
I've seen so much open source software with fundamental coding and security errors I shudder every time I see someone using one of these applications.
You had me at this, but then lost me with
but I recommend for my business clients never to use open source
Yes, some popular parts of open source could use an huge overhaul on coding practices and designs, but they're still pretty decent most of the time. Especially the core code, like the Linux Kernel, lots of great code quality overall.
when you leak it in C or C++, the OS can't get the memory back when the program quits
Incorrect, but some truth. When a program quits, all of it's virtual memory is released, but any unmanaged resources like file descriptors could somehow be left in an opened state.
GC still requires a stop world during compaction or any times references need to change. Certain parts of the GC can be done in parallel, like cleaning up dereferenced objects. The GC will eventually kick in and can cause jitter. Improved GCs will preemptively start to stop-world in smaller chunks than waiting until the last possible moment then grinding to a halt for a long time.
You can't proxy HTTPS without having control of the client machine to install your custom CA. HTTPS will freak out when the cert doesn't match and is not signed by a "trusted" CA.
At one of my hourly jobs back in college, someone had 110 hours on their pay-check. Punch in, punch out, and even punch out on breaks. It can be done, but I don't recommend it.
UDP and TCP, choose which one you want. TCP is great if you want the accuracy of calling someone on the phone and saying "now". It's isn't UDP's fault for spoofing and amp attacks, that's that application's fault. UDP blindly does what it's told, no questions asked. Application says respond with a payload, UDP does it.
OpenNTPd added the ability to tweak the kernel tick rate to reduce skew. It can now keep your clock within 10 milliseconds between syncs. Still not as good as the official NTP.
I assumed you were talking about the developers because the community is great. Very nice and helpful people. Maybe you have a social issue and find any amount of push back to be threatening.
I am not trying to say the F-35 is good, I have no idea, but from what I understand about the jet is it's designed to not get into dog fights in the first place. A similar line of logic of someone gaining physical access to your server, all bets are off. F-35 has advanced stealth and targeting tech that also allows the jets to communicate with each other to integrate targeting information from multiple systems.
Instead of a car analogy, an RPG analogy. If you're a hunter and you're getting into melee range with a rogue, you're doing it wrong.
Slashdot Mirror
How does that help if you want to boot off of ZFS?
SKEIN 256/512 was a SHA3 finalist and is only 1/2 the speed of SSE4 CRC32C, and that is on a CORE2 DUO with out modern SIMD. For half the speed on any 64bit machine you gain many more bits and cryptographic strength.
Native flash support isn't a huge selling point. A simple IO layer like FreeBSD's GEOM can handle that. They're two distinctly separate issues with virtually no benefit of integration. Similar thing with encryption and ZFS. OpenZFS has decided to forgo encryption because layers like GEOM can handle the encryption just fine and has the benefit of being useful for other file systems as well and reduces the work, complexity, and chance of bugs for OpenZFS. There are some benefits to ZFS directly supporting encryption, but they're corner cases and more useful as a check-box for policy requiring such features than needing such features.
The problem with ZFS is the only way to rebalance vDevs or removing them is to do pointer re-writing, and pointer re-writing by definition leaves the FS in an inconsistent state during the transition, and they refuse to do anything that leaves the FS in an inconsistent state. What they need is a way to atomically update all references that point to a a data block. There are some ways to do this, but the cure is worse than the disease. It's simpler to just make a duplicate system with your corrected vDevs and replicate the data over to them.
They actually did find a work-around to removing a vDev. Make a virtual vDev that is backed by the remaining vDevs, replicate that to-be-removed vDev to that virtual vDev, then remove the one vDev. I don't know when/if this will be implemented, but one of the original engineers who designed and programmed ZFS back with Sun who is still a contributing member to OpenZFS, said this is doable.
With my limited understanding, you may be able to change a vDev's raid type with this new feature. If you can clone a vDev without cloning the entire pool, you could in theory write the data to a vDev with a different raid level. You just can't do in-place raid level changes.
You can configure ZFS to only cache metadata in memory. Out of the box, ZFS comes configured for servers with at least 8GiB of memory. You can tweak it to be decent on low end hardware, but it really isn't meant for embedded systems.
A well designed FS should not allow for committed data to be lost. A correct design results in a very binary state, either things work or they don't. If they work, you don't lose data, if they don't work, it immediate errors out instead of chugging along and corrupting data.
Of course this is ideal and not 100% attainable, but you can get really damned close. Fail early and fail with a clear error message with the exact reason. All reasons should be accounted for.
Not the driver, that's a divide-by-zero in a bash-script that only happened when there were 0 reads from the L2arc, which can only happen during a brief window after the system starts up.
A generic algorithm that takes 10 years between each iteration. btrfs has some cool things, but has some horrible things that seem cool to a dev because of all the complex setups you can do, but sounds like a nightmare to a sysadmin because of all the complex setups it can do. It also forgoes some very important features to gain these "nifty" features.
ZFS is really great, but not perfect. How about someone takes the idea of ZFS, but with no legacy dependencies to hold them down, and implement it in a way that makes up for its shortcomings, like no pointer re-write? One idea that I like about btrfs is configurable raid levels per volume.
I've seen so much open source software with fundamental coding and security errors I shudder every time I see someone using one of these applications.
You had me at this, but then lost me with
but I recommend for my business clients never to use open source
Yes, some popular parts of open source could use an huge overhaul on coding practices and designs, but they're still pretty decent most of the time. Especially the core code, like the Linux Kernel, lots of great code quality overall.
when you leak it in C or C++, the OS can't get the memory back when the program quits
Incorrect, but some truth. When a program quits, all of it's virtual memory is released, but any unmanaged resources like file descriptors could somehow be left in an opened state.
GC still requires a stop world during compaction or any times references need to change. Certain parts of the GC can be done in parallel, like cleaning up dereferenced objects. The GC will eventually kick in and can cause jitter. Improved GCs will preemptively start to stop-world in smaller chunks than waiting until the last possible moment then grinding to a halt for a long time.
Google's going to put it's private CA on the router? Ohh, you mean Google is going to commit a crime and open it self up for a massive law suit. Yep.
You can't proxy HTTPS without having control of the client machine to install your custom CA. HTTPS will freak out when the cert doesn't match and is not signed by a "trusted" CA.
Even worse is that newer strong crypto hashes are much faster than MD5.
NTPd is decent for me. I don't need that kind of accuracy, but it is cool. OpenNTPd would be nice, but no package for PFSense.
Active Peer 67.202.100.50
Delay 10.325ms
Offset 0.487ms
Jitter 0.326ms
The GP said to stop using UDP. You take it up with him, I was making a sarcastic remark.
Good enough for most usages. Stratum 2 time servers can have up to 100ms of uncertainty. 10ms puts you into Stratum 1 for practical purposes.
Unless you're working in specialized situations where microseconds are important, like multi-master distributed systems, I wouldn't worry about it.
At one of my hourly jobs back in college, someone had 110 hours on their pay-check. Punch in, punch out, and even punch out on breaks. It can be done, but I don't recommend it.
UDP and TCP, choose which one you want. TCP is great if you want the accuracy of calling someone on the phone and saying "now". It's isn't UDP's fault for spoofing and amp attacks, that's that application's fault. UDP blindly does what it's told, no questions asked. Application says respond with a payload, UDP does it.
It's been able to do 10ms accuracy for around the last year after they added the ability to adjust the kernel tick rate.
OpenNTPd added the ability to tweak the kernel tick rate to reduce skew. It can now keep your clock within 10 milliseconds between syncs. Still not as good as the official NTP.
maximum POSSIBLE level of sustainable productivity
I assumed you were talking about the developers because the community is great. Very nice and helpful people. Maybe you have a social issue and find any amount of push back to be threatening.
I am not trying to say the F-35 is good, I have no idea, but from what I understand about the jet is it's designed to not get into dog fights in the first place. A similar line of logic of someone gaining physical access to your server, all bets are off. F-35 has advanced stealth and targeting tech that also allows the jets to communicate with each other to integrate targeting information from multiple systems.
Instead of a car analogy, an RPG analogy. If you're a hunter and you're getting into melee range with a rogue, you're doing it wrong.
North Korea has a death sentence and yet people still keep pirating. Sharing culture is an innate function for society.