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

[Bruce Evans]

On Mon, 23 Mar 2009, Julian Elischer wrote:

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

Actually, this only (*) applies to the metadata.  The async mount option
does not affect writes, except for the metadata part of writes and for
a small affect on the amount of asyncness of writes.  The data part of
writes is always (*) written asynchronously and "success" is returned to
the user immediately, irrespective of whether the write has actually
been done.  (Success may be returned even if the write was attempted but
failed.  Writes are retried endlessly to a fault, so the data for a failed
writes is not always lost.  (The usual fault is panicing when the disk
goes away.)  It is necessary to use fsync() or the still-unimplemnted
POSIX interface fdatasync() to ensure that the data has been written or
get a report of non-success.)

(*) Not quite only or always, since
(1) The async mount option is incompatible with soft updates and is silently
     ignored if soft updates is configured.  Soft updates essentially gives
     async everything, with stronger ordering of writes so that the file
     system is always consistent (but often out of date).
(2) The sync mount option may be used to force synchronous writes of data.
     This option should give synchronous everything, but when it is mixed
     with the async mount option (and that option is not ignored) it gives
     the weird and undesirable behaviour of sync writes of data and async
     writes of metadata.

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

Yes, essentially Unix kernels always had and used async writes, and the
relatively new and quite different aio interface lets applications do
async writes too.

Bruce