[OpenIndiana-discuss] zpool replace says the disk has a different sector alignment

Timothy Coalson tsc5yc at mst.edu
Wed Nov 20 19:08:51 UTC 2013


On Wed, Nov 20, 2013 at 5:48 AM, Frank Swasey <Frank.Swasey at uvm.edu> wrote:

> On Tue, 19 Nov 2013 at 6:57pm, Timothy Coalson wrote:
>
>  Is it possible to reflash the controller to the older firmware that
>> reported them as 512?  Not the first thing I'd want to try, but...
>>
>
> Yeah, I'm hopeful that there was something beneficial in that update
> besides the pain that I'm now feeling.  (Of course, it would have been a
> good thing if I had read the notes about what the update was going to do
> first -- but hindsight is usually perfect).
>

If you updated firmware without having a symptom you wanted resolved, then
moving back to the old firmware without this new "problem" (which is
probably a feature rather than a bug) becomes more palatable, as long as
you can be sure that going backwards won't break something (for instance,
since it is using RAID labels on the disks, did the new firmware change the
label to a newer format?).


> One of my co-workers suggested that since this pool is made up of 4
> 11-disk RAIDZ2's and we are using less than half the entire pool size -
> that perhaps we can shrink the pool and create a new pool to move the data
> to, then add the other half into the new pool.  I'm starting to do more
> reading, but while it sounds like a good idea, I'm not sure how or if it
> would be possible.
>
>
>
>> Found one post I half-remembered over on illumos zfs that says the sd
>> driver doesn't allow that:
>>
>> http://www.listbox.com/member/archive/182191/entry/19:299/
>> 20130326114258:D38D379E-962B-11E2-AF17-BE9C6E434AE2/
>>
>
> Well, that is a real bummer - but I do understand why a programmer would
> not want to insert that kind of complexity (not to mention the performance
> penalty of a bad implementation) into the sd driver.
>

I'm not sure that changing the behavior to do what we want would actually
be a problem for the driver - also that post says logical, when apparently
it won't let you set it below the reported physical blocksize, I'm thinking
that may have been a mistype.  The disk should accept IO of the size of the
logical blocksize, which is 512 to not break previous usage, so in theory,
the sd driver shouldn't have to do the RMW logic if you told it to treat a
512e drive as 512n...maybe I'm missing something, but this seems like an
unneccesary limitation, which makes it extra hard to deal with situations
that are "suboptimal".

Obviously the system can import a pool with ashift=9 configuration on 4k
(well, 512e anyway) disks, so at some layer, it works for both reading and
writing in exactly the configuration you want on the replacement disk - it
just apparently will not let you apply such a suboptimal label to a new
disk, even when trying to replace a failed disk.  Personally, I think that
the zpool command should treat it as a warning that can be overridden with
-f (which can already override "in-use" detection, which can actually be
destructive rather than just suboptimal), rather than a flat-out error.
Making the disk lie to zfs via sd.conf is only desirable because zfs is too
stubborn about it.

Tim


More information about the OpenIndiana-discuss mailing list