Date: Sat, 11 Dec 1999 01:28:54 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: noslenj@swbell.net (Jay Nelson) Cc: tlambert@primenet.com, des@flood.ping.uio.no, andrews@technologist.com, Doug@gorean.org, bright@wintelcom.net, chat@FreeBSD.ORG, doconnor@gsoft.com.au, dscheidt@enteract.com Subject: Re: dual 400 -> dual 600 worth it? Message-ID: <199912110128.SAA19053@usr02.primenet.com> In-Reply-To: <Pine.BSF.4.05.9912101801450.2681-100000@acp.swbell.net> from "Jay Nelson" at Dec 10, 99 06:05:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> > > Yeah, the new box I'm evaluating has SCA LVD SCSI, and it goes a > >> > > lot faster. I'm compiling -Stable and so far -j 6, 8 and 12 have all > >> > It _SHOULD_ go faster with SCSI as opposed to (E)IDE/UDMA/etc. > > [snip] > > >This means that for server systems, A SCSI drive with a tagged > >command queue depth of 128 (common on a number of IBM drives, > >just to keep the vendor the same) can support 128 times as much > >concurrency as an IDE drive, everything else about the drive > >being equal. > > This may be a stupid question, but would soft updates improve IDE > performance in relation to SCSI? Or would it simply block longer less > often? Soft updates speak to the ability to stall dependent writes until they either _must_ be done, or until they no longer are relevent. It does this as a strategy for ordering the metadata updates (other methods are DOW - Delayed Ordered Writes - and synchronous writing of metadata... in decreasing order of performance). Soft updates basically represents possible file system operations as a directed acyclic graph, and then registers dependency resolvers that resolve dependencies between operations on an edge (this is why Kirk often calls them "soft dependencies" instead of "soft updates", the original name used by Ganger and Patt). For operations where the cached metadata updates that have been delayed result in a cache hit and a rewrite of the update, you can expect high performance from soft updates. They also do an implict implementation of what is commonly called "write gathering" by virtue of being able to resolve metadata updates that revert data before it has to go to disk. This is why when you copy a huge tree, then delete it, and you do it within 30 seconds (or whatever you've set your syncerd for), the only thing that gets updated is the access and modification times of the directory in which you did the work. But then you must add in locality of reference. The locality of reference theorem stated that applications tend to operate against data sets which are localized, and that different applications will operate against different localities by virtue of operating against different data sets. In this case, you have soft updates graphs with dependencies hooked off of them, but the directories to which these graphs apply are members og non-intersecting sets. This means that there is no dependency related stalling as a result of the applications modifications to file system data or metadata, and thus, if it can be supported, the operations can be interleaved to stable storage. So the very short answer to the question is "on a multi-applicaiton server, using soft updates doesn't mean that you wouldn't benefit from interleaving your I/O". To speak to Brett's issue of RAID 5, parity is striped across all disks, and doing parity updates on one stripe on one disk will block all non-interleaved I/O to all other areas of the disk; likewise, doing a data write will prevent a parity write from completing for the other four disks in the array. This effectively means that, unless you can interleave I/O requests, as tagged command queues do, you are much worse off. As to the issue of spindle sync, which Brett alluded to, I don't think that it is supported for IDE, so you will be eating a full rotational latency on average, instead of one half a rotational latency, on average: (0 + 1)/2 vs. (1 + 1)/2. Rod Grimes did some experimentation with CCD and spindle sync on SCSI devices back when CCD first became capable of mirroring, and has some nice hard data that you should ask him for (or dig it out of DejaNews on the FreeBSD news group). As I said, tagged command queues are supported by the IDE standard; they just aren't supported by commonly available IDE disks or controllers. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912110128.SAA19053>