On Wed, Nov 04 2009, Radha Ramachandran wrote:
> Thank you for the documentation update.
I haven't updated it, it was already there :-)
> 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.
I didn't use libaio, I can reproduce it with the sync engine directly
and much easier if using fast "null" verifies. It triggers this assert
in put_io_u():
assert((io_u->flags & IO_U_F_FREE) == 0);
and this in __get_io_u():
assert(io_u->flags & IO_U_F_FREE);
The former I think is just a bug, it's likely a reput or something, but
not sure yet. The latter looks like a race on the flags, since it isn't
always locked down when manipulated.
So it sounds like it's two separate issues, I'd urge you to continue
debugging yours and I'll fix this one tomorrow.
--
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
