Line 71 of http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/fs/zfs/sys/dsl_dataset.h#dsl_dataset_phys says uint64_t ds_pad[8]; /* pad out to 256 bytes for good measure */ But that padding actually increases dsl_dataset_phys to 320 bytes total; the structure is already 256 bytes without the padding. This message posted from opensolaris.org
Matthew A. Ahrens
2005-Dec-16 21:46 UTC
[zfs-discuss] Re: Miscalculation in a comment in dsl_dataset.h
> Line 71 of > http://cvs.opensolaris.org/source/xref/on/usr/src/uts/ > common/fs/zfs/sys/dsl_dataset.h#dsl_dataset_phys > says > uint64_t ds_pad[8]; /* pad out to 256 bytes for good > measure */ > But that padding actually increases dsl_dataset_phys > to 320 bytes total; the structure is already 256 > bytes without the padding.Good catch. That comment must have been left over from when the blkptr_t was "only" 64 bytes long. --matt This message posted from opensolaris.org
Possibly Parallel Threads
- [PATCH] 1. changes for vdiskadm on illumos based platform
- [LLVMdev] trunk's optimizer generates slower code than 3.5
- [LLVMdev] trunk's optimizer generates slower code than 3.5
- [LLVMdev] trunk's optimizer generates slower code than 3.5
- Are recursive snapshot destroy and rename atomic too?