Question about non asynchronous aio calls.

[Gleb Natapov]

On Thu, Oct 08, 2015 at 08:21:58AM +0300, Avi Kivity wrote:
> >>>I fixed something similar in ext4 at the time, FWIW.
> >>Makes sense.
> >>
> >>Is there a way to relax this for reads?
> >The above mostly only applies to writes. Reads don't modify data so
> >racing unaligned reads against other reads won't given unexpected
> >results and so aren't serialised.
> >
> >i.e. serialisation will only occur when:
> >	- unaligned write IO will serialise until sub-block zeroing
> >	  is complete.
> >	- write IO extending EOF will serialis until post-EOF
> >	  zeroing is complete
> 
> 
> By "complete" here, do you mean that a call to truncate() returned, or that
> its results reached the disk an unknown time later?
> 
I think Brian already answered that one with:

  There are no such pitfalls as far as I'm aware. The entire AIO
  submission synchronization sequence triggers off an in-memory i_size
  check in xfs_file_aio_write_checks(). The in-memory i_size is updated in
  the truncate path (xfs_setattr_size()) via truncate_setsize(), so at
  that point the new size should be visible to subsequent AIO writers.

> i could, immediately after truncating the file, extend it to a very large
> size, and truncate it back just before the final fsync/close sequence.  This
> has downsides from the viewpoint of user support (why is the file so large
> after a crash, what happens with backups) but is better than nothing.
> 
> >	- cached pages are found on the inode (i.e. mixing
> >	  buffered/mmap access with direct IO).
> 
> We don't do that.
> 
> >	- truncate/extent manipulation syscall is run
> 
> Actually, we do call fallocate() ahead of io_submit() (in a worker thread,
> in non-overlapping ranges) to optimize file layout and also in the belief
> that it would reduce the amount of blocking io_submit() does.
> 
> Should we serialize the fallocate() calls vs. io_submit() (on the same
> file)?  Were those fallocates a good idea in the first place?
> 
> >All other DIO will be issued and run concurrently, reads and writes.
> >
> >Realistically, if you are care about performance (which obviously
> >you are) then you do not do unaligned IO, and you try hard to
> >minimise operations that extend the file...
> 
> On SSDs, if you care about performance you avoid random writes, which cause
> write amplification.  So you do have to extend the file, unless you know its
> size in advance, which we don't.
> 
> Also, does "extend the file" here mean just the size, or extent allocation
> as well?
> 
> A final point is discoverability.  There is no way to discover safe
> alignment for reads and writes, and which operations block io_submit(),
> except by asking here, which cannot be done at runtime.  Interfaces that
> provide a way to query these attributes are very important to us.
As Brian pointed statfs() can be use to get f_bsize which is defined as
"optimal transfer block size".

--
			Gleb.