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? Nico -- _______________________________________________ opensolaris-arc mailing list opensolaris-arc@opensolaris.org
