[zfs-code] Adding New Zpool Property

[J Duff]

Thanks Matt... It looks as if 6582456 is in snv_71, and PSARC 2007/342 will be 
in snv_75. I'll wait until snv_75 comes out since I'm just playing around with 
using ZFS on a laptop and thought I'd add a pool property to enable/disable a 
setting that identifies the pool as a laptop pool. There are probably many 
other ways to do this, but I thought it would be a good learning experience to 
add the pool property.

Duff
--
This messages posted from opensolaris.org

[zfs-code] Adding New Zpool Property

[Matthew Ahrens]

Duff,

You should resync with Lin Ling's putback for: PSARC 2007/342 "Enhanced ZFS 
Pool Properties" from this morning.  It substantially changes the way the 
pool properties are implemented, and should make implementing a new pool 
property much easier.  (Also note, I fixed particular nastyness that you hit 
as part of 6582456 "property code is overdue for some spring cleaning" on 
August 2.)

What new pool properties are you working on?

--matt


J Duff wrote:
> I?m trying to add a new zpool property to the ZFS code base, but I am
> confused by the mismatched lengths of zfs_prop_t and zfs_prop_table. For
> more details, read on?
> 
> In the file usr/src/uts/common/sys/fs/zfs.h, I add a new value to the
> zfs_prop_t enum. The comment at the beginning of zfs_prop_t states that I
> must add my new property to the end of the enum in order to ?ensure that
> external consumers are not affected by the change?. I assume this means
> that some users of zfs.h might not be recompiled, and so I should not
> disrupt the existing enum values for zfs_prop_t. So, I add my new
> property, ZPOOL_PROP_NEWPROP, to the end of the zfs_prop_t, i.e., after
> ZPOOL_PROP_NAME.
> 
> The comment at the beginning of zfs_prop_t also states that I must update
> zfs_prop_table in usr/src/common/zfs/zfs_prop.c. However, zfs_prop_table
> has entries for all zfs and zpool properties except for ZPOOL_PROP_NAME.
> If I add a zfs_prop_table entry for ZPOOL_PROP_NEWPROP, its table index
> will not match the ZPOOL_PROP_NEWPROP enum and hence will cause the
> property code to break.
> 
> Should I add ZPOOL_PROP_NEWPROP just before ZPOOL_PROP_NAME in
> zfs_prop_table and not at the end of the enum as the comment states? This
> would result in generating the proper zfs_prop_table index. Also, I can?t
> find a place where ZPOOL_PROP_NAME is actually used to index into
> zfs_prop_table so the missing zfs_prop_table entry may be tolerable.
> However, ZPOOL_PROP_NAME is used in
> usr/src/lib/libzfs/common/libzfs_pool.c, and if I change its enum value, I
> will have to rebuild it and all its users.
> 
> In order to complete the task of adding a new pool property, I will have
> to re-build not only the kernel, but also modify and rebuild the zpool
> executable. Are there other executables that I will have to rebuild?
> 
> Duff -- This messages posted from opensolaris.org 
> ___ zfs-code mailing list 
> zfs-code at opensolaris.org 
> http://mail.opensolaris.org/mailman/listinfo/zfs-code

[zfs-code] Adding New Zpool Property

[J Duff]

I?m trying to add a new zpool property to the ZFS code base, but I am confused 
by the mismatched lengths of zfs_prop_t and zfs_prop_table. For more details, 
read on?

In the file usr/src/uts/common/sys/fs/zfs.h, I add a new value to the 
zfs_prop_t enum. The comment at the beginning of zfs_prop_t states that I must 
add my new property to the end of the enum in order to ?ensure that external 
consumers are not affected by the change?. I assume this means that some users 
of zfs.h might not be recompiled, and so I should not disrupt the existing enum 
values for zfs_prop_t. So, I add my new property, ZPOOL_PROP_NEWPROP, to the 
end of the zfs_prop_t, i.e., after ZPOOL_PROP_NAME.

The comment at the beginning of zfs_prop_t also states that I must update 
zfs_prop_table in usr/src/common/zfs/zfs_prop.c. However, zfs_prop_table has 
entries for all zfs and zpool properties except for ZPOOL_PROP_NAME. If I add a 
zfs_prop_table entry for ZPOOL_PROP_NEWPROP, its table index will not match the 
ZPOOL_PROP_NEWPROP enum and hence will cause the property code to break.

Should I add ZPOOL_PROP_NEWPROP just before ZPOOL_PROP_NAME in zfs_prop_table 
and not at the end of the enum as the comment states? This would result in 
generating the proper zfs_prop_table index. Also, I can?t find a place where 
ZPOOL_PROP_NAME is actually used to index into zfs_prop_table so the missing 
zfs_prop_table entry may be tolerable. However, ZPOOL_PROP_NAME is used in 
usr/src/lib/libzfs/common/libzfs_pool.c, and if I change its enum value, I will 
have to rebuild it and all its users.

In order to complete the task of adding a new pool property, I will have to 
re-build not only the kernel, but also modify and rebuild the zpool executable. 
Are there other executables that I will have to rebuild?

Duff
--
This messages posted from opensolaris.org