SSD blocksize about zfsonlinux.github.com HOT 5 CLOSED

Under Linux normally we use the physical block size reported by the device. However, there are a small number of devices which incorrectly report their physical block size (normally as 512b) so we maintain a white list. If you have a Samsung 840 I'd suggest checking /sys/block/<device>/queue/physical_block_size to see what it reports.

Setting this value larger than the actual physical block size can result in wasted space, setting it smaller can result in terrible performance. So it's definitely best if it actually matches the what's used internally in the drive.

from zfsonlinux.github.com.

The device reports 512b blocks I was questioning the disparity between the zfsonlinux blocksize override for that device (8K) the value joyent picked (4K) for the same device.

My reasoning for doubting the zfsonlinux value is that the hardware will have been tuned for NTFS which is going to pick an allocation size of 4K.

This stems from the fact that I am running an NTFS volume with 4K allocation size on a zvol (volblocksize 4K) and if I go with the zfsonlinux default of ashift=13 (8K) I also hit the problem of performance tanking as my writes are too small for the zpool.

from zfsonlinux.github.com.

Also the pagesize on x86_64 is 4K so if you swap on a zvol with 4K blocksize belonging to a zpool with ashift=13 / 8K blocks you are going be issuing writes that are too small

from zfsonlinux.github.com.

The datasheet for this device doesn't seem to explicitly state the physical block size. so either the 4k or 8k value really could be correct. The ZoL commit message in bff32e0972bbc07ba5f2b9ce5b965813d8edcf78 says the 8k value was verified but it doesn't provide a link. Regardless, the important thing is how the device behaves. I'd suggest trying both sizes and see if you notice any difference, you can use the -o ashift=X option when creating the pool to force the ashift.

from zfsonlinux.github.com.

Closed as stale.

from zfsonlinux.github.com.