[zfs-discuss] ashift=12 on 512 bytes disks?
adilger at dilger.ca
Tue Dec 19 15:24:39 EST 2017
On Dec 19, 2017, at 8:44 AM, Richard Elling via zfs-discuss <zfs-discuss at list.zfsonlinux.org> wrote:
>> On Dec 17, 2017, at 1:05 AM, Gionatan Danti via zfs-discuss <zfs-discuss at list.zfsonlinux.org> wrote:
>> Hi all,
>> I recently created a new ZFS pool using 4x WD Gold 2TB (configured in mirrored pairs) and 2x Samsung 850 EVO 500GB for caching ans SLOG.
>> The main pool disks (WD Gold) have 512-bytes sectors and I left ashift to the default value (ashift=9). Cache and SLOG were added with "-o ashift=12" to align at 4K boundaries.
> slogs workloads are 4k anyway, so setting ashift doesn't do much for 512e devices.
> For cache devices, it depends on the release. In the bad old days, cache only worked well for 512e/512n.
> Proper 4k support was added https://github.com/zfsonlinux/zfs/commit/82710e993a3481b2c3cdefb6f5fc31f65e1c6798
>> Now I wonder if the original choice to use ashift=9 on the main disks was the better one, or if it can bite me in the future. Suppose a disk fails and I can not replace it with another 512-bytes disk, rather a 4K HD must be used. I know I can manually set the correct ashift value (12) during replacing; however, I wonder if this "mixed" mode (ashift=9 on some disks, ashift=12 on the new 4K one) can lead to lower performance and/or other problems.
> Mixed mode is very common. Ideally, it should be handled automatically and do the right thing.
There is a proposal in that area, see ""Oh Shift! changing the allocation size":
>> The obvious solution would be to recreate the entire pool with ashift=12, treating all disks as 4K ones. I know this implies some space loss, but it should be no too severe.
>> Any suggestions?
> Personally, I wouldn't bother with recreating the pool. Eventually these things tend to migrate towards
> more modern hardware and I would do the migration when ready to decommission the old hardware.
> -- richard
> zfs-discuss mailing list
> zfs-discuss at list.zfsonlinux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: Message signed with OpenPGP
More information about the zfs-discuss