Is there any update on this? You suggested that Jeff had some kind of solution
for this - has it been integrated or is someone working on it?
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
On September 27, 2006 11:27:16 AM -0700 Richard Elling - PAE [EMAIL
PROTECTED] wrote:
In the interim, does it makes sense for a simple rule of thumb?
For example, in the above case, I would not have the hole if I did
any of the following:
1. add one disk
2. remove one disk
observations below...
Bill Moore wrote:
Thanks, Chris, for digging into this and sharing your results. These
seemingly stranded sectors are actually properly accounted for in terms
of space utilization, since they are actually unusable while maintaining
integrity in the face of a single drive
Richard Elling - PAE wrote:
More generally, I could suggest that we use an odd number of vdevs
for raidz and an even number for mirrors and raidz2.
Thoughts?
Sounds good to me. I'd make sure it's in the same section of the BP
guide as Align the block size with your app... type notes.
I believe I have tracked down the problem discussed in the low
disk performance thread. It seems that an alignment issue will
cause small file/block performance to be abysmal on a RAID-Z.
metaslab_ff_alloc() seems to naturally align all allocations, and
so all blocks will be aligned to asize on
On 9/26/06, Richard Elling - PAE [EMAIL PROTECTED] wrote:
Chris Csanady wrote:
What I have observed with the iosnoop dtrace script is that the
first disks aggregate the single block writes, while the last disk(s)
are forced to do numerous writes every other sector. If you would
like to
