On Sat, Nov 10, 2012 at 6:19 PM, Jim Klimov <jimkli...@cos.ru> wrote:
> On 2012-11-10 17:16, Jan Owoc wrote:
>> Any other ideas short of block pointer rewrite?
> A few... one is an idea of what could be the cause: AFAIK the
> ashift value is not so much per-pool as per-toplevel-vdev.
> If the pool started as a set of the 512b drives and was then
> expanded to include sets of 4K drives, this mixed ashift could
> happen...
Now I'm really confused. Turns out, my system is the opposite:
# zdb -C tank | grep ashift
ashift: 12
ashift: 12
ashift: 12
ashift: 12
ashift: 12
ashift: 12
ashift: 9
ashift: 9
ashift: 9
ashift: 9
ashift: 9
ashift: 9
ashift: 9
ashift: 9
ashift: 9
ashift: 12
ashift: 12
ashift: 12
ashift: 12
ashift: 12
ashift: 12
I had an old pool with ashift=9, and when I tried to add new disks,
zpool wouldn't let me add the new drives. So, I ended up creating a
new pool with ashift=12, and after migrating, destroyed the old pool,
and added the drives to the new. I was told at the time that as long
as the pool is created with ashift=12, new vdevs would have ashift=12
as well. Obviously, that's not the case. I did verify that ashift was
12 after creating the pool, but I apparently did not check after
adding the old drives, because this is the first time I've noticed
that there's any ashift=9 in the pool.
--
Trond Michelsen
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
