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

[Julian Elischer]

Mel Flynn wrote:
> 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?

The filesystem actually makes the I/O requests at a "later time".

> 
>>> 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.

oh, where to begin....

you do the aio operation. It is queued in the aio system, (unless it 
is acted upon immediately by the AIO thread) your thread then returns 
immediately. The aio thread associated with your process
continues by (though the filesystem) requesting that the IO be done.
The IO system (geom) queues the IO request and (probably immediately)
starts operation on it. which results in the IO request being made to
the hardware.
On completion a notification is made by the driver to the geom layer 
which trickles the info back up to the AIO system which in turn
notifies your process (when it asks) of the result of the operation.

however, you have been working all (or much of) this time, so
throughput and latency are not too bad.  Notice that
teh data is not necessarily queued everywhere if there is no work
in front of it blovking the way. (I'm not a geom expert so
that part is not too clear to me).

async mounting plays no real part in this.


> 
>> BTW for efficient async IO check out the relationship between the aio
>> calls and the kqueue calls.
> 
> Thanks for the pointer, reading up ...
>