Nicolas Williams wrote:
On Tue, Jul 27, 2010 at 12:47:31PM -0700, Garrett D'Amore wrote:
I'm really confused here. Why run in an emulation mode at all? It
seems like we can align and use 4K blocks directly, then we should
*always* do so - at least for those devices which have a 4K physical
block size. The "emulated" block size might be helpful for legacy OS,
but we can do better, can't we?
Is there a reason that this we would ever, under normal circumstances,
want to use RMW on these devices? Is there a reason that this should
even be exposed as a tunable to customers?
Probably when accessing UFS, FAT, and other such filesystems.
Yes, For other file systems or applications which still issue non-4K
aligned I/Os to those SSDs which
has low performance RMW in f/w, turn on RMW in sd can greatly improve
the performance, our experiments
show 100x faster than RMW in f/w. But for those disk drives which
perform RMW better at f/w, we should turn
RMW in sd driver off. This is one reason we need this tunable.
But I don't get why this needs to be a tunable either, at least for ZFS,
since we could ensure that ZFS always does 4KB aligned writes, and then
who cares if UFS, FAT, and friends run slow on flash.
For ZFS, which now uses READ CAPACITY 16 (if succeed) to get the
physical block size of SSD. If the
physical block size is 4096, ZFS aligns its minimal I/O size and request
address at 4K boundary which can get best performance.
But most of the SSDs now still report 512B physical sector size or even
do not support physical sector size at all, and some
of them also has bad RMW performance in f/w. in this case, we should
turn on RMW in sd for them. that's another reason
we need this tunable.
Thanks.
-bo
Nico
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
