Jens, Sorry I don't know how to compile. Hope that doesn't mean no one will ever replay to me again. I'm very appreciative of the suggestions you've made and will try capturing a source trace where I don't get any dropped event messages. I'll also capture just one device. My blktrace log files go to the OS storage device whereas the devices traced are on a different storage path. In this first experiment I didn't have to do any device mapping as I was able to arrange storage on the replay host of sufficient capacity with matching device references. Eric -----Original Message----- From: Jens Axboe [mailto:axboe@xxxxxxxxx] Sent: Wednesday, February 26, 2014 3:45 PM To: Lamkin, Eric; David Nellans Cc: fio@xxxxxxxxxxxxxxx Subject: Re: fio replay On 2014-02-26 09:49, Jens Axboe wrote: > On 2014-02-26 06:23, Lamkin, Eric wrote: >> David, >> >> Thanks for responding. >> I sent the below out last week but didn't get a reply so thought I'd >> try a simpler 'what works' tactic this morning. >> As seen in the below I'm using 2.0.10. > > I just ran a quick test here, current -git seems to work fine for me. > It might be a bit finicky in that the error handling isn't stellar, > which I'm thinking could be your issue since you have dropped events > in your blktraces. You need to eliminate any dropped events - either > log to tmpfs or send the traces over the network, that would likely do it. > > If that doesn't solve it for you, please boil this down to a smaller > test case. Start with one device. Does that work? Up the complexity > until you see an issue, then I can likely help you get this fixed if I > get the problematic trace. Can you try current -git? I made some improvements/fixes to the multiple device handling. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
