From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: Issues with delalloc->real extent allocation
Date: Wed, 19 Jan 2011 09:03:35 +1100 [thread overview]
Message-ID: <20110118220335.GY28803@dastard> (raw)
In-Reply-To: <20110118204008.GA28791@infradead.org>
On Tue, Jan 18, 2011 at 03:40:09PM -0500, Christoph Hellwig wrote:
> On Tue, Jan 18, 2011 at 08:30:00AM -0600, Geoffrey Wehrman wrote:
> > Glad you were able to understand what I meant. Something I didn't think
> > of earlier though: What happens when I try to use an 8 GB on a system
> > with only 4 GB of memory? I'm not really worried about this pathological
> > case, but I do wonder what the effects will be of allocating what could
> > be significant quantities of memory in .aio_write.
>
> I think for large regions we'd be much better off to only zero the
> blocks on disk, not in-memory - for example like the code in
> xfs_zero_remaining_bytes does.
That doesn't help us, because the .writepage allocation code will
still allocate extsize aligned extents and expose the problem that
we have blocks on disk with no data in the page cache covering
them. The point of zeroing at .aio_write is that it avoids the
problem of .writepage allocating blocks we don't have dirty pages
for.
My preferred optimisation for this problem is that once we get above
a certain extsize threshold we simply preallocate extsized and
aligned chunks that cover the entire range for the write instead of
writing zeros. That preserves the extsize allocation alignment, and
unaligned writes and future IO see the space as unwritten and hence
get zeroed correctly...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-01-18 22:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 0:29 Issues with delalloc->real extent allocation Dave Chinner
2011-01-14 16:40 ` Geoffrey Wehrman
2011-01-14 22:59 ` Dave Chinner
2011-01-15 4:16 ` Geoffrey Wehrman
2011-01-17 5:18 ` Dave Chinner
2011-01-17 14:37 ` Geoffrey Wehrman
2011-01-18 0:24 ` Dave Chinner
2011-01-18 14:30 ` Geoffrey Wehrman
2011-01-18 20:40 ` Christoph Hellwig
2011-01-18 22:03 ` Dave Chinner [this message]
2011-01-14 21:43 ` bpm
2011-01-14 23:32 ` bpm
2011-01-14 23:50 ` bpm
2011-01-14 23:55 ` Dave Chinner
2011-01-17 20:12 ` bpm
2011-01-18 1:44 ` Dave Chinner
2011-01-18 20:47 ` Christoph Hellwig
2011-01-18 23:18 ` Dave Chinner
2011-01-19 12:03 ` Christoph Hellwig
2011-01-19 13:31 ` Dave Chinner
2011-01-19 13:55 ` Christoph Hellwig
2011-01-20 1:33 ` Dave Chinner
2011-01-20 11:16 ` Christoph Hellwig
2011-01-21 1:59 ` Dave Chinner
2011-01-20 14:45 ` Geoffrey Wehrman
2011-01-21 2:51 ` Dave Chinner
2011-01-21 14:41 ` Geoffrey Wehrman
2011-01-23 23:26 ` Dave Chinner
2011-01-17 0:28 ` Lachlan McIlroy
2011-01-17 4:37 ` Dave Chinner
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=20110118220335.GY28803@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=xfs@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox