Nicolas Williams wrote:
On Wed, Jul 28, 2010 at 07:06:20AM +0800, bz211116 wrote:
Nicolas Williams wrote:
On Tue, Jul 27, 2010 at 12:47:31PM -0700, Garrett D'Amore wrote:
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 do we care about performance of non-ZFS here? (Answer: probably.
I'm thinking of raw device uses too.)
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.
But shouldn't ZFS just always do 4KB aligned writes and be done? Who
cares if the SSD claims to have a 512B physical sector size?
Most of SSDs in F5100/F20 is in this case...
Thanks.
-bo
Nico
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org
