From: Dave Chinner <david@fromorbit.com>
To: Avi Kivity <avi@scylladb.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: ENSOPC on a 10% used disk
Date: Fri, 19 Oct 2018 12:24:23 +1100 [thread overview]
Message-ID: <20181019012423.GK6311@dastard> (raw)
In-Reply-To: <5516031c-6c4f-072f-e9f9-9f0ecee9927d@scylladb.com>
On Thu, Oct 18, 2018 at 06:44:54PM +0300, Avi Kivity wrote:
>
> On 18/10/2018 14.00, Avi Kivity wrote:
> >
> >
> >This can happen, and indeed I see our default hint is 1MB, so our
> >small files use a 1MB hint. Looks like we should remove that 1MB
> >hint since it's reducing allocation flexibility for XFS without a
> >good return.
>
>
> I convinced myself that this is the root cause, it fits perfectly
> with your explanation. I still think that XFS should allocate
> *something* rather than ENOSPC, but I can also understand someone
> wanting a guarantee.
Yup, it's a classic catch 22.
> >On the other hand, I worry that because we bypass the page cache,
> >XFS doesn't get to see the entire file at one time and so it will
> >get fragmented.
>
>
> That's what happens. I write 1000 4k writes to 400 files, in
> parallel, AIO+DIO. I got 400 perfectly-fragmented files, each had
> 1000 extents.
Yup, you wrote them all in the one directory, didn't you? :)
> So I'll remove the default hint for small files, and replace it with
> larger buffer sizes so we batch more and don't get 8k-sized extents
> (which is our default buffer size).
Or you could just mount with the "noalign" mount option to turn off
stripe alignment. After all, you don't need stripe alignment for a
single spindle....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-10-19 9:28 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-17 7:52 ENSOPC on a 10% used disk Avi Kivity
2018-10-17 8:47 ` Christoph Hellwig
2018-10-17 8:57 ` Avi Kivity
2018-10-17 10:54 ` Avi Kivity
2018-10-18 1:37 ` Dave Chinner
2018-10-18 7:55 ` Avi Kivity
2018-10-18 10:05 ` Dave Chinner
2018-10-18 11:00 ` Avi Kivity
2018-10-18 13:36 ` Avi Kivity
2018-10-19 7:51 ` Dave Chinner
2018-10-21 8:55 ` Avi Kivity
2018-10-21 14:28 ` Dave Chinner
2018-10-22 8:35 ` Avi Kivity
2018-10-22 9:52 ` Dave Chinner
2018-10-18 15:44 ` Avi Kivity
2018-10-18 16:11 ` Avi Kivity
2018-10-19 1:24 ` Dave Chinner [this message]
2018-10-21 9:00 ` Avi Kivity
2018-10-21 14:34 ` Dave Chinner
2018-10-19 1:15 ` Dave Chinner
2018-10-21 9:21 ` Avi Kivity
2018-10-21 15:06 ` Dave Chinner
2018-10-18 15:54 ` Eric Sandeen
2018-10-21 11:49 ` Avi Kivity
2019-02-05 21:48 ` Dave Chinner
2019-02-07 10:51 ` Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181019012423.GK6311@dastard \
--to=david@fromorbit.com \
--cc=avi@scylladb.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.