-
Notifications
You must be signed in to change notification settings - Fork 4
Conversation
This commit tries to implement the ashift pool property as used in ZFSonLinux and the ZEVO beta releases. It is based on the ZFSonLinux implementation, and follows this comment: openzfs/zfs#195 (comment) and the resulting final patch for ZFSonLinux found here: openzfs/zfs@df30f56 The original inventors are - Darik Horn <[email protected]> - Richard Laager <[email protected]> - Christian Kohlschütter <[email protected]> Due to the large distance between macZFS and ZFSonLinux (pool version 8 vs. 28) it was necessary to redo and adapt their approach instead of just copying the changes. Note that this solution is technical not fully correct: (a) it introduces a pool property that should not exist in pool version 8 (b) it introduces a new property type, PROP_ONTIME that should not exist in pool version 8 (c) the ashift value is really a property of individual top-level vdevs, and not a pool-wide value. A pool can (and should under certain conditions) have top-level vdevs of different block size. However, using a pool-wide property is what other implementations do, so we do the same for the sake of compatibility.
If have ported this changes over to your untested, to be found here: The diff untested_ashift to untested is smaller then the diff maczfs_74+ashift to maczfs_74, because maczfs_78 already has all the infrastructure for pool properties that was still missing from maczfs_74. However, this commit kernel panics. But as the bare untest kernel panics in the same situation, I am quite sure the panic is unrelated to my ashift implementation. |
… ashift property in some placed missed earlier.
I moved the ashift stuff for untested form the untested branch itself into a feature branch untested_ashift. That required rewriting history and dropping my two commits from untesting, both commits ore now part of untested_ashift (unmodified, i.e same IDs as before). Sorry for the confusion Different topic: |
This commit adds the missing bits to check the numeric value of the ashift property. Please review carefully, since this part is most different in maczfs_74 from all newer revisions.
Hi Alex, |
…r new pool properties. This fixes the kernel panic introduced by the previous fix to the ashift property implementation. This revision supports setting ashift at pool creation, rejects resetting the property and correctly reports the property in zpool get. Fixes issue 111
Obsoleted by new request #4 Closed by BjoKaSH |
Hello Alex,
As pushed forward by Daniel on the mailing list, implements "zpool create -o ashift=xxx ...". I have tested it on Snow Leopard (using my makefile-build system) and it seems to work.
This commit should work as "fast-forward" on your master.
-- Björn
This commit tries to implement the ashift pool property as used
in ZFSonLinux and the ZEVO beta releases. It is based on the
ZFSonLinux implementation, and follows this comment:
openzfs/zfs#195 (comment)
and the resulting final patch for ZFSonLinux found here:
openzfs/zfs@df30f56
The original inventors are
Due to the large distance between macZFS and ZFSonLinux
(pool version 8 vs. 28) it was necessary to redo and adapt their
approach instead of just copying the changes.
Note that this solution is technical not fully correct:
(a) it introduces a pool property that should not exist in pool
version 8
(b) it introduces a new property type, PROP_ONTIME that should not
exist in pool version 8
(c) the ashift value is really a property of individual top-level
vdevs, and not a pool-wide value. A pool can (and should under
certain conditions) have top-level vdevs of different block size.
However, using a pool-wide property is what other implementations do,
so we do the same for the sake of compatibility.