> 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. When it comes to reads: The OS does readahead more intelligently than the disk could ever hope. Hardware readahead is useless. 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. 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. It's like selling usb fobs labeled USB2 or USB3. If you look up or measure the actual performance of any one of these devices, they can't come anywhere near the bus speed... In fact, I recently paid $45 for a USB3 16G fob, which is finally able to achieve 380 Mbit. Oh, thank goodness I'm no longer constrained by that slow 480 Mbit bus... ;-) Even so, my new fob is painfully slow compared to a normal cheap-o usb2 hard disk. They just put these labels on there because it's a marketing requirement. Something that formerly mattered one day, but people still use as a purchasing decider. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
