I'm sure there are both genetic and environmental causes even for twin studies, and there is also epigenetics (which can be partially environmental as well).
I just don't know that you can conclude much from this study. If your "intelligence" were 100% determined by genes, but there were 1000 genes involved and none of them had more than a 0.1% contribution to your "intelligence" you'd never expect a study like this to show anything. Then factor in that we can argue all day about what intelligence is in the first place...
Well, I'd take "production-ready" with a heavy grain of salt. If you stick to the features that aren't too new it is pretty decent, but the 3.15 kernel series had issues with deadlocks when using compress=lzo (just fixed in 3.16.2), and while that sort of thing isn't too common it happens. The checksumming does provide a pretty high level of data integrity - if you have issues most likely it will be more about hangs/crashes/etc, and not so much about major loss of data. The one big gaping hole in btrfs is that it does not behave well when space gets tight - it can be tricky to recover if the filesystem runs out of space to allocate metadata (since it is COW, even deleting files requires empty metadata space to function).
However, it is certainly well-worth playing around with, especially if you're interested in storage (and I'd certainly say the same about zfs). The box I'm typing this on uses a non-redundant btrfs root partition on an SSD (btrfs handles SSD well), and a 5-disk RAID1 on btrfs for everything else. I rsnapshot all of that stuff to ext4 daily on another drive, so I'm not too concerned about issues. I'm doing this half for the learning, but it is REALLY nice to be able to just snapshot a container/etc before I do an update on it (as with zfs snapshots on btrfs take almost zero time), and it is also nice to have my cp aliased with --reflink=auto - I'm not sure if zfs on linux supports that yet but reflinks on linux are basically a file-level COW snapshot (it isn't quite as fast as a regular snapshot since all the file metadata for the file needs to be copied if it has multiple extents - with a subvolume there is a pointer into the b-tree that allows a snapshot to be made by copying one record and incrementing the reference count of the record it points to - kind of like making two tags for the same commit in git).
In theory I'd get much better performance if I did my backups with send/receive, but I use rsnapshot so that my backups don't depend on any btrfs magic to work.
You can definitely point btrfs at a loopback device. That is an easy way to get into it. Ages ago I actually got a kernel panic when trying to do this with an ext4 conversion, but I think those issues are ancient history.
Btrfs RAID5 won't have a write hole. It is fairly equivalent to zfs RAID-Z.
Right now the btrfs raid5 code doesn't recover from any kind of disk failure at all - it is experimental (that is, it writes parity to disk, but cannot use it to recover missing data). All data written to each disk are checksumed, so in the event of a problem during write the filesystem can determine which disks are correct and which ones aren't. Also, like zfs btrfs does not overwrite data in-place, so in the event of a failure files should end up in either the pre-write or post-write state.
I couldn't find any official docs about raid5 on btrfs at all - it is still experimental. Mailing list posts seem to suggest that it will not have the write hole when complete (such as http://comments.gmane.org/gman... ).
Now, I'm talking about btrfs directly writing to disks. If you stick mdadm in-between btrfs and the disks (avoiding the layering violation), then the result will be the same as if you stick mdadm between zfs and the disks - you'll have the write hole. The same layering violation concerns that apply to zfs also apply to btrfs as it also does volume management, raid, disk management, etc. If you run a scrub on btrfs or rebuild a disk it will only scrub/rebuild the blocks that are actually in use, etc.
I won't argue that btrfs on the whole is nowhere near as stable as zfs is currently, but most of the key features are very similar. They are both COW filesystems that are designed to run directly against disks, they both checksum all data to protect against on-disk modification and the write-hole, they both utilize their knowledge of what is on the disk to optimize how things like striping/parity are done, they both support very cheap snapshots, etc.
Anybody interested in storage at a low level would do well to have at least a general familiarity of both, regardless of preference.
With btrfs I can do this while letting it have the entire drive - there are no partitions involved. You just feed it drives, and it maximizes space use. Btrfs does mirroring at the chunk level (I forget how large a chunk is but it is hundreds of MB to GB size), and not at the drive/etc level. This is why it is a lot more flexible - imagine that vdevs aren't a collection of drives, but that each vdev is maybe a few GB of data that is spread across multiple drives, and drives are just collections of hundreds/thousands of parts of vdevs. You could do this on zfs if you divided each drive into 1000 partitions and made 1000 vdevs out of each drive, and then you'd probably have a lot more flexibility about moving data around.
At the enterprise level that granularity probably isn't needed. On the other hand, at the workstation level it is a lot more useful.
RAID-Z, yes (but more flexible, though it is experimental and definitely not usable yet), RAID1 is production-ready (and it works like RAID-Z, not like traditional Raid1). ZIL does not exist at all yet. Dedupe does exist.
It is a COW filesystem that does checksumming of all blocks/etc, manages storage pools, doesn't have the RAID write hole, etc, just like ZFS. It tends to be more flexible as you don't have the limitation of being unable to add drives to a "vdev." However, it is far less mature and many features are still just on the roadmap.
Right now my one RAID1 has 4x1TB drive and 1x3TB drive, with 3.5TB of usable space. This is because RAID is implemented at the chunk level, not the drive level, so that 3TB drive can be mirrored across all the other drives (of course, that makes it a bit of a bottleneck for writes). I could covert that to a RAID5 (which is basically the equivalent of RAIDZ in zfs) without having to rewrite all the data - the already-written chunks would just stay in raid1 mode and new chunks would be allocated in raid5 mode unless I told the filesystem to migrate everything.
In general I think the design of btrfs is a bit more flexible. However, it is far less mature and in particular the more "enterprise-oriented" features tend to be lacking as they aren't a priority. They're really focused on different audiences.
Not something I would attempt. Personally, I accept this limitation and always add drives in pairs. Upgrading capacity then becomes a 2-drive cost instead of a number_of_disks_in_raid cost.
I've never replaced all my disks in a raid at the same time. When I ran mdadm I would just partition the disks so that I was running multiple raid5s on each drive (so if I had 3x1TB and 2x3TB drives I'd have 6TB of usable space - 4x1TB+1x2TB). With btrfs I'd just put them all in an array and let btrfs figure out how to use it once raid5 mode was mature (actually, I should look into how btrfs will handle mixed sizes in raid5 mode - it generally does the right thing in raid1, but I suspect it will need help in parity modes).
Agree - I phrased my original question poorly. My point was that raidz was not as flexible as the roadmap raid5 support for btrfs (which behaves like raidz, not like raid5 in zfs). I'm interested in being able to add/remove individual drives to a parity array.
A couple hundred bucks is more than the cost of all the hard drives I own.:)
I think that is where the gap lies. The designers of ZFS are marketing towards people who manage at least dozens of disks, and they really don't need the features I'm talking about. On the other hand, if you own a grand total of 3x1TB drives and you want to add 1TB of storage, and you don't own a tape drive or any other spare media, then backup, destory, restore isn't a viable option.
I'm running full backups only because I'm experimenting with btrfs and don't trust the filesystem to not eat my data. However, I don't plan to do that for the long-term and at some point I'll probably move my backup drives into my storage array. At that point most of my data won't have backups at all. Everything I REALLY care about is backed up offsite daily, but it isn't more than a few GB of storage. If I lose a few hundred hours of MythTV video it isn't the end of the world, but that doesn't mean that I want to wipe my system every time I want to add a disk.
The whole point of btrfs (or mdadm for that matter) is that I don't have to plan better next time.
I understand that. If you have 25 drives that is probably all the flexibility you need. On the other hand, if you have 3x1TB drives (2TB usable, 1TB parity), and you'd like to add 1 more 1TB drive so as to have 3TB usable, 1TB parity, then being able to add additional vdevs doesn't buy you anything, unless you want to make that 1TB drive non-redundant. You could add 2x1TB in a mirrored configuration and get 1TB space, but if you could reshape the array you'd get that 1TB space for the cost of a single drive.
For the more casual user, that flexibility matters more. If you're running a SAN with 50 drives in it, then you're not going to have one big raid-z across all of them for performance reasons if nothing else. You could have 10x5 disk arrays, and adding another 5-disk array is easy.
Haha, and conversely ZFS' "rampant layering violations" approach confers advantages that btrfs cannot match.
What advantage does ZFS have over btrfs, other than maturity? You do realize that both are virtually identical as far as "rampant layering violations" go, right?
Yup - disk failure isn't really implemented yet in btrfs. You get the behavior you describe for raid1 mode, and for the parity raid modes it doesn't handle recovery at all yet. I'd be reluctant to run it in a server I didn't babysit for that reason.
With mdadm if a drive fails I get messages to dmesg, and it has a daemon that will happily send mail/logs/etc wherever I want it to go. I think btrfs might output a line to dmesg but it would be VERY easy to miss a degraded array, and that is a problem.
But, I chalk that up to btrfs not being done yet. When it will be done is very much a matter of speculation.
What you propose requires doubling the cost of storage. I realize that CPU is cheap, RAM is cheap, storage is cheap, and so on. But, for whatever reason it seems like everybody selling all this "cheap" stuff still wants my credit card number.
With RAID5 the dollar cost of parity isn't nearly as significant. Sure, it might not perform quite as well, but until you start getting into the 20-30 drive scenario performance of spinning disks is always going to be lousy. Unless you're running VMs on the disks, it probably doesn't matter, since most of the stuff that takes lots of space (video) tends to be rarely accessed, and only sequentially.
Well, encrypting stuff isn't necessarily hard. What gets hard is managing the keys when you do it competently.
If you just take somebody's screen lock PIN, hash it, and use it as the key, well, that would be trivial to crack which is why android's built-in encryption is useless.
Likewise, if you want to keep things secure but allow for users to forget their passphrase, that isn't easy either.
Agree 100%. I had a similar conversation with a zfs proponent in my local linux user group. The zfs design makes a lot more sense when you think about enterprise storage. Btrfs is targeted as being more of an ext4 replacement, where you aren't managing groups of 5 disks in a unit with 100 disks.
I'm not intimately familiar with all the details of raidz, but I believe what btrfs calls raid5/6 is roughly equivalent to raidz/2. It involves n+1/2 redundancy but with chunk-level allocation/striping instead of having it at the physical layer (so no raid hole, can have multiple raid modes on the same physical partitions, can operate with mixed-size media, etc). If anything it should be more flexible than raidz because you can add/remove individual drives at will, and convert a raid1 to raid5 in-place without rewriting anything (existing chunks stay raid1, new ones are written as raid5, unless you rebalance).
Of course, this is all roadmap. Raid5/6 is still experimental, and in particular it doesn't actually recover from a disk loss at this point, so I really do MEAN experimental.
From a VERY brief perusal of "datasets" on zfs they appear to be similar to btrfs subvolumes. In btrfs these certainly can be nested, however if you snapshot a subvolume the snapshot does NOT contain the nested subvolumes. That can be useful for some things, but I imagine it could also be less than useful for others - I had to design my use of subvolumes around this. For example, if/home is a subvolume and every user is a subvolume, then you could have per-user-dir quotas easily enough and per-user snapshots, but if you do a snapshot of/home chances are you won't have anything in it but a bunch of empty user directories.
Yeah, I was wondering that as well. How does that show up on the balance sheet? Do you put in the annual statement "Risks may or may not include failure to cooperate with a request to disclose data that the government may or may not have made, which may or may not have resulted in millions of dollars in fines?"
Well, you can believe whatever you want. Real world experience has shown me one of those things is at least 3 orders of magnitude more likely than the other. Guess which.
I think you missed the point. There will ALWAYS be some situation where you can gain another 9 in reliability by adding another zero or two to the price tag. I don't debate that ECC RAM is a more cost-effective solution than a hardware architecture that tolerates CPU errors.
No, the insinuation is that ZFS is approximately a decade more mature and proven than that upstart knockoff, btrfs.
If they had only BSD licensed it, the latter might never have been built.:) Just another case of qt syndrome I guess.
Btrfs does have a few advantages - it is a bit more flexible in some respects, mostly in areas where the more enterprise-y ZFS audience isn't going to care.
True. Now, what if you wanted to add 1 3TB drive to the existing 3x1TB RAID-Z, so that instead of having 2TB of usable space it now has 3TB of usable space?
Maybe collectively they have an effect that can't be detected statistically.
If it can't be detected statistically, how can it be detected?
I never claimed that it could be detected. That doesn't mean that it isn't there.
Also, this is about finding a needle in a haystack. You might not be able to find a needle in a haystack, but if you give me a haystack containing a needle, and I find the needle, you probably could easily determine if what I found was actually a needle. Testing for the affect of a single gene on a single carefully-defined trait is much easier - fewer degrees of freedom mean fewer datapoints needed to detect an effect.
Apple could go a long way toward protecting customer privacy just by adding a second credential to encrypt stored iCloud data. An encryption password could be used to decrypt the backup when downloaded to iTunes or to the device, or it could be used to decrypt the data as it is read by iCloud to stream down to the device.
I forgot my iPhone password, and those lousy Apple folks refused to reset it for me. They just said some kind of technobabble about encryption and security. Why did they make iPhones harder to use? Isn't Apple supposed to be easy to figure out?
You can't have it both ways. I encrypt all my sensitive data that I back up to the cloud, but I also keep copies of the key in safe places so that when my house burns down I don't lose access to my offsite backups along with it. I wouldn't expect the average iCloud user to appreciate the need for this, and neither does Apple, so their backups aren't encrypted.
Slashdot Mirror
I'm sure there are both genetic and environmental causes even for twin studies, and there is also epigenetics (which can be partially environmental as well).
I just don't know that you can conclude much from this study. If your "intelligence" were 100% determined by genes, but there were 1000 genes involved and none of them had more than a 0.1% contribution to your "intelligence" you'd never expect a study like this to show anything. Then factor in that we can argue all day about what intelligence is in the first place...
Well, I'd take "production-ready" with a heavy grain of salt. If you stick to the features that aren't too new it is pretty decent, but the 3.15 kernel series had issues with deadlocks when using compress=lzo (just fixed in 3.16.2), and while that sort of thing isn't too common it happens. The checksumming does provide a pretty high level of data integrity - if you have issues most likely it will be more about hangs/crashes/etc, and not so much about major loss of data. The one big gaping hole in btrfs is that it does not behave well when space gets tight - it can be tricky to recover if the filesystem runs out of space to allocate metadata (since it is COW, even deleting files requires empty metadata space to function).
However, it is certainly well-worth playing around with, especially if you're interested in storage (and I'd certainly say the same about zfs). The box I'm typing this on uses a non-redundant btrfs root partition on an SSD (btrfs handles SSD well), and a 5-disk RAID1 on btrfs for everything else. I rsnapshot all of that stuff to ext4 daily on another drive, so I'm not too concerned about issues. I'm doing this half for the learning, but it is REALLY nice to be able to just snapshot a container/etc before I do an update on it (as with zfs snapshots on btrfs take almost zero time), and it is also nice to have my cp aliased with --reflink=auto - I'm not sure if zfs on linux supports that yet but reflinks on linux are basically a file-level COW snapshot (it isn't quite as fast as a regular snapshot since all the file metadata for the file needs to be copied if it has multiple extents - with a subvolume there is a pointer into the b-tree that allows a snapshot to be made by copying one record and incrementing the reference count of the record it points to - kind of like making two tags for the same commit in git).
In theory I'd get much better performance if I did my backups with send/receive, but I use rsnapshot so that my backups don't depend on any btrfs magic to work.
You can definitely point btrfs at a loopback device. That is an easy way to get into it. Ages ago I actually got a kernel panic when trying to do this with an ext4 conversion, but I think those issues are ancient history.
Btrfs RAID5 won't have a write hole. It is fairly equivalent to zfs RAID-Z.
Right now the btrfs raid5 code doesn't recover from any kind of disk failure at all - it is experimental (that is, it writes parity to disk, but cannot use it to recover missing data). All data written to each disk are checksumed, so in the event of a problem during write the filesystem can determine which disks are correct and which ones aren't. Also, like zfs btrfs does not overwrite data in-place, so in the event of a failure files should end up in either the pre-write or post-write state.
I couldn't find any official docs about raid5 on btrfs at all - it is still experimental. Mailing list posts seem to suggest that it will not have the write hole when complete (such as http://comments.gmane.org/gman... ).
Now, I'm talking about btrfs directly writing to disks. If you stick mdadm in-between btrfs and the disks (avoiding the layering violation), then the result will be the same as if you stick mdadm between zfs and the disks - you'll have the write hole. The same layering violation concerns that apply to zfs also apply to btrfs as it also does volume management, raid, disk management, etc. If you run a scrub on btrfs or rebuild a disk it will only scrub/rebuild the blocks that are actually in use, etc.
I won't argue that btrfs on the whole is nowhere near as stable as zfs is currently, but most of the key features are very similar. They are both COW filesystems that are designed to run directly against disks, they both checksum all data to protect against on-disk modification and the write-hole, they both utilize their knowledge of what is on the disk to optimize how things like striping/parity are done, they both support very cheap snapshots, etc.
Anybody interested in storage at a low level would do well to have at least a general familiarity of both, regardless of preference.
With btrfs I can do this while letting it have the entire drive - there are no partitions involved. You just feed it drives, and it maximizes space use. Btrfs does mirroring at the chunk level (I forget how large a chunk is but it is hundreds of MB to GB size), and not at the drive/etc level. This is why it is a lot more flexible - imagine that vdevs aren't a collection of drives, but that each vdev is maybe a few GB of data that is spread across multiple drives, and drives are just collections of hundreds/thousands of parts of vdevs. You could do this on zfs if you divided each drive into 1000 partitions and made 1000 vdevs out of each drive, and then you'd probably have a lot more flexibility about moving data around.
At the enterprise level that granularity probably isn't needed. On the other hand, at the workstation level it is a lot more useful.
RAID-Z, yes (but more flexible, though it is experimental and definitely not usable yet), RAID1 is production-ready (and it works like RAID-Z, not like traditional Raid1). ZIL does not exist at all yet. Dedupe does exist.
It is a COW filesystem that does checksumming of all blocks/etc, manages storage pools, doesn't have the RAID write hole, etc, just like ZFS. It tends to be more flexible as you don't have the limitation of being unable to add drives to a "vdev." However, it is far less mature and many features are still just on the roadmap.
Right now my one RAID1 has 4x1TB drive and 1x3TB drive, with 3.5TB of usable space. This is because RAID is implemented at the chunk level, not the drive level, so that 3TB drive can be mirrored across all the other drives (of course, that makes it a bit of a bottleneck for writes). I could covert that to a RAID5 (which is basically the equivalent of RAIDZ in zfs) without having to rewrite all the data - the already-written chunks would just stay in raid1 mode and new chunks would be allocated in raid5 mode unless I told the filesystem to migrate everything.
In general I think the design of btrfs is a bit more flexible. However, it is far less mature and in particular the more "enterprise-oriented" features tend to be lacking as they aren't a priority. They're really focused on different audiences.
> That's what snapper is for.
Does snapper work with ZFS?
No idea, but I'm sure you could make it work. I use it all the time with btrfs.
Not something I would attempt. Personally, I accept this limitation and always add drives in pairs. Upgrading capacity then becomes a 2-drive cost instead of a number_of_disks_in_raid cost.
I've never replaced all my disks in a raid at the same time. When I ran mdadm I would just partition the disks so that I was running multiple raid5s on each drive (so if I had 3x1TB and 2x3TB drives I'd have 6TB of usable space - 4x1TB+1x2TB). With btrfs I'd just put them all in an array and let btrfs figure out how to use it once raid5 mode was mature (actually, I should look into how btrfs will handle mixed sizes in raid5 mode - it generally does the right thing in raid1, but I suspect it will need help in parity modes).
Agree - I phrased my original question poorly. My point was that raidz was not as flexible as the roadmap raid5 support for btrfs (which behaves like raidz, not like raid5 in zfs). I'm interested in being able to add/remove individual drives to a parity array.
A couple hundred bucks is more than the cost of all the hard drives I own. :)
I think that is where the gap lies. The designers of ZFS are marketing towards people who manage at least dozens of disks, and they really don't need the features I'm talking about. On the other hand, if you own a grand total of 3x1TB drives and you want to add 1TB of storage, and you don't own a tape drive or any other spare media, then backup, destory, restore isn't a viable option.
I'm running full backups only because I'm experimenting with btrfs and don't trust the filesystem to not eat my data. However, I don't plan to do that for the long-term and at some point I'll probably move my backup drives into my storage array. At that point most of my data won't have backups at all. Everything I REALLY care about is backed up offsite daily, but it isn't more than a few GB of storage. If I lose a few hundred hours of MythTV video it isn't the end of the world, but that doesn't mean that I want to wipe my system every time I want to add a disk.
The whole point of btrfs (or mdadm for that matter) is that I don't have to plan better next time.
I understand that. If you have 25 drives that is probably all the flexibility you need. On the other hand, if you have 3x1TB drives (2TB usable, 1TB parity), and you'd like to add 1 more 1TB drive so as to have 3TB usable, 1TB parity, then being able to add additional vdevs doesn't buy you anything, unless you want to make that 1TB drive non-redundant. You could add 2x1TB in a mirrored configuration and get 1TB space, but if you could reshape the array you'd get that 1TB space for the cost of a single drive.
For the more casual user, that flexibility matters more. If you're running a SAN with 50 drives in it, then you're not going to have one big raid-z across all of them for performance reasons if nothing else. You could have 10x5 disk arrays, and adding another 5-disk array is easy.
Haha, and conversely ZFS' "rampant layering violations" approach confers advantages that btrfs cannot match.
What advantage does ZFS have over btrfs, other than maturity? You do realize that both are virtually identical as far as "rampant layering violations" go, right?
Yup - disk failure isn't really implemented yet in btrfs. You get the behavior you describe for raid1 mode, and for the parity raid modes it doesn't handle recovery at all yet. I'd be reluctant to run it in a server I didn't babysit for that reason.
With mdadm if a drive fails I get messages to dmesg, and it has a daemon that will happily send mail/logs/etc wherever I want it to go. I think btrfs might output a line to dmesg but it would be VERY easy to miss a degraded array, and that is a problem.
But, I chalk that up to btrfs not being done yet. When it will be done is very much a matter of speculation.
What you propose requires doubling the cost of storage. I realize that CPU is cheap, RAM is cheap, storage is cheap, and so on. But, for whatever reason it seems like everybody selling all this "cheap" stuff still wants my credit card number.
With RAID5 the dollar cost of parity isn't nearly as significant. Sure, it might not perform quite as well, but until you start getting into the 20-30 drive scenario performance of spinning disks is always going to be lousy. Unless you're running VMs on the disks, it probably doesn't matter, since most of the stuff that takes lots of space (video) tends to be rarely accessed, and only sequentially.
Are you saying that intelligence doesn't exist?
That is a bit like saying "mental illness" doesn't exist, simply because we find it really hard to categorize.
Well, encrypting stuff isn't necessarily hard. What gets hard is managing the keys when you do it competently.
If you just take somebody's screen lock PIN, hash it, and use it as the key, well, that would be trivial to crack which is why android's built-in encryption is useless.
Likewise, if you want to keep things secure but allow for users to forget their passphrase, that isn't easy either.
Agree 100%. I had a similar conversation with a zfs proponent in my local linux user group. The zfs design makes a lot more sense when you think about enterprise storage. Btrfs is targeted as being more of an ext4 replacement, where you aren't managing groups of 5 disks in a unit with 100 disks.
I'm not intimately familiar with all the details of raidz, but I believe what btrfs calls raid5/6 is roughly equivalent to raidz/2. It involves n+1/2 redundancy but with chunk-level allocation/striping instead of having it at the physical layer (so no raid hole, can have multiple raid modes on the same physical partitions, can operate with mixed-size media, etc). If anything it should be more flexible than raidz because you can add/remove individual drives at will, and convert a raid1 to raid5 in-place without rewriting anything (existing chunks stay raid1, new ones are written as raid5, unless you rebalance).
Of course, this is all roadmap. Raid5/6 is still experimental, and in particular it doesn't actually recover from a disk loss at this point, so I really do MEAN experimental.
From a VERY brief perusal of "datasets" on zfs they appear to be similar to btrfs subvolumes. In btrfs these certainly can be nested, however if you snapshot a subvolume the snapshot does NOT contain the nested subvolumes. That can be useful for some things, but I imagine it could also be less than useful for others - I had to design my use of subvolumes around this. For example, if /home is a subvolume and every user is a subvolume, then you could have per-user-dir quotas easily enough and per-user snapshots, but if you do a snapshot of /home chances are you won't have anything in it but a bunch of empty user directories.
Yeah, I was wondering that as well. How does that show up on the balance sheet? Do you put in the annual statement "Risks may or may not include failure to cooperate with a request to disclose data that the government may or may not have made, which may or may not have resulted in millions of dollars in fines?"
I think this is time to invoke Carl Sagan's dragon in the garage. If there's no detectable effects, why on earth would we conclude it exists?
Twin studies are highly suggestive of intelligence having a genetic component. That doesn't mean that you can figure out which gene is responsible.
Well, you can believe whatever you want.
Real world experience has shown me one of those things is at least 3 orders of magnitude more likely than the other.
Guess which.
I think you missed the point. There will ALWAYS be some situation where you can gain another 9 in reliability by adding another zero or two to the price tag. I don't debate that ECC RAM is a more cost-effective solution than a hardware architecture that tolerates CPU errors.
No, the insinuation is that ZFS is approximately a decade more mature and proven than that upstart knockoff, btrfs.
If they had only BSD licensed it, the latter might never have been built. :) Just another case of qt syndrome I guess.
Btrfs does have a few advantages - it is a bit more flexible in some respects, mostly in areas where the more enterprise-y ZFS audience isn't going to care.
True. Now, what if you wanted to add 1 3TB drive to the existing 3x1TB RAID-Z, so that instead of having 2TB of usable space it now has 3TB of usable space?
Maybe collectively they have an effect that can't be detected statistically.
If it can't be detected statistically, how can it be detected?
I never claimed that it could be detected. That doesn't mean that it isn't there.
Also, this is about finding a needle in a haystack. You might not be able to find a needle in a haystack, but if you give me a haystack containing a needle, and I find the needle, you probably could easily determine if what I found was actually a needle. Testing for the affect of a single gene on a single carefully-defined trait is much easier - fewer degrees of freedom mean fewer datapoints needed to detect an effect.
Apple could go a long way toward protecting customer privacy just by adding a second credential to encrypt stored iCloud data. An encryption password could be used to decrypt the backup when downloaded to iTunes or to the device, or it could be used to decrypt the data as it is read by iCloud to stream down to the device.
I forgot my iPhone password, and those lousy Apple folks refused to reset it for me. They just said some kind of technobabble about encryption and security. Why did they make iPhones harder to use? Isn't Apple supposed to be easy to figure out?
You can't have it both ways. I encrypt all my sensitive data that I back up to the cloud, but I also keep copies of the key in safe places so that when my house burns down I don't lose access to my offsite backups along with it. I wouldn't expect the average iCloud user to appreciate the need for this, and neither does Apple, so their backups aren't encrypted.
ZFS on Linux would be cooler if they could port Time Slider to Linux from Open Solaris. http://java.dzone.com/news/kil...
That's what snapper is for.