There are two issues.
The first is correct partition alignment, the second ashift value.
In "theory", I haven't tested this yet, manually creating the slices
with a start position to sector 64 and using slices instead of whole
disks for the zpool devices, and creating with an ashift of 12 may
produce the desired outcome.
I have used 4k disks (wd20ears) in 3 and 4 disk raidz pools, but they
are used for archiving, so just have data dumped to them.
Few issues on Sata ports, but dodgy on SAS.
Mark
On 1/05/2012 8:23 a.m., Peter Wood wrote:
I'm building a storage server with Dell MD1000 DAS and I just bought 30
drives with 4K sectors.
One of the reasons I selected the "new" 4K sector is so I can easily find
replacement drives 2-3 years from now when they start failing. Looks like
this was a huge mistake.
I'm fine if the drives report 512B sectors and work in slower legacy mode
as long as they work reliable but seems that this may not be the case. On
top of that my internal drives that make the rpool have 512B sectors so I'm
not sure how workarounds will effect this pool.
Is it fair to say that if one uses 4K drives he will run into alignment
issue sooner or later?
I'm really puzzled what to do here.
Should I try to replace the drives with 512B ones before the storage goes
life?
Any thoughts?
Thank you
Peter
On Mon, Apr 30, 2012 at 7:54 AM, Richard Elling<
richard.ell...@richardelling.com> wrote:
On Apr 29, 2012, at 7:38 PM, Gordon Ross wrote:
On Sun, Apr 29, 2012 at 8:46 PM, Richard Elling
<richard.ell...@richardelling.com> wrote:
On Apr 29, 2012, at 11:45 AM, George Wilson wrote:
[...]
Speaking of 4K sectors, I've taken a slightly different approach that
fixes this outside of ZFS. The idea is to allow sd to override the
physical-block-size which ZFS will pick up. The way this works is you can
specify the Vendor/Product id in sd.conf. Here's an example:
sd-config-list = "NETAPP LUN, "physical-block-size:4096";
This is the preferred solution and there are several implementations
running
around in various stages of test/release/acceptance. I look forward to
getting this
upstream :-)
-- richard
Providing a work-around in "sd" is great. We should do that, at least.
But is it sufficient? What happens if I replace a mirrored drive with
512 byte sectors with one having 4k sectors? What if I want to plan
ahead for that? Maybe in only some of my ZFS pools but not all?
It would seem that a pool-level override for "ashift" might also be
useful.
ashift is set for the top-level vdev at creation time. So you have to
override
prior to creation of the mirror.
-- richard
--
ZFS Performance and Training
richard.ell...@richardelling.com
+1-760-896-4422
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
