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

It might be possible to override the ashift value with sd.conf
and fool the OS into using 512b sectors over a 4KB native disk
(this is mostly used the other way around, though - to enforce
4KB sectors on 4KB native drives that emulate 512b sectors).
This might work, and earlier posters on the list saw no evidence
to say that 512b emulation is inherently evil and unreliable
(modulo firmware/hardware errors that can be anywhere anyway),
but this would likely make the disk slower on random writes.

Also, I am not sure how the 4KB-native HDD would process partial
overwrites of a 4KB sector with 512b pieces of data - would other
bytes remain intact or not?..

Before trying to fool a production system this way, if at all,
I believe some stress-tests with small blocks are due on some
other system.

My 2c,
//Jim Klimov

zfs-discuss mailing list

Reply via email to