On Mon, Sep 4, 2017 at 9:42 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Fri, Sep 01, 2017 at 09:52:18AM +0300, Amir Goldstein wrote: >> [CC list, Ted] >> >> ... >> >> >> > >> > Alright I tested it and it's working fine for me. I'm creating three lv's and >> > then doing >> > >> > -drive file=/dev/mapper/whatever,format=raw,cache=none,if=virtio,aio=native >> > >> > And I get /dev/vd[bcd] which I use for my test/scratch/log dev and it works out >> > fine. What is your -drive option line and I'll duplicate what you are doing. >> > Thanks, >> > >> >> I am using Ted's kvm-xfstests, so this is the qemu command line: >> https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/kvm-xfstests#L104 >> >> The only difference in -drive command is no aio=native. >> BINGO! when I add aio-native there are no more log corruptions :) >> Please try to use aio=threads to see if you also get log corruptions. >> >> Thing is we cannot change kvm-xfstests to always use aio=native because >> it is not recommended for sparse images: >> https://access.redhat.com/articles/41313 > > Hmmmm. I think you're looking at an article that's at least 6 years > out of date. It was last updated at: > > Updated September 16 2012 at 2:04 AM > > Looking at the bug it references there was a heap of problems in the > DIO code, the AIO code and the filesystem code that we fixed in > upstream kernels in late 2010/early 2011. e.g > > http://oss.sgi.com/archives/xfs/2011-01/msg00156.html > > Those took some time to get back into vendor kernels, but the > aio=native kvm problems described in that kbase article were fixed > in a RHEL 6.1 point release in May 2011. > > IOWs, if qemu w/ aio=native doesn't work these days, the article > you've quoted is not the reason. > > In that case, I'll post a patch to have kvm-xfstests use aio=native. I suppose it is the proper way to run xfstests inside kvm anyway. Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html