The E3 series, the most recent versions released in mid 2012. Use the link you provided and select View All E3. Notice the 2011-12 launch dates.
No, that's the first generation E3's. You'll note the page I actually linked you to shows E3 v5, the "View All" link takes you to the database which can only show one generation at a time and defaults to the oldest.
And that is how airplanes occasionally crash. Its usually not one flaw or problem, its multiple problems/flaws occurring at the same time
Right, because they have safety systems that cover the typical cases. Apple lack those, so it's not just the convoluted multiple problems piling up that will take out their products, it's simple common ones as well.
There is quite a difference between corrupting the inode info / timestamp info and corrupting the **contents of a file**, its user data. That is what is unique about ZFS. File data being **read** is at risk due to automatic repairs of **user data**.
ZFS repairs using redundant copies of data which don't exist on single-disk configurations. All ZFS will do in such a situation is tell you there's an error in a file it can't correct and suggest you restore it from backup. If it's a transient memory or IO error causing the checksum to fail, a second attempt at reading it should work.
Yes, server grade CPUs support server grade RAM. And judging from Intel's data sheets the current generation Xeons are slower (clock rate, more cores though) and generate more heat
For you it may be a low risk. For Apple its not. Apple will be shipping millions of machines.
And these machines are already vulnerable just to single bit errors anywhere both in the IO path and in memory.
The repair-of-death you describe involves multiple errors in the memory path occurring in a specific order and in relatively specific places, that are already dangerous to existing filesystems.
The atime update metadata corruption you quote is similarly already a problem with existing filesystems. In fact it's more of a problem for these filesystems because they're overwriting existing metadata, not creating new copies of metadata that can be rolled back in a disaster as ZFS does.
Even if we take it as true that ZFS is more vulnerable to these specific types of error (by no means demonstrated), that needs to be balanced against all the other errors it's less vulnerable against.
Stop approaching this from the perspective that ZFS is flawed. Rather approach this from the perspective that ZFS assumes memory can be trusted
... so does every other filesystem. I'll quote another bit of that paper you like:
"In addition to ZFS, we have applied the same fault injection framework used in Section 5 to a simpler filesystem,ext2. Our initial results indicate that ext2 is also vulnerable to memory corruptions. For example, corrupt data can be returned to the user or written to disk. When certain fields of a VFS inode are corrupted, operations on that inode fail or the whole system crashes. If the inode is dirty, the corrupted fields of the VFS inode are propagated to the inode in the page cache and are then written to disk, making the corruptions permanent. Moreover, if the superblock in the page cache is corrupted and flushed to disk, it might result in an unmountable filesystem"
Intel is more likely to support ECC in lower end CPUs (ex i3) than in mid to higher end CPUS (ex i5, i7)
i7-class Xeons (E3-XXXX) support ECC and are usually priced basically identically to their i7 cousins. i3's get used in tiny NAS systems like HP Microservers, probably why they come in ECC variants.
Another difficulty for a consumer oriented company like Apple, making using ECC not really an option for them
I'm sure Apple are more than capable of pushing for it if they considered it a priority. They have the purchasing power, they have the margins, they have the PR to make people wet themselves over the benefits if they so choose.
When checksums fail ZFS will assume the problem is on disk and attempt to "repair" the data on disk. This automatic repair is a great feature, when your RAM can be trusted.
Repair by attempting to correct the data from a redundant location, if one exists, and if its checksum passes. The bit flips required to make such a process actually damage your data seems quite convoluted - it'd have to be multiple errors in different locations happening at just the right times - one in the read before the checksum is checked, one in the data to repair it after the checksum has been verified but before it's written back.
"By default, access time updates are enabled in ZFS; therefore, a read-only workload will update the access time of any file accessed. Consequently, when the structure containing the access time (znode) goes inactive (or when there is another workload that updates the znode), ZFS writes the block holding the znode to disk and updates and writes all its parental blocks. Therefore, any corruption to these blocks will become permanent after the flush caused by the access time update"
In-memory filesystem metadata can get damaged and end up in on-disk structures regardless of which one you use, and it's far from the only fs with atime updates. Is ZFS really significantly more vulnerable to this by comparison, or is it just that ZFS won't defend you against it?
My quick skim of the paper suggests the latter. They don't seem to condemn ZFS for being worse, rather, they show it suffers the same sort of problems they find ext2 suffers from in face of memory errors, while demonstrating it's great at picking up errors from the disk/IO controller/etc.
The problem with zfs clone is that "clones can only be created from a snapshot" which means that deleting a file from a clone does not delete the file from the underlying snapshot, so the space is never actually freed
Hence why the ZFS filesystem layer is built on top of its volume management layer, and why you manage things like that using the zpool command, not the zfs command.
This is one of the things the Solaris-derived versions have tended to be better at handling - ZFS expects failing drives to be detected/managed by an external fault management service (fmd) which doesn't exist on other OS's. ZFS itself doesn't mark a drive as bad itself unless it outright disappears from the system.
- Mutable snapshots. It is infuriating that ZFS's snapshots are immutable.
Er, snapshots should be immutable. They're used as sources for backups and replication, allowing them to be mutable would defeat the main purpose.
zfs clone if you want a writable copy. What's wrong with that?
ZFS is designed for extremely high quality hardware (and lots of RAM) that doesn't lie to the OS
ZFS is designed to be robust in face of crappy lying disks. That's what all the checksumming and self healing is about - ZFS will cope *far* better with your dire consumer drives than most traditional filesystems. But yes, it likes its RAM, and it likes its redundancy.
That's only a very partial solution - vdev removal, not vdev shrinking. And it's got a pretty meh way of going about it (removing a vdev leaves a permanent layer of redirection in its place).
What we want is something called "block pointer rewriting", which would allow far more flexibility in the modification of an existing pool - possibly even dynamically changing RAID levels on the fly. Unfortunately it's a massive job that nobody's sufficiently interested in solving.
I loath wrappers though as they have a tendency to cost on perfomance an example is Civilization V on Linux is painful compared to windows on trhe same machine.
What makes you think this is the fault of the wrapper rather than just drivers being crap?
My gmail address gets used as a throwaway rather a lot, and you'd be surprised at the number of sites that don't bother at all.
This message was sent to you ($foo@gmail.com) because you are a valued NBA fan registered with us and we wanted to wish you a happy birthday!
Hi meleonaz,
www.skype.com Registered email successfully updated Your email address for the account meleonaz has been successfully updated to $foo@gmail.com
Hi @notme345, We got a request to reset your Instagram password.
Thanks so much for joining Pandora! We're very happy to have you on board, and we look forward to providing you with endless hours of great music listening and discovery.
Many more sites will still create the account and let you use it without me validating the email, and many more provide no means of saying this *isn't* their email.
Because a lot of security boils down to "I'm thinking of a number between 0 and $something, I bet an attacker can't guess it at a rate better than blind chance".
e.g. a 128 bit encryption key is a number between 0 and 340282366920938463463374607431768211455. With a secure random number generator, an attacker will have to on average test half of those possible keys before he finds the correct one, because he can't know anything that will reduce the space he has to search.
If your random number generator is broken - for an extreme example, say you only seed it with a 16-bit process ID - suddenly the random values you generate are trivially guessable, because there's only 65535 possible streams of randomness to check instead of $impossibly_huge_number. What should have taken longer than the age of the universe to crack now takes mere seconds.
DragonFlyBSD's HAMMERFS does much of this - you can examine the version history of files and directories using hammer history and undo commands, and reference versions directly by appending @@ to filenames.
You can control how long history is preserved for and in what level of detail, as well as efficiently replicate it all across the network to remote filesystems (which can have their own, different rules). All this in addition to the more traditional named snapshots approach you're limited to with, e.g. ZFS.
The desktop client is mostly unobfuscated Python bytecode and easily inspected, docstrings, symbol names and all, with a bytecode decompiler. Not good enough, but at least a bit more transparent than most.
Guess that has to be my main server, even though it's a few generations older than my desktop, it has more cores, more IO, more memory and more storage. It runs FreeBSD.
I play with search engines and stuff, the memory comes in handy and I got it for a great price.
Desktop is a 32GB ECC quad core Haswell Xeon mumble mumble running Windows 8.1, with a pair of 30" 1600p monitors and a 20" 1600x1200. Nice having space to put stuff. Also nice having memory that doesn't silently corrupt itself every few months, you crazy kids and your non-parity.
In case anyone missed it, if you're using one for OpenPGP key use you might be vulnerable to a pin bypass attack. Details on how to check are on that page.
If you have a vulnerable device, YubiCo will send you a free replacement upon request - just open a ticket with your serial and order numbers.
It's not being used as a key. Key stretching would be pointless. You stretch to get a longer key if your goal is to derive a strong key
You want a strong key! Key stretching isn't just about making a physically longer key, it's about making a stronger one, such as by iterating your hash function a million times.
KDFs are for key derivation. That's why they're called key derivation functions. How is that hard to understand.
This is not in question. What is in question is why it's not exactly what you'd want out of a password hashing function - what difference does it make whether you're going to pass it to AES or to a comparison function?
A better choice is a properly vetted hash that's designed as a hash, such as SHA256
... which you then need to, at a minimum, apply salting and key stretching to. Good work, you just rewrote most of PBKDF2, just without the peer review, sane defaults, and for most people, probably in a language where the function call overhead exceeds the cost of the hashing.
Using a KDF as a hash is like using a butter knife as a screwdriver - it gets the job done, and professionals normally use the tool designed for the job rather than substituting.
Hashes are not designed for password storage, that's the entire reason we're having this conversation in the first place. People use KDF's for password storage because that's what they're made for. Anyone who uses a plain old hash has to make a KDF out of it. How are they different?
You want the hash algorithm to be SLOW, not "well optimized"... You don't want it to be computationally complex.
How do you make an algorithm that's slow without being computationally complex? Writing it all in PHP doesn't count.
The algorithm has to be slow because it's a lot of work. Your implementation has to be fast to maximise the security benefit of using it in the first place.
You don't care about turning it into an unpredictable number.
What else do I want a hash function to return?
In fact you sometimes enforce O(1) time, you don't want a longer or different password to take longer to hash, because that facilitates timing attacks.
Pad your inputs and use constant time comparison functions, kids.
Er, not really? You want a well-optimized function to turn a password into a very big unpredictable number in a way that's computationally complex, and that's precisely what KDFs are made to do. The entire crux of your argument against such use seems to boil down to "but they sometimes let you specify how big a number you want", as if this added complexity and risk somehow massively outweighed that created by rolling your own slow crappy little alternative.
I find it odd that the WD drives, at the 5400rpm speed, were able to write data faster than the 7200rpm Seagate drives.
Maybe the Seagates are more sensitive to vibration, either from making more of it when you shove 45 into a cheap metal box, or by being less tolerant to it because they're pushed harder.
I recall reading that the uncorrectable read error rate tends towards the 2TB mark.
12.5TB, assuming the specified 1-in 10^14 bit uncorrectable-read-error rate specified for most consumer drives is accurate. I certainly don't see rates anywhere near that high with my consumer drives, but I could just be lucky.
Slashdot Mirror
The E3 series, the most recent versions released in mid 2012. Use the link you provided and select View All E3. Notice the 2011-12 launch dates.
No, that's the first generation E3's. You'll note the page I actually linked you to shows E3 v5, the "View All" link takes you to the database which can only show one generation at a time and defaults to the oldest.
v5 launch dates are Q4'15 through Q2'16.
And that is how airplanes occasionally crash. Its usually not one flaw or problem, its multiple problems/flaws occurring at the same time
Right, because they have safety systems that cover the typical cases. Apple lack those, so it's not just the convoluted multiple problems piling up that will take out their products, it's simple common ones as well.
There is quite a difference between corrupting the inode info / timestamp info and corrupting the **contents of a file**, its user data. That is what is unique about ZFS. File data being **read** is at risk due to automatic repairs of **user data**.
ZFS repairs using redundant copies of data which don't exist on single-disk configurations. All ZFS will do in such a situation is tell you there's an error in a file it can't correct and suggest you restore it from backup. If it's a transient memory or IO error causing the checksum to fail, a second attempt at reading it should work.
Yes, server grade CPUs support server grade RAM. And judging from Intel's data sheets the current generation Xeons are slower (clock rate, more cores though) and generate more heat
More cores?
And the 4-5 year old Xeons you mention
When did I mention 4-5 year old Xeons? Current prices here:
i7 Skylake, £258-£290 for 2.4-4GHz.
E3 Skylake, £162-£508 for 2.9-3.7GHz. If you forgo 4GHz the Xeons are actually cheaper.
For you it may be a low risk. For Apple its not. Apple will be shipping millions of machines.
And these machines are already vulnerable just to single bit errors anywhere both in the IO path and in memory.
The repair-of-death you describe involves multiple errors in the memory path occurring in a specific order and in relatively specific places, that are already dangerous to existing filesystems.
The atime update metadata corruption you quote is similarly already a problem with existing filesystems. In fact it's more of a problem for these filesystems because they're overwriting existing metadata, not creating new copies of metadata that can be rolled back in a disaster as ZFS does.
Even if we take it as true that ZFS is more vulnerable to these specific types of error (by no means demonstrated), that needs to be balanced against all the other errors it's less vulnerable against.
Stop approaching this from the perspective that ZFS is flawed. Rather approach this from the perspective that ZFS assumes memory can be trusted
... so does every other filesystem. I'll quote another bit of that paper you like:
"In addition to ZFS, we have applied the same fault injection framework used in Section 5 to a simpler filesystem,ext2. Our initial results indicate that ext2 is also vulnerable to memory corruptions. For example, corrupt data can be returned to the user or written to disk. When certain fields of a VFS inode are corrupted, operations on that inode fail or the whole system crashes. If the inode is dirty, the corrupted fields of the VFS inode are propagated to the inode in the page cache and are then written to disk, making the corruptions permanent. Moreover, if the superblock in the page cache is corrupted and flushed to disk, it might result in an unmountable filesystem"
Intel is more likely to support ECC in lower end CPUs (ex i3) than in mid to higher end CPUS (ex i5, i7)
i7-class Xeons (E3-XXXX) support ECC and are usually priced basically identically to their i7 cousins. i3's get used in tiny NAS systems like HP Microservers, probably why they come in ECC variants.
Another difficulty for a consumer oriented company like Apple, making using ECC not really an option for them
I'm sure Apple are more than capable of pushing for it if they considered it a priority. They have the purchasing power, they have the margins, they have the PR to make people wet themselves over the benefits if they so choose.
When checksums fail ZFS will assume the problem is on disk and attempt to "repair" the data on disk. This automatic repair is a great feature, when your RAM can be trusted.
Repair by attempting to correct the data from a redundant location, if one exists, and if its checksum passes. The bit flips required to make such a process actually damage your data seems quite convoluted - it'd have to be multiple errors in different locations happening at just the right times - one in the read before the checksum is checked, one in the data to repair it after the checksum has been verified but before it's written back.
"By default, access time updates are enabled in ZFS; therefore, a read-only workload will update the access time of any file accessed. Consequently, when the structure containing the access time (znode) goes inactive (or when there is another workload that updates the znode), ZFS writes the block holding the znode to disk and updates and writes all its parental blocks. Therefore, any corruption to these blocks will become permanent after the flush caused by the access time update"
In-memory filesystem metadata can get damaged and end up in on-disk structures regardless of which one you use, and it's far from the only fs with atime updates. Is ZFS really significantly more vulnerable to this by comparison, or is it just that ZFS won't defend you against it?
My quick skim of the paper suggests the latter. They don't seem to condemn ZFS for being worse, rather, they show it suffers the same sort of problems they find ext2 suffers from in face of memory errors, while demonstrating it's great at picking up errors from the disk/IO controller/etc.
The problem with zfs clone is that "clones can only be created from a snapshot" which means that deleting a file from a clone does not delete the file from the underlying snapshot, so the space is never actually freed
zfs promote clone-filesystem && zfs destroy clone-filesystem@snapshot-it-was-based-on
Hence why the ZFS filesystem layer is built on top of its volume management layer, and why you manage things like that using the zpool command, not the zfs command.
This is one of the things the Solaris-derived versions have tended to be better at handling - ZFS expects failing drives to be detected/managed by an external fault management service (fmd) which doesn't exist on other OS's. ZFS itself doesn't mark a drive as bad itself unless it outright disappears from the system.
- Mutable snapshots. It is infuriating that ZFS's snapshots are immutable.
Er, snapshots should be immutable. They're used as sources for backups and replication, allowing them to be mutable would defeat the main purpose.
zfs clone if you want a writable copy. What's wrong with that?
ZFS is designed for extremely high quality hardware (and lots of RAM) that doesn't lie to the OS
ZFS is designed to be robust in face of crappy lying disks. That's what all the checksumming and self healing is about - ZFS will cope *far* better with your dire consumer drives than most traditional filesystems. But yes, it likes its RAM, and it likes its redundancy.
That's only a very partial solution - vdev removal, not vdev shrinking. And it's got a pretty meh way of going about it (removing a vdev leaves a permanent layer of redirection in its place).
What we want is something called "block pointer rewriting", which would allow far more flexibility in the modification of an existing pool - possibly even dynamically changing RAID levels on the fly. Unfortunately it's a massive job that nobody's sufficiently interested in solving.
I loath wrappers though as they have a tendency to cost on perfomance an example is Civilization V on Linux is painful compared to windows on trhe same machine.
What makes you think this is the fault of the wrapper rather than just drivers being crap?
My gmail address gets used as a throwaway rather a lot, and you'd be surprised at the number of sites that don't bother at all.
This message was sent to you ($foo@gmail.com) because you are a valued NBA fan registered with us and we wanted to wish you a happy birthday!
Hi meleonaz,
www.skype.com
Registered email successfully updated
Your email address for the account meleonaz has been successfully updated to $foo@gmail.com
Hi @notme345,
We got a request to reset your Instagram password.
Thanks so much for joining Pandora! We're very happy to have you on board, and we look forward to providing you with endless hours of great music listening and discovery.
Many more sites will still create the account and let you use it without me validating the email, and many more provide no means of saying this *isn't* their email.
Because a lot of security boils down to "I'm thinking of a number between 0 and $something, I bet an attacker can't guess it at a rate better than blind chance".
e.g. a 128 bit encryption key is a number between 0 and 340282366920938463463374607431768211455. With a secure random number generator, an attacker will have to on average test half of those possible keys before he finds the correct one, because he can't know anything that will reduce the space he has to search.
If your random number generator is broken - for an extreme example, say you only seed it with a 16-bit process ID - suddenly the random values you generate are trivially guessable, because there's only 65535 possible streams of randomness to check instead of $impossibly_huge_number. What should have taken longer than the age of the universe to crack now takes mere seconds.
Users who upgrade to 10 will have their default browser automatically changed to the new Edge browse
I upgraded and it gave me a clear screen showing the new defaults, and an option to keep my existing ones, which I chose.
After booting, MPC-HC was still my default video player, foobar2000 was still my default music player, and Opera was still my default browser.
Erm, "appending @@<version> to filenames".
DragonFlyBSD's HAMMERFS does much of this - you can examine the version history of files and directories using hammer history and undo commands, and reference versions directly by appending @@ to filenames.
You can control how long history is preserved for and in what level of detail, as well as efficiently replicate it all across the network to remote filesystems (which can have their own, different rules). All this in addition to the more traditional named snapshots approach you're limited to with, e.g. ZFS.
https://www.dragonflybsd.org/d...
Their mobile client is open source: https://github.com/SpiderOak/S...
The desktop client is mostly unobfuscated Python bytecode and easily inspected, docstrings, symbol names and all, with a bytecode decompiler. Not good enough, but at least a bit more transparent than most.
Guess that has to be my main server, even though it's a few generations older than my desktop, it has more cores, more IO, more memory and more storage. It runs FreeBSD.
Case: SuperChassis 745TQ-R800B (pic)
Motherboard: Supermicro X8DTN+
CPUs: 2 x 6-core Xeon L5639 @ 2.13GHz
RAM: 144GB - 9 x 16GB DDR3-1333 ECC Reg
Primary Storage: 2 x SanDisk Extreme Pro 960GB, ZFS mirror.
Mass Storage: 6 x 5TB Toshiba MD04ACA5, ZFS 3 x mirror.
Disk controller: IBM M1015, seems one of the most favoured HBA's these days.
Keyboard: NTC KB-6153EA with clicky White Alps.
I play with search engines and stuff, the memory comes in handy and I got it for a great price.
Desktop is a 32GB ECC quad core Haswell Xeon mumble mumble running Windows 8.1, with a pair of 30" 1600p monitors and a 20" 1600x1200. Nice having space to put stuff. Also nice having memory that doesn't silently corrupt itself every few months, you crazy kids and your non-parity.
In case anyone missed it, if you're using one for OpenPGP key use you might be vulnerable to a pin bypass attack. Details on how to check are on that page.
If you have a vulnerable device, YubiCo will send you a free replacement upon request - just open a ticket with your serial and order numbers.
It's not being used as a key. Key stretching would be pointless. You stretch to get a longer key if your goal is to derive a strong key
You want a strong key! Key stretching isn't just about making a physically longer key, it's about making a stronger one, such as by iterating your hash function a million times.
KDFs are for key derivation. That's why they're called key derivation functions. How is that hard to understand.
This is not in question. What is in question is why it's not exactly what you'd want out of a password hashing function - what difference does it make whether you're going to pass it to AES or to a comparison function?
A better choice is a properly vetted hash that's designed as a hash, such as SHA256
... which you then need to, at a minimum, apply salting and key stretching to. Good work, you just rewrote most of PBKDF2, just without the peer review, sane defaults, and for most people, probably in a language where the function call overhead exceeds the cost of the hashing.
Using a KDF as a hash is like using a butter knife as a screwdriver - it gets the job done, and professionals normally use the tool designed for the job rather than substituting.
Hashes are not designed for password storage, that's the entire reason we're having this conversation in the first place. People use KDF's for password storage because that's what they're made for. Anyone who uses a plain old hash has to make a KDF out of it. How are they different?
Yes, I used "computationally complex" to mean "takes a lot of steps to complete". You and your "words mean stuff", stop evading the point.
Why is a KDF like PBKDF2, bcrypt or scrypt, a poorer option for password storage than rolling your own? Please use words which mean stuff.
You want the hash algorithm to be SLOW, not "well optimized" ... You don't want it to be computationally complex.
How do you make an algorithm that's slow without being computationally complex? Writing it all in PHP doesn't count.
The algorithm has to be slow because it's a lot of work. Your implementation has to be fast to maximise the security benefit of using it in the first place.
You don't care about turning it into an unpredictable number.
What else do I want a hash function to return?
In fact you sometimes enforce O(1) time, you don't want a longer or different password to take longer to hash, because that facilitates timing attacks.
Pad your inputs and use constant time comparison functions, kids.
Er, not really? You want a well-optimized function to turn a password into a very big unpredictable number in a way that's computationally complex, and that's precisely what KDFs are made to do. The entire crux of your argument against such use seems to boil down to "but they sometimes let you specify how big a number you want", as if this added complexity and risk somehow massively outweighed that created by rolling your own slow crappy little alternative.
I find it odd that the WD drives, at the 5400rpm speed, were able to write data faster than the 7200rpm Seagate drives.
Maybe the Seagates are more sensitive to vibration, either from making more of it when you shove 45 into a cheap metal box, or by being less tolerant to it because they're pushed harder.
I recall reading that the uncorrectable read error rate tends towards the 2TB mark.
12.5TB, assuming the specified 1-in 10^14 bit uncorrectable-read-error rate specified for most consumer drives is accurate. I certainly don't see rates anywhere near that high with my consumer drives, but I could just be lucky.