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