ZFS ashift tuning revisited

[Matthew Ahrens]

On Sat, Apr 20, 2013 at 3:35 PM, Steven Hartland <killing at multiplay.co.uk>wrote:

> ----- Original Message ----- From: "Pawel Jakub Dawidek" <pjd at FreeBSD.org>
>
> On Sat, Apr 20, 2013 at 06:20:58PM +0100, Steven Hartland wrote:
>
>> > From: "Alexander Motin" <mav at FreeBSD.org>
>> > > I've never really investigated the question, but I guess that
>> increasing > > system-wide minimal desired ashift to 4K may cause
>> additional disk space > > waste, possibly even more if compression is used.
>> Though point that more > > and more disks are using 4K blocks is valid.
>> From other side FusioIO > > periodically mention that they can effectively
>> handle records smaller > > then 512b, so who knows what we seen in 10 years.
>> > > It does indeed increase waste a bit but currently I'd say thats a
>> small
>> > downside compared to benefits of increased compatibility and performance
>> > on more mainstream / popular HW.
>>
>> I saw presentation of one of the key ZFS devs, not sure which one (was
>> it Matt Ahrens?) stating that 4kB sectors can waste a lot of space for
>> reasonable small blocks and wide RAIDZ vdevs.
>>
>
That sounds right to me.  RAIDZ-N always has to allocate at least N sectors
for parity, and possibly a few additional sectors for alignment issues.  So
your example below is correct.

I didn't see the beginning of this thread, but it sounds like you're
considering changing the default ashift to 4k?  I guess it depends on what
kind of bug reports / complaints you want to field :)  "my hardware is
great but ZFS uses twice as much space" vs. "my hardware lies to ZFS, which
therefore uses a slower way of accessing the hardware".

--matt


>
>> For example if you use RAIDZ2 and 8kB recordsize you will be able to use
>> only half of your pool size (effectively it becomes a mirror), because
>> of how RAIDZ allocates the space.
>>
>> In my math half is a lot:)
>>
>> PS. I'm adding zfs-devel@ to the thread.
>>
>
> That is indeed a lot. I've got some machines here that are not yet in
> production I can test that and report back.
>




>
>    Regards
>    Steve
>
> ==============================**==================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and
> the person or entity to whom it is addressed. In the event of misdirection,
> the recipient is prohibited from using, copying, printing or otherwise
> disseminating it or any information contained in it.
> In the event of misdirection, illegible or incomplete transmission please
> telephone +44 845 868 1337
> or return the E.mail to postmaster at multiplay.co.uk.
>
> ______________________________**_________________
> zfs-devel at freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/zfs-devel<http://lists.freebsd.org/mailman/listinfo/zfs-devel>
> To unsubscribe, send any mail to "zfs-devel-unsubscribe@**freebsd.org<zfs-devel-unsubscribe at freebsd.org>
> "
>