4k drives and x86 OpenSolaris clones : a workaround.

Added by Guenther Alka about 3 years ago

i found this thread at http://hardforum.com/showthread.php?t=1579515
is this doable, recomended and stable??

from the thread"
Disclaimer : this is highly experimental, DO NOT use as your only backup, you may loose data you care about !

Hi all,

I wanted a reliable way to tune current 4k drives on x86 Solaris clones. Freebsd already has it's trick with "gnop".
However, Freebsd creates a slice on drives, and ZFS best practices say "no good" if you import a Freebsd created zpool to Solaris.

I tried this patched zpool binary, but I had a serious system panic after a while. I could re-import my zpool read-only, but I consider myself lucky. After a deep look in the ZFS code on the OpenSolaris source browser, it appears that ashift is scattered in other places, and changing it only in the zpool binary file results in inconsistencies and at least broken space maps. Digging deep enough it seems however that there may be a right place to change the value in the "vdev.c" source file, at least to create a zpool, but this is what we want.

http://src.opensolaris.org/source/xr...fs/vdev.c#1226

The authors say

  • This is the first-ever open, so use the computed values.
  • For testing purposes, a higher ashift can be requested.

As far as I understand it, it won't touch your existing zpools, but only on the new ones you'll create.
So ashift can be changed here, put 12 instead of zip :

http://src.opensolaris.org/source/xr...fs/vdev.c#1107

The makefile is way too cryptic for my developer skills, so I rebuilt the whole system, following this great guide :

http://www.illumos.org/projects/illu..._Build_illumos

After checking the nightly build log, it appears that only the "zfs" binaries and "libzpool.so.1" libraries depend on vdev.c.

So here we are, you can do it yourself, or save some time: install OpenIndiana b148 and download the modified files here:

http://www.megaupload.com/?d=EQ0MT0M0

Make a backup of your existing files:

/kernel/kmdb/amd64/zfs
/kernel/kmdb/zfs
/kernel/drv/zfs
/kernel/drv/amd64/zfs
/kernel/fs/amd64/zfs
/kernel/fs/zfs
/sbin/zfs
/usr/lib/amd64/libzpool.so.1
/usr/lib/libzpool.so.1

and replace them with the ones I've built. As root, call

tar xvjpf <ashift12.tar.bz2 path> -C /

Reboot, create a new zpool, it will have "ashift" set to 12. Restore your original zfs and libzpool.so.1 files, reboot.
Now stress your new zpool (copy and delete files, on and on, benchmark...) and get us posted about stability and performance.
"


Replies (2)

RE: 4k drives and x86 OpenSolaris clones : a workaround. - Added by Indiana Joe about 3 years ago

I should have posted here first probably :)

Is it doable ? Sure it is, I'm testing it right now on a 9X2TB Samsung F4EG raidz.

As described in the post, I created the zpool with a modified OpenIndiana. (BTW, the OpenIndiana build guide is out of my reach, thats why I switched to Illumos)
Then exported it, imported back and upgraded in Solaris 11 Express.

Before anybody tells me : sorry for the poor technique. Just starting messing around with some code... All the files are probably not necessary, but the package is not that heavy so I prefered put all the zfs binaries I could find in.

Is it stable ? Time and testing will tell :) But as for now, it should be considered instable.

Feedback and improvement advices welcome !

RE: 4k drives and x86 OpenSolaris clones : a workaround. - Added by Indiana Joe about 3 years ago

Actually it was a much more complicated way to achieve exactly what was done here

http://digitaldj.net/2010/11/03/zfs-zpool-v28-openindiana-b147-4k-drives-and-you/

It took me time to get that vdev.c actually reads what the zpool command populates. At least I took confidence in the above link method reliability.
Post deleted on HardForum.

(1-2/2)