Thank you for the documentation update. You also mentioned that you saw some kind of a race on io_u->flags today, do you by any chance know if you were using iodepth_low or iodepth_batch_complete or libaio engine options. I think I see an issue when using them and understand why it happens, but dont have a clean fix yet, will hopefully have one soon. I was wondering if its the same issue you are seeing. Basically the issue is we might think the queue is full (because we cannot allocate any more io_u (they are probably doing async verify)), but the code assumes that if the queue is full, then there is atleast one I/O that we can do "io_getevents" on. And that will cause a hang in the code. thanks -radha On Wed, Nov 4, 2009 at 11:22 AM, Jens Axboe <jens.axboe@xxxxxxxxxx> wrote: > On Wed, Nov 04 2009, Jens Axboe wrote: >> On Wed, Nov 04 2009, Radha Ramachandran wrote: >> > I would rather document it than add it by default in case it starts >> > hitting memory constraints because its allocating more memory buffers. >> >> Yes I agree, I usually don't like having one option implying changes for >> another either. > > So the problem with documentation is that usually nobody reads it. This > is what the HOWTO/man page currently has: > > verify_async=int Fio will normally verify IO inline from the submitting > thread. This option takes an integer describing how many > async offload threads to create for IO verification instead, > causing fio to offload the duty of verifying IO contents > to one or more separate threads. If using this offload > option, even sync IO engines can benefit from using an > iodepth setting higher than 1, as it allows them to have > IO in flight while verifies are running. > > It's already documented... > > -- > 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
