From: Mark Tinguely <tinguely@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: Mon, 11 Feb 2013 16:00:44 -0600 [thread overview]
Message-ID: <51196A0C.8080405@sgi.com> (raw)
In-Reply-To: <1360559102-20432-2-git-send-email-david@fromorbit.com>
On 02/10/13 23:05, 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>
> ---
Works great. The above xfs_io example makes a good start of a test.
Reviewed-by: Mark Tinguely <tinguely@sgi.com>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-02-11 22:00 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 [this message]
2013-02-12 13:35 ` Brian Foster
2013-02-14 23:31 ` Ben Myers
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=51196A0C.8080405@sgi.com \
--to=tinguely@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox