Trying to understand how aio(4), mount(8) async (and gjournal) relate

[Mel Flynn]

On Monday 23 March 2009 18:18:19 Julian Elischer wrote:
> Mel Flynn wrote:
> > Hello list,
> >
> > in an effort to try and understand the various async systems available,
> > it's unclear to me how (if at all) the above relate.
> >
> > If one mounts a disk with async, does this internally use aio system
> > calls, or is there a subsystem available which does largely the same? If
> > so, why are there 2 subsystems?
>
> the async mount operation tells the systewm that writes done by a
> process may be actually written to teh filesystem at any time later,
> and that it is ok to return "success" to the user immediately,
> regardless of whether the write has actually been done.
> This also applies to the metadata. It does not affect reads at all.

So it is up to the underlying geom provider to handle the write queue?

>
> > When using aio, for example with squid, does this mean the underlying
> > provider needs to be mounted async or is this totally unrelated?
> > Similarly if said disk is on a gjournalled partition, is the async mount
> > redundant or is using aio redundant or neither?
>
> no the aio system calls are implemented in a manner that allows
> the caller to request IO and then return at a later time to find out
> the result. it has no connection to the mount option.

So with aio_write(2) on an async gjournal fs, one faces a write queue on the 
fd used by aio(4) along with another made by gjournal? This leads me to 
believe that it's better to take one of those out of the equation for 
performance.

> BTW for efficient async IO check out the relationship between the aio
> calls and the kqueue calls.

Thanks for the pointer, reading up ...

-- 
Mel