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
On 9/12/07, Pawel Jakub Dawidek wrote:
> On Tue, Aug 07, 2007 at 11:28:31PM +0100, James Blackburn wrote:
> > Well I read this email having just written a mammoth one in the other
> > thread, my thoughts:
> >
> > The main difficulty in this, as far as I see it, is you're
> > intentionally moving d
Andreas,
We have explored the idea of increasing the dnode size in the past
and discovered that a larger dnode size has a significant negative
performance impact on the ZPL (at least with our current caching
and read-ahead policies). So we don't have any plans to increase
its size generically any
On Sep 13, 2007 15:27 -0600, Mark Maybee wrote:
> We have explored the idea of increasing the dnode size in the past
> and discovered that a larger dnode size has a significant negative
> performance impact on the ZPL (at least with our current caching
> and read-ahead policies). So we don't have
The performance benchmarks that Mark refers to are valid for our current
ZPL implementation. That is, the bonus buffer only contains the znode
and symlink contents. If, however, we had an application that always
had an extended attribute, and that extended attribute was frequently
accessed, then
