Re: [squid-users] aufs lseek on read()

From: Michael Puckett <Michael.Puckett@dont-contact.us>
Date: Thu, 30 Sep 2004 08:14:28 -0700

Henrik Nordstrom wrote:

> On Wed, 29 Sep 2004, Michael Puckett wrote:
>
> > I have been examining both the aufs and ufs versions of squid with truss
> > and have seen that the async i/o version has thousands more calls to
> > lseek than the non async version. On looking at the source of
> > squidaio_do_read() it does indeed do a lseek() followed by a read()
> > where the non async read doesn't seem to. This leads to 2 questions:
> >
> > 1. According to the man page entry, threaded implementations should not
> > use lseek() followed by read() as atomicity between the calls cannot be
> > guaranteed. It recommends using pread() instead. Is this correct?
>
> Correct. But in Squid there is an guarantee there is only one call at a
> time per filedescriptor so it is not a problem.
>
> > 2. Why is the lseek() necessary in the async read method but not the
> > blocking read method?
>
> Because the async-io lowlevel interface was modelled along the lines of
> POSIX AIO where the read() operation is read(file, buffer, buffersize,
> file_offset). This was perhaps not the best design, but reasonable.

then why not simply use the pread() function instead which seems to be a
direct replacement for the POSIX AIO and would halve the number of system
calls made when doing a read? In my application it is the large number of
system calls which is affecting the throughput.

Best regards

-mikep

>
>
> Regards
> Henrik

Received on Thu Sep 30 2004 - 09:15:32 MDT

This archive was generated by hypermail pre-2.1.9 : Fri Oct 01 2004 - 12:00:03 MDT