Re: Add extra_buff_count flag

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Wed, Nov 04 2009, Jens Axboe wrote:
> > 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.

I think this is fixed now, committed a patch for it.

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

[Home]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Video Projectors]     [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [XFree86]

Powered by Linux