From: Dave Chinner <david@fromorbit.com>
To: Alex Elder <aelder@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/2] xfs: dynamic speculative EOF preallocation
Date: Fri, 15 Oct 2010 08:33:25 +1100 [thread overview]
Message-ID: <20101014213325.GF4681@dastard> (raw)
In-Reply-To: <1287076965.2362.520.camel@doink>
On Thu, Oct 14, 2010 at 12:22:45PM -0500, Alex Elder wrote:
> On Mon, 2010-10-04 at 21:13 +1100, Dave Chinner wrote:
> > @@ -427,11 +431,25 @@ xfs_iomap_eof_want_preallocate(
> > if ((imap[n].br_startblock != HOLESTARTBLOCK) &&
> > (imap[n].br_startblock != DELAYSTARTBLOCK))
> > return 0;
> > +
> > start_fsb += imap[n].br_blockcount;
> > count_fsb -= imap[n].br_blockcount;
> > +
> > + /* count delalloc blocks beyond EOF */
> > + if (imap[n].br_startblock == DELAYSTARTBLOCK)
> > + found_delalloc += imap[n].br_blockcount;
> > }
> > }
> > - *prealloc = 1;
>
> At this point, count_fsb will be 0 (a necessary condition
> for loop termination, since count_fsb is unsigned). Since
> found_delalloc is initially 0 (and is also unsigned), we
> can safely assume that found_delalloc >= count_fsb. The
> only case in which found_delalloc <= count_fsb is if
> found_delalloc is also 0 (a case you cover separately,
> first, below).
>
> Furthermore, *prealloc was assigned the value 0 at the top.
> So I think this bottom section can be simplified to:
> if (!found_delalloc)
> *prealloc = 1;
I'll have a look at this - there was some reason for the second
case, but the code has changed since I needed it and, as you
suggest, it might not be needed anymore.
> > error = xfs_iomap_eof_want_preallocate(mp, ip, offset, count,
> > ioflag, imap, XFS_WRITE_IMAPS, &prealloc);
> > if (error)
> > @@ -476,9 +495,25 @@ xfs_iomap_write_delay(
> >
> > retry:
> > if (prealloc) {
> > + xfs_fileoff_t alloc_blocks = 0;
> > + /*
> > + * If we don't have a user specified preallocation size, dynamically
> > + * increase the preallocation size as we do more preallocation.
> > + * Cap the maximum size at a single extent.
> > + */
> > + if (!(mp->m_flags & XFS_MOUNT_DFLT_IOSIZE)) {
>
> I note that this is circumventing the special code in
> xfs_set_rw_sizes() that tries to set up a different (smaller)
> size in the event the "sync" (generic) mount option was supplied
> (indicated by XFS_MOUNT_SYNC). If that is a good thing, then I
> suggest the code in xfs_set_rw_sizes() go away. But it would be
> good to have the case for making that change stated.
The new code based on file size is a bit different. It still
triggers off the absence of his flag, but it now uses the default
sizes as the minimum speculative allocation size.
> I guess the reason one might want the "allocsize" mount
> option now becomes the opposite of why one might have
> wanted it before. I.e., it would be used to *reduce*
> the size of the preallocated range beyond EOF, which I
> could envision might be reasonable in some circumstances.
It now becomes the minimum preallocation size, rather than both the
minimum and the maximum....
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:[~2010-10-14 21:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 10:13 [RFC, PATCH 0/2] xfs: dynamic speculative preallocation for delalloc Dave Chinner
2010-10-04 10:13 ` [PATCH 1/2] xfs: dynamic speculative EOF preallocation Dave Chinner
2010-10-14 17:22 ` Alex Elder
2010-10-14 21:33 ` Dave Chinner [this message]
2010-10-15 6:51 ` allocsize mount option, was: " Michael Monnerie
2010-10-15 11:59 ` Dave Chinner
2010-10-04 10:13 ` [PATCH 2/2] xfs: don't truncate prealloc from frequently accessed inodes Dave Chinner
2010-10-14 17:22 ` Alex Elder
2010-10-14 21:28 ` Dave Chinner
2010-10-14 17:22 ` [RFC, PATCH 0/2] xfs: dynamic speculative preallocation for delalloc Alex Elder
2010-10-14 21:16 ` Dave Chinner
2010-10-14 21:50 ` Ivan.Novick
2010-10-15 7:14 ` Michael Monnerie
2010-10-15 11:45 ` Dave Chinner
2010-10-17 14:31 ` Michael Monnerie
2010-10-17 23:49 ` Dave Chinner
2010-10-18 6:39 ` Michael Monnerie
-- strict thread matches above, loose matches on Subject: below --
2010-11-29 0:43 [PATCH 0/2] xfs: dynamic speculative allocation beyond EOF V3 Dave Chinner
2010-11-29 0:43 ` [PATCH 1/2] xfs: dynamic speculative EOF preallocation Dave Chinner
2010-12-07 10:17 ` Christoph Hellwig
2010-12-07 10:49 ` Dave Chinner
2010-12-13 1:25 [PATCH 0/2] xfs: dynamic speculative allocation beyond EOF V4 Dave Chinner
2010-12-13 1:25 ` [PATCH 1/2] xfs: dynamic speculative EOF preallocation Dave Chinner
2010-12-15 18:57 ` Christoph Hellwig
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=20101014213325.GF4681@dastard \
--to=david@fromorbit.com \
--cc=aelder@sgi.com \
--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 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.