On Thu, Jun 16, 2011 at 10:40:25PM -0400, Edward Ned Harvey wrote: > > From: Daniel Carosone [mailto:d...@geek.com.au] > > Sent: Thursday, June 16, 2011 10:27 PM > > > > Is it still the case, as it once was, that allocating anything other > > than whole disks as vdevs forces NCQ / write cache off on the drive > > (either or both, forget which, guess write cache)? > > I will only say, that regardless of whether or not that is or ever was true, > I believe it's entirely irrelevant. Because your system performs read and > write caching and buffering in ram, the tiny little ram on the disk can't > possibly contribute anything.
I disagree. It can vastly help improve the IOPS of the disk and keep the channel open for more transactions while one is in progress. Otherwise, the channel is idle, blocked on command completion, while the heads seek. > When it comes to reads: The OS does readahead more intelligently than the > disk could ever hope. Hardware readahead is useless. Little argument here, although the disk is aware of physical geometry and may well read an entire track. > When it comes to writes: Categorize as either async or sync. > > When it comes to async writes: The OS will buffer and optimize, and the > applications have long since marched onward before the disk even sees the > data. It's irrelevant how much time has elapsed before the disk finally > commits to platter. To the application in he short term, but not to the system. TXG closes have to wait for that, and applications have to wait for those to close so the next can open and accept new writes. > When it comes to sync writes: The write will not be completed, and the > application will block, until all the buffers have been flushed. Both ram > and disk buffer. So neither the ram nor disk buffer is able to help you. Yes. With write cache on in the drive, and especially with multiple outstanding commands, the async writes can all be streamed quickly to the disk. Then a cache sync can be issued, before the sync/FUA writes to close the txg are done. Without write cache, each async write (though deferred and perhaps coalesced) is synchronous to platters. This adds latency and decreases IOPS, impacting other operations (reads) as well. Please measure it, you will find this impact significant and even perhaps drastic for some quite realistic workloads. All this before the disk write cache has any chance to provide additional benefit by seek optimisations - ie, regardless of whether it is succesful or not in doing so. -- Dan.
pgpCzO1l9K1Um.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
