From: Ben Myers <bpm@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 1/2] xfs: limit speculative prealloc size on sparse files
Date: Thu, 14 Feb 2013 17:31:24 -0600 [thread overview]
Message-ID: <20130214233124.GK22182@sgi.com> (raw)
In-Reply-To: <1360559102-20432-2-git-send-email-david@fromorbit.com>
On Mon, Feb 11, 2013 at 04:05:01PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> Speculative preallocation based on the current file size works well
> for contiguous files, but is sub-optimal for sparse files where the
> EOF preallocation can fill holes and result in large amounts of
> zeros being written when it is not necessary.
>
> The algorithm is modified to prevent EOF speculative preallocation
> from triggering larger allocations on IO patterns of
> truncate--to-zero-seek-write-seek-write-.... which results in
> non-sparse files for large files. This, unfortunately, is the way cp
> now behaves when copying sparse files and so needs to be fixed.
>
> What this code does is that it looks at the existing extent adjacent
> to the current EOF and if it determines that it is a hole we disable
> speculative preallocation altogether. To avoid the next write from
> doing a large prealloc, it takes the size of subsequent
> preallocations from the current size of the existing EOF extent.
> IOWs, if you leave a hole in the file, it resets preallocation
> behaviour to the same as if it was a zero size file.
>
> Example new behaviour:
>
> $ xfs_io -f -c "pwrite 0 31m" \
> -c "pwrite 33m 1m" \
> -c "pwrite 128m 1m" \
> -c "fiemap -v" /mnt/scratch/blah
> wrote 32505856/32505856 bytes at offset 0
> 31 MiB, 7936 ops; 0.0000 sec (1.608 GiB/sec and 421432.7439 ops/sec)
> wrote 1048576/1048576 bytes at offset 34603008
> 1 MiB, 256 ops; 0.0000 sec (1.462 GiB/sec and 383233.5329 ops/sec)
> wrote 1048576/1048576 bytes at offset 134217728
> 1 MiB, 256 ops; 0.0000 sec (1.719 GiB/sec and 450704.2254 ops/sec)
> /mnt/scratch/blah:
> EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
> 0: [0..65535]: 96..65631 65536 0x0
> 1: [65536..67583]: hole 2048
> 2: [67584..69631]: 67680..69727 2048 0x0
> 3: [69632..262143]: hole 192512
> 4: [262144..264191]: 262240..264287 2048 0x1
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
Applied.
Regards,
Ben
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-14 23:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-11 5:05 [PATCH 0/2] xfs: couple of patches for 3.9 Dave Chinner
2013-02-11 5:05 ` [PATCH 1/2] xfs: limit speculative prealloc size on sparse files Dave Chinner
2013-02-11 22:00 ` Mark Tinguely
2013-02-12 13:35 ` Brian Foster
2013-02-14 23:31 ` Ben Myers [this message]
2013-02-11 5:05 ` [PATCH 2/2] xfs: rearrange some code in xfs_bmap for better locality Dave Chinner
2013-02-11 22:43 ` Mark Tinguely
2013-02-12 1:36 ` 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=20130214233124.GK22182@sgi.com \
--to=bpm@sgi.com \
--cc=david@fromorbit.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.