Re: io_submit() blocks for writes for substantial amount of time

[Dave Chinner <david@fromorbit.com>]

On Tue, Sep 19, 2017 at 07:53:52PM +0200, Tomasz Grabiec wrote:
> On Tue, Sep 19, 2017 at 7:38 PM, Brian Foster <bfoster@redhat.com> wrote:
> >> Is that because the disk is nearly full and there are no known flushed
> >> extents, or because the allocator doesn't prioritize known-flushed extents?
> >> From your comments below I gather you may not know for sure.
> >>
> >
> > I'm not sure without digging further into it. Hence the question around
> > free space availability.
> 
> The file system was utilized between 90% and 95% out of 165GB during the test.

Then I'm surprised that you only hit these relatively minor delays.
Once you get beyond 85-90% full the filesystem is typically not
running through allocation fast paths as large contiguous free
spaces are getting to be non-existant (especially for such small
filesystems like this).

Continued operation at >85-90% full will run you into premature
aging situations like free space fragmentation, and then all your
allocations and then data IO patterns will begin to suffer.  Once
you get above 95% full, various algorithms will even stop attempting
optimal allocations and instead start optimising for minimum size at
the expense of increased file fragmentation.

IOWs, expect unpredictable delays in the filesystem once you start
approaching ENOSPC, and the closer to ENOSPC you get the more
unpredictable the filesystem behaviour will get. And if you spend
long periods of time operating near ENOSPC, performance and
behaviour may not improve unless you free a large amount of space
(e.g. 50% of filesystem space) so that large contiguous free space
regions can reform....

So, yes, you can operate at near ENOSPC conditions. However, it's not
advisable if you require deterministic/predictable behaviour and/or
have long term filesystem performance requirements...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com