On Thu, Oct 16, 2008 at 1:53 AM, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > OFF TOPIC : > > On Wed, Oct 8, 2008 at 5:14 PM, FUJITA Tomonori > <fujita.tomonori@xxxxxxxxxxxxx> wrote: >> >> My point is that the performance of read-world workload benchmark like >> dbench are relevant for the users than the performances of sequential >> accesses. > > > Funny you should mention DBENCH ( http://dbench.samba.org ). > I recently added a NFS backend so that dbench can generate raw NFS > traffic using "nfs-style" loadfiles. With the ability to take a NFS > network trace and convert into one such loadfile automatically. > > I also recently added a SCSI backend to dbench (though it only handles > READ10 and TESTUNITREADY commands so far) with the intent of being > able to trace from a kernel the set of all SCSI operations perfromed > durign some operation and then use "dbench -B scsi" to replay the > exact same set of commands. > My vision is that this could then be used to compare different devices > how they operate on specific kinds of workloads. > Maybe one "loadfile" that records and replays all SCSI i/o that goes > to a device while one is recompiling a kernel, while operating on a > very large picture in GIMP, reading a very large document into > openoffice, etc etc. Hmmm, it struck me recently that one could write a simple filter SCSI LLD that interposes itself between a real LLD and the SCSI ML and captures all CDBs and some of the data on the way through and makes it available for a capture program in the same way as the packet capture stuff works. In some ways, this would be more convenient than using iSCSI ... -- Regards, Richard Sharpe -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
