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... 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 zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
