You might try using aio_waitcomplete instead of aio_suspend. I wrote it
because I hated the aio_suspend/array methodology. You should also make
sure you bzero the aiocb structure before use as some of the fields could
cause strange behavior if left with random data.
-Chris
On Mon, 25 Jun 2001, Richard Hodges wrote:
> > On Fri, 22 Jun 2001, Richard Hodges wrote:
>
> > > I tried AIO some months ago (4.1R or 4.2R), but had some trouble
> > > with AIO, mainly that it seemed to lose track of half my files.
> > > Not any particular files, it seemed that at any moment it would
> > > just pick ten or so (out of maybe 20-25 files) to ignore at any
> > > given time.
> > >
>
> On Mon, 25 Jun 2001, Christopher Sedore wrote:
>
> > I've done this at the 3-6 MB/sec continous (peaks at 10MB+/sec) range with
> > good success with aio, both the network and disk functions. Never had
> > trouble with it losing track of files (not sure what you mean here). If
> > you didn't tweak some of the default sysctl settings, you may have bumped
> > limits that caused unexpected behaviour (though you should have gotten
> > error returns to let you know).
>
> Going back to my notes, my first use of AIO was:
>
> For every file to read:
> 1. Clear aiocb and fill all fields,
> x->aio_sigevent.sigev_notify = SIGEV_NONE;
> x->aio_sigevent.sigev_signo = 0;
> 2. Do an aio_read(), if no error, put pointer to aiocb
> into an array
> 3. Do aio_suspend with pointers to the successful
> aiocb's from the aio_read()'s
>
> The idea is to queue up the requests and wait for one of them
> to succeed. Then check all of the files, for each pending:
>
> 4. Get status with aio_error()
> 5. If EINPROGRESS, check next file
> 6. If zero or error, get status with aio_return
> 7. If successful, log new data and check next file
> 8. If error, log error and check next file
>
> What I found out that aio_suspend() will fail with a rather low
> number of file operations (AIO_LISTIO_MAX==16), so aio_suspend()
> is not an option.
>
> So instead of doing aio_suspend(), I had a loop that posted
> new reads as neccessary with aio_read(), and another loop
> that checks each pending operation with aio_error(). This
> allowed some of the reads to succeed, but for some reason
> AIO seemed to forget about some of them, as if AIO has some
> internal limit to the number of pending read operations. This
> was with only 20 files, and reading from UFS on vinum (striped).
>
> This was about half a year ago, but I am sure this is reasonably
> close to what really happened...
>
> -Richard
>
> -------------------------------------------
> Richard Hodges | Matriplex, inc.
> Product Manager | 769 Basque Way
> [EMAIL PROTECTED] | Carson City, NV 89706
> 775-886-6477 | www.matriplex.com
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
