From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <53966518.6020407@kernel.dk> Date: Mon, 09 Jun 2014 19:53:28 -0600 From: Jens Axboe MIME-Version: 1.0 Subject: Re: unable to replay a trace generated w/ fio References: <537A5FBD.6010303@kernel.dk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: Allen Schade , fio@vger.kernel.org List-ID: On 2014-06-05 13:02, Allen Schade wrote: > Jens Axboe writes: > >> >> On 2014-05-18 04:01, Alket Memushaj wrote: >>> I am not having luck with 2.1.7 either, but anything up to 2.0.11 >>> works. It seems to terminate as soon as it completes reading the trace >>> file - at the end of which I have /dev/sdb close as that's what's >>> generated by fio itself when I set write_iolog= >> >> I'll take a look, I bet it's an issue from around the time the file >> opening logic was added. >> >> Can you send the exact job you used to create and replay files? Will >> make my life easier. >> > > Hi, I'm am running into this issue too. > > Here are simple instructions to replicate: > > [hdc-write] > filename=/dev/hdc > ioengine=sync > iodepth=1 > direct=1 > thread=1 > continue_on_error=1 > read_iolog=trace.log > > > trace.log: > /dev/hdc add > /dev/hdc open > /dev/hdc write 2045557202944 8192 > /dev/hdc close > > ./fio trace.fio > hdc-write: (g=0): rw=read, bs=4K-4K/4K-4K/4K-4K, ioengine=sync, iodepth=1 > fio-2.1.7 > Starting 1 thread > Segmentation fault (core dumped) OK, so the replay bug here is that you added a filename=. Due to a bug in the freeing of files logic (fio does do that for iolog loads), we don't reset this when freeing files. So fio attempts to close 2 files on exit, boom. This is fixed in -git as of now. Replay of that file still looks weird, doesn't look like it actually does that IO. Will debug next... -- Jens Axboe