Re: [zfs-macos] What's zpool version 5000?!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.02.14 23:27, schrieb Daniel Jozsef: > Hey ppl ;) I've been wondering about "version 5000", and what it > signifies. Does this bump mean a fork from Oracle's code? Will > there be a 5001, 5002, 5099, etc. in the future, on a path separate > and incompatible from Oracle's versions? Or is it just some kind of > nonsense number, like setting Samba OS level to MAXINT? :) Is v5000 > identical to v28 or does it indicate some kind of incremental > update to 28? the pool version 5000 indicates pools that support the so-called feature flags. A version 5000 pool with no specific features turned on is essentially a v28 pool with the same on-disk data layout. Feature flags are a way to solve the problem of potentially incompatible changes to the on-disk data structures in the absence of a central authority that defines what a given version of the software should support. Instead of incrementing the pool version by one every time an incompatible change occurred and coordinating the version increase across all independent implementations of ZFS, now any implementation can define new features that are supported by that implementation and possibly some other implementations that pickup the change. Such a pool can be imported read-only by any implementation that support reading all features active in the pool and read-write by any implementation that support writing all active features. Some features are defined as only requiring implementation support for writing, that is a pool with such a feature active can be imported read-only by an implementation that has no support for the feature. Since feature are technically pool properties, there is no reason to ever again increase the pool version to support new features. As such, the "5000" in pool version 5000 is just an arbitrary number made up to distinguish feature flag enabled pools from legacy Oracle pools. Hope that clarifies it a bit. Björn - -- | Bjoern Kahl +++ Siegburg +++Germany | | "googlelogin@-my-domain-" +++ www.bjoern-kahl.de | | Languages: German, English, Ancient Latin (a bit :-)) | -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAgUBUw/JAFsDv2ib9OLFAQJRSAP9HtM4vSqRUgDrjlxNrH+Yh5xYZewMBpJV RUkXYJkapGqioOJjsifo/mxmXTj81eSVjeKaCl0h5ToPbfCJ14FC3soyeJ3E9DkG xhp5TbxRY4fWYiSACqO42hgt9hgSNQD0WGLzdOp73HtyG4tt7Rc5+PmLughbsHfM YtoS7N72Rzo= =QYf+ -END PGP SIGNATURE- -- --- You received this message because you are subscribed to the Google Groups "zfs-macos" group. To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[zfs-macos] What's zpool version 5000?!
Hey ppl ;) I've been wondering about "version 5000", and what it signifies. Does this bump mean a fork from Oracle's code? Will there be a 5001, 5002, 5099, etc. in the future, on a path separate and incompatible from Oracle's versions? Or is it just some kind of nonsense number, like setting Samba OS level to MAXINT? :) Is v5000 identical to v28 or does it indicate some kind of incremental update to 28? -- --- You received this message because you are subscribed to the Google Groups "zfs-macos" group. To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data
Wouldn't ZFS actually make things better as opposed to worse? Say I have a Macbook with failing memory, and there's a magnetic storm. If I was using HFS+, with each write I'd be seeding the drive with bit errors, without ever noticing until the system crashes. If the bit error happens infrequently, the data corruption would likely be propagated to any backup I maintain. With ZFS, the bit error would likely result in me being alerted of a corruption, and even if error correction "fixed" the data on the drive, this would result in an inconsistent state, and soon ZFS would take the drive offline due to fault threshold, and the system would crash. Then I would know that the data is damaged, and I could restore from backup after replacing the memory. (And of course, ZFS protects me from the much more common hard drive bit errors.) I don't see how this isn't awesome. -- --- You received this message because you are subscribed to the Google Groups "zfs-macos" group. To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data
Why is this a zfs issue. If you have bad ram data, the OS is compromised already. Where is the blame supposed to be. ZFS is not an OS and is has to trust some api's it calls to actually perform work. -- --- You received this message because you are subscribed to the Google Groups "zfs-macos" group. To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [zfs-macos] ZFS w/o ECC RAM -> Total loss of data
On Feb 26, 2014, at 10:51 PM, Daniel Becker wrote: > Incidentally, that paper came up in a ZFS-related thread on Ars Technica just > the other day (as did the link to the FreeNAS forum post). Let me just quote > what I said there: > >> The conclusion of the paper is that ZFS does not protect against in-memory >> corruption, and thus can't provide end-to-end integrity in the presence of >> memory errors. I am not arguing against that at all; obviously you'll want >> ECC on your ZFS-based server if you value data integrity -- just as you >> would if you were using any other file system. That doesn't really have >> anything to do with the claim that ZFS specifically makes lack of ECC more >> likely to cause total data loss, though. > > The sections you quote below basically say that while ZFS offers good > protection against on-disk corruption, it does *not* effectively protect you > against memory errors. Or, put another way, the authors are basically finding > that despite all the FS-level checksumming, ZFS does not render ECC memory > unnecessary (as one might perhaps naively expect). No claim is being made > that memory errors affect ZFS more than other filesystems. Yes. Just like anything else, end-to-end data integrity is needed. So until people write apps that self-check everything, there is a possibility that something you trust [1] can fail. As it happens, only the PC market demands no ECC. TANSTAAFL. [1] http://en.wikipedia.org/wiki/Pentium_FDIV_bug -- richard -- --- You received this message because you are subscribed to the Google Groups "zfs-macos" group. To unsubscribe from this group and stop receiving emails from it, send an email to zfs-macos+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
